SlideShare ist ein Scribd-Unternehmen logo
1 von 50
Downloaden Sie, um offline zu lesen
BEDIFFERENT                                ACE   GERMANY




Copyright © 2012 Aras. All Rights Reserved.                   aras.com
ACE
                                              Germany


 Implementation Best Practices
 Scrum Methodology

 Patrick Willemsen
 Senior Consultant
 ARAS Software AG




Copyright © 2012 Aras. All Rights Reserved.        aras.com
Dilbert says




Copyright © 2012 Aras. All Rights Reserved.   Slide 3   aras.com
Agenda

    Agile Methodology – An Overview
    Agile Methodology – Applied
    Questions




Copyright © 2012 Aras. All Rights Reserved.   Slide 4   aras.com
What is Agile?

    Agile is an iterative software development
     methodology that promotes open collaboration and
     process adaptability through the life cycle of the
     project
    Is beneficial on projects with many unknowns
    Scrum is a framework within Agile methodology




Copyright © 2012 Aras. All Rights Reserved.   Slide 5   aras.com
What Characterizes the Agile
   Process?
    Collaboration and communication
    High level of participation and transparency to the
     users
    Dedicated, cross-functional team(s)
    Self-organized, where everyone participates in
          decision making
    Development is planned in stages by team members
    Testing and documentation are done as you go
    Users see working product sooner

Copyright © 2012 Aras. All Rights Reserved.   Slide 6      aras.com
Agile Development


                                                                     Scrum

Use Cases (Requirements)
                                                                                        Product
                             Product backlog   Sprint backlog                          increment
                                                                              n days

                                      UC001
                                      UC003
                                      UC015
                                        …

                                                                             Sprint




Copyright © 2012 Aras. All Rights Reserved.                Slide 7                                 aras.com
Product Backlog

    High-level document for the entire project
    Contains backlog items:
             brief use case descriptions
             wish-list items
             prioritized/ranked by business value
    The product backlog is property of the Product
     Owner
    Business value is set by the Product Owner

                                                     http://en.wikipedia.org/wiki/Scrum_(development)


Copyright © 2012 Aras. All Rights Reserved.                                             aras.com
Product Owner

    Represents the voice of the customer and ensures
     that the Scrum Team works with the "right things"
     from a business perspective
    The Product Owner collects use cases,
     requirements, prioritizes them, then places them in
     the product backlog


                                              Business Perspective



Copyright © 2012 Aras. All Rights Reserved.                          aras.com
Sprint Team

                                                                  Product owner


                                  Sprint team

                      Customer                          Consultant(s)
                   Process owner(s)


                                              Architect(s)   Scrum master


Copyright © 2012 Aras. All Rights Reserved.                                 aras.com
Scrum Master

    Primary job is to remove obstacles to the ability of
     the team to deliver the sprint goal
    Is not the leader of the team (as the team is self-
          organizing) but acts as a buffer between the team
          and any distracting influences
    Ensures that the Scrum process is used as intended.
     The Scrum Master is the enforcer of rules
    A key part of the Scrum Masters role is to protect
          the team and keep them focused on the
          tasks at hand

Copyright © 2012 Aras. All Rights Reserved.                   aras.com
The Team

    Has responsibility to deliver the product increment
             All team members are responsible to deliver a
              complete and consistent sprint result
    Team is self-organizing in terms of
             Task assignment
             Task order
             Availability
    With sprint planning it commits itself to deliver the
     communicated results
    A team is typically made up of up to 6 people
Copyright © 2012 Aras. All Rights Reserved.                   aras.com
SCRUM Detailed

  • Product backlog                 • Sprint backlog                                       Scrum master




                                                                               Start
                                                                                            • Scrum


                                                Part                           1
                                                                       Sprint planning
Product owner                                                          Requirements definition   2        Consultant(s)
                                                                                                          Customer representatives


                                                                                                           Product
                                                 5     Result presentation
                                                                                                          increment
                                                       Demo

                                                       4    Implementation
                                                                            Solution
                                                                          specification
                                                                                             Sprint
                                                                               3             n days


                                                           Architect
  Copyright © 2012 Aras. All Rights Reserved.                                                                            aras.com
Meetings (1)
                                  At the beginning of a sprint cycle resp. daily

                                 Meeting                      Topics
                                 Planning                      Select what work is to be done
                                              limit: 2h        Prepare the sprint backlog that details the time it
                                                                will take to do that work, with the entire team
                                                               Identify and communicate how much of the work is
                                                                likely to be done during the current sprint

                                                               Input: Product Backlog
                                                               Result: Sprint Backlog
                                 Scrum (Daily)                 What have you done since yesterday?
                                                               What are you planning to do by today?
                                              limit: 15 min    Do you have any problems preventing you from
                                                                accomplishing your goal?




Copyright © 2012 Aras. All Rights Reserved.                                                                           aras.com
Meetings (2)
                                  At the end of a sprint cycle

                                  Meeting                 Topics
                                  Review (demo)            Present the completed work to the stakeholders
                                                            (a.k.a. "the demo")
                                              limit: 2h
                                                           Incomplete work cannot be demonstrated
                                  Review (sessions)        Review the work that was completed and not
                                                            completed by the sprint team
                                              limit: 2h

                                  Retrospective            All team members reflect on the past sprint
                                              limit: 1h    Make continuous process improvement
                                                           Two main questions are asked in the sprint
                                                            retrospective: What went well during the sprint?
                                                            What could be improved in the next sprint?




Copyright © 2012 Aras. All Rights Reserved.                                                                    aras.com
Sprint Backlog

    Detailed document containing information about how the team is going
          to implement the use cases / requirements for the upcoming sprint.
    The document contains the availability of the team members during the
          sprint period.
    Work list broken down into doable tasks (between 2 and 8 hours of
          work). With this level of detail the whole team understands exactly what
          to do, and anyone can potentially pick a task from the list.
    Tasks on the sprint backlog are never assigned by a team lead; rather,
          tasks are signed up for by the team members as needed, according to
          the set priority and the team member skills (Self organizing team).
    The sprint backlog is property of the Team. Estimations are set by the
          Team.



                                                               http://en.wikipedia.org/wiki/Scrum_(development)


Copyright © 2012 Aras. All Rights Reserved.                                                       aras.com
Burn Down Chart

    The burn down chart is a publicly displayed chart showing remaining
          work in the sprint backlog. Updated every day, it gives a simple view of
          the sprint progress. It also provides quick visualizations for reference.


    It should not be confused with an earned value chart.




                                                                 http://en.wikipedia.org/wiki/Scrum_(development)


Copyright © 2012 Aras. All Rights Reserved.                                                         aras.com
OK, GREAT!

        Now how does this apply to Aras
        Innovator?

Copyright © 2012 Aras. All Rights Reserved.   aras.com
Implementation Methodology

    Aras Innovator is ideally suited for an iterative approach:
             Rational Unified Process
                      • Best Practice Presentation ACE 2010 International
                      • Starting Your Aras Implementation ACE 2011 International
             Agile / Scrum Software Development
                      • Aras Innovator Deployment Methodology ACE 2012 Germany
                      • wikipedia http://en.wikipedia.org/wiki/Agile_software_development




                                                   Starting Your Aras
                                                     Implementation
                                               ACE 2011 International

Copyright © 2012 Aras. All Rights Reserved.     Slide 19                                    aras.com
Aras Methodology Overview

    Designed to use the “Small Win” approach
    Take a well defined problem(s) and implement with
     less risk and a higher degree of confidence
    Implement a series of product increments
     (production) releases that comprise the complete
     solution
    Each product increment provides value to the
     business
    Scope each increment to be completed in a defined
     number of sprints

Copyright © 2012 Aras. All Rights Reserved.   Slide 20   aras.com
Discovery Workshop

Customer investigation




                                                                                                SoW

Customer
workshop                                                               Result
  order

                                         Business process analysis              Process description
                                         Business entity model definition       Solution description
                                         Solution mockup                        Solution proposal
                                                                                Main Requirements
                                                                                Brief use cases
                                                                                Data model (high level)
                                                                                System architecture
                                                                                Scope of work
                                                                                Project definition

Copyright © 2012 Aras. All Rights Reserved.                         Slide 21                              aras.com
Use Case Workshops


Discovery Workshop                                          Use Case and Design Workshops


                                                                                                  Product
                                                                                    UC001
                                                 Customer                                         backlog
                                       SoW        project
                                                   order                                           UC001
                                                                UC004       UC003                  UC003
                                                                                                   UC015
                                                                                                     …

                                                                                    UCnnn




                                   Process description                   Detailed use cases
                                   Solution description                  Requirement definition
                                   Solution proposal                     System design
                                   Brief use cases
                                   …


Copyright © 2012 Aras. All Rights Reserved.                   Slide 22                                aras.com
Sprint Plan
                                              Discovery                Workshops                             Product backlog


                        System                Requirements              High Level Use      Non-functional     UC001
                                                                                                               UC003

                      Architecture              definition                  Cases           requirements       UC015
                                                                                                                 …




                                                 Part & BOM
                            Sprint 1             Management
                                                                       Implementation               Test

                                                               Requirements          Requirements
                                                                                                                Product
                                                                                                              increment
                                                 Part & BOM
                            Sprint 2             Management
                                                                       Implementation               Test


                                                                                                                Product
                                                                                                              increment
                                                   Change
                            Sprint 3             Management
                                                                       Implementation               Test




                                                 Program and
                            Sprint 4                Project            Implementation               Test
                                                 Management


Copyright © 2012 Aras. All Rights Reserved.         Slide 23                                                     aras.com
Part & BOM Management
   Example
   Topics                                                System
    Requirements Definition                              Visual Prototypes
             Use case definition
             Data model
             Numbering scheme
             Life cycle
             Workflow
             Permissions
             Revisioning and sequence
             Relationships to other items
              (Part, CAD, documents, …)


Copyright © 2012 Aras. All Rights Reserved.   Slide 24                         aras.com
Implementation

   Sprint                                                Result Presentation
    Develop product increment                            Live Demo
    Write agile documentation
    Maintain product backlog




Copyright © 2012 Aras. All Rights Reserved.   Slide 25                         aras.com
Final Thoughts

    DO
             Develop accurate Use Cases and keep them up to date as you go
             Prioritize use cases and requirements
             Look for “Small Wins” that provide business value
             Create visual prototypes and get user validation before developing
              any method code
             Take result presentations seriously: prepare well, show and discuss
              product increments
    DON’T
             Spend a significant amount of time developing specifications without
              prototyping the solution
             Worry about not getting 100% of the detailed requirements up front:
              Iterate!


Copyright © 2012 Aras. All Rights Reserved.   Slide 26                              aras.com
ACE Germany




 Questions                                    ?
 Patrick Willemsen
 Senior Consultant
 ARAS Software AG




Copyright © 2012 Aras. All Rights Reserved.               aras.com
Scrum

        Project Management


Copyright © 2012 Aras. All Rights Reserved.   aras.com
Project Management
   Agile Project Management with Scrum
    Scrum has not only reinforced the interest in software project management, but also
     challenged the conventional ideas about such management.
    Scrum focuses on project management institutions where it is difficult to plan ahead with
     mechanisms for empirical process control, such as where feedback loops constitute the
     core element of product development compared to traditional command-and-control-
     oriented management.
    It represents a radically new approach for planning and managing software projects,
     bringing decision-making authority to the level of operation properties and certainties.
    Scrum reduces defects and makes the development process more efficient, as well as
     reducing long-term maintenance costs.




Copyright © 2012 Aras. All Rights Reserved.   Slide 29                                          aras.com
Modeling Basics

        Use Cases


Copyright © 2012 Aras. All Rights Reserved.   aras.com
Definition (1)

    A use case is the specification of a set of actions
     performed by a system which yields an observable
     result that is of value to one or more actors or
     other stakeholders of the system
                                               UML 2.0 Specification




Copyright © 2012 Aras. All Rights Reserved.                       aras.com
Definition (2)
    Use Cases
                 Use cases are a documentation technique
                 Use case is a story of using a system to fulfill a goal
                 Use cases capture functional requirements
                 Use cases are not diagrams, they are text
                 Use cases are requirements
                 Use cases define a contract how the system will behave
                 Use case model is the set of all use cases

    Use cases emphasize the user goals and perspectives



    Use Cases do not
             Specify user interface design. They specify the intent, not the action detail
             Specify implementation detail (unless it is of particular importance to the actor to be
              assured that the goal is properly met)



Copyright © 2012 Aras. All Rights Reserved.                                                             aras.com
Definition (3)
             Name starts with a verb
                       Create Part
                       Search on Classification Attributes
                       Release Part
                       Assign Review Participants




Copyright © 2012 Aras. All Rights Reserved.                   aras.com
Definition (4)
    Find the right use case level
                  “A task performed by one person in one place at one time, in response to a business
                  event, which adds measurable business value and leaves the data in a consistent state.”


             Known as Elementary Business Process (EBP, also known as user-level goal use cases)
             An EBP-level use case usually is composed of several steps, not just one or two




Copyright © 2012 Aras. All Rights Reserved.                                                            aras.com
“Boss Test”

    The "boss test" is a naïve approach for determining whether an activity
          qualifies as an elementary business process.
    For example, consider this dialog:
             Boss: "What did you do all day today?“
             Employee: "I logged in.“


    Is the boss happy?
    In general, an EBP-level use case usually involves many steps, not just
          one or two.




Copyright © 2012 Aras. All Rights Reserved.                                    aras.com
Level of Detail

   Casual use case
    Consists of a few paragraphs of text, summarizing the use case.
   Brief use case (Cloud level)
    Consists of a few sentences summarizing the use case. It can be easily inserted in a
     spreadsheet cell, and allows the other columns in the spreadsheet to record priority,
     technical complexity, release number, and so on.
   Fully dressed use case (Sea level)
    Is a formal document based on a detailed template with fields for various sections; and it is
     the most common understanding of the meaning of a use case.




Copyright © 2012 Aras. All Rights Reserved.                                                      aras.com
Brief Use Case Example

    Use Case Name:
             Release CAD Drawing
    Actors:
             Designated User (CMII)
             System
    Use Case Description:
          The user selects one or more drawings to be released and then releases the items. The
          system checks if all release mandatory information – meta data as well as CAD files – has
          been entered by the user and verifies that all related CAD models have been released. The
          system shows success or failure to the user. After the release, the system shall create a
          neutral file format.




Copyright © 2012 Aras. All Rights Reserved.   Slide 37                                                aras.com
Fully-Dressed
         Use case name                             Extensions
         Brief description                            alternate scenarios of success and
                                                        failure
         Scope
                                                    Frequency of occurrence
         Primary actor
                                                       Daily, Weekly, Monthly, Quarterly,
         Stakeholders and interests                    Yearly
             who cares about this use case, and    Complexity
              what do they want?
                                                       Concerning logic which corresponds
    Preconditions                                      to implementation effort
             what must be true on start?              Easy (OOTB), Medium (small
    Success guarantee                                  enhancements), Difficult (complex
                                                        logic)
          (Post conditions)
             what must be true on successful       Miscellaneous
              completion?
    Main success scenario
             typical path, happy path


                                                                                        alistair.cockburn.us

Copyright © 2012 Aras. All Rights Reserved.                                                  aras.com
Diagrams (1)

    UML has use case diagrams
    Use cases are text, not diagrams
             Use case analysis is a writing effort, not drawing
    But a short time drawing a use case diagram provides a context for:
             identifying use cases by name
             creating a “context diagram”




Copyright © 2012 Aras. All Rights Reserved.                                aras.com
Tips & Tricks

    Write in an essential UI-free style
    Write simple
    Write black-box use cases (write what the system must do without
          deciding how it will be done)
    Take an actor and actor-goal perspective
    Define use cases properly (name, etc.)
    Define more useful use cases first




Copyright © 2012 Aras. All Rights Reserved.                             aras.com
Common Problems
    The following is a list of the most common problems in writing
          requirements:
             Making bad assumptions
             Writing implementation (HOW) instead of requirements (WHAT)
             Describing operations instead of writing requirements
             Using incorrect terms
             Using incorrect sentence structure or bad grammar
             Missing requirements
             Over-specifying




Copyright © 2012 Aras. All Rights Reserved.                                 aras.com
Modeling Basics

        Requirements


Copyright © 2012 Aras. All Rights Reserved.   aras.com
Definition
    User Requirements
             Statements of fact and assumptions that define the expectations of the system in terms
              of mission objectives, environment, constraints, and measures of effectiveness and
              suitability (MOE/MOS)


    Functional Requirements
             Functional requirements explain what has to be done by identifying the necessary task,
              action or activity that must be accomplished


    Non-Functional Requirements
             Specify criteria that can be used to judge the operation of a system, rather than specific
              behaviors. Non-functional requirements are often called qualities of a system.




                                                                               http://en.wikipedia.org/wiki/Non-functional_requirement

Copyright © 2012 Aras. All Rights Reserved.                                                                             aras.com
Terminology (1)

    In a specification, there are terms to be avoided and terms that must be
          used in a very specific manner. Authors need to understand the use of
          shall, will, and should:
             Requirements use shall
             Statements of fact use will
             Goals use should


    Terms such as are, is, and was do not belong in a requirement. The term
          must shall be handled consciously. Are, is and was may be used in a
          descriptive section or in the lead-in to a requirements section of the
          specification.




Copyright © 2012 Aras. All Rights Reserved.                                        aras.com
Terminology (2)

    There are a number of terms to be avoided in writing requirements,
          because they confuse the issue and can cost you money, e.g.
             Support
             But not limited to
             Etc.
             And/or




Copyright © 2012 Aras. All Rights Reserved.                               aras.com
Terminology (3)

    Requirements should be easy to read and understand. The requirements
          in a system specification are either for the system or its next level, e.g.
          subsystem. Each requirement can usually be written in the format:
                  The System shall provide ........
                  The System shall be capable of ........
                  The System shall weigh ........
                  The Subsystem #1 shall provide ........
                  The Subsystem #2 shall interface with .....
                  It is required that …




Copyright © 2012 Aras. All Rights Reserved.                                             aras.com
Terminology (4)

                                 Ambiguous Terms           Ways to Improve Them
                                 acceptable, adequate      Define what constitutes acceptability and how the
                                                           system can judge this.
                                 as much as practicable    Don't leave it up to the developers to determine
                                                           what's practicable. Make it a TBD and set a date to
                                                           find out.
                                 at least, at a minimum,   Specify the minimum and maximum acceptable
                                 not more than, not to     values.
                                 exceed
                                 between                   Define whether the end points are included in the
                                                           range.
                                 depends on                Describe the nature of the dependency. Does another
                                                           system provide input to this system, must other
                                                           software be installed before your software can run, or
                                                           does your system rely on another one to perform
                                                           some calculations or services?


Copyright © 2012 Aras. All Rights Reserved.                                                                      aras.com
Terminology (5)

                                 Ambiguous Terms             Ways to Improve Them
                                 efficient                   Define how efficiently the system uses resources, how
                                                             quickly it performs specific operations, or how easy it
                                                             is for people to use.
                                 flexible                    Describe the ways in which the system must change in
                                                             response to changing conditions or business needs.
                                 improved, better, faster,   Quantify how much better or faster constitutes
                                 superior                    adequate improvement in a specific functional area.
                                 including, including but    The list of items should include all possibilities.
                                 not limited to, and so      Otherwise, it can't be used for design or testing.
                                 on, such as, etc.
                                 maximize, minimize,         State the maximum and minimum acceptable values
                                 optimize                    of some parameter.
                                 normally, ideally           Also describe the system's behavior under abnormal
                                                             or non-ideal conditions.



Copyright © 2012 Aras. All Rights Reserved.                                                                        aras.com
Terminology (6)

                                 Ambiguous Terms          Ways to Improve Them
                                 optionally               Clarify whether this means a system choice, a user
                                                          choice, or a developer choice.
                                 reasonable, when         Explain how to make this judgment.
                                 necessary, where
                                 appropriate
                                 robust                   Define how the system is to handle exceptions and
                                                          respond to unexpected operating conditions.
                                 seamless, transparent,   Translate the user's expectations into specific
                                 graceful                 observable product characteristics.
                                 several                  State how many, or provide the minimum and
                                                          maximum bounds of a range.
                                 shouldn't                Try to state requirements as positives, describing
                                                          what the system will do.
                                 state-of-the-art         Define what this means.



Copyright © 2012 Aras. All Rights Reserved.                                                                    aras.com
Terminology (7)

                                 Ambiguous Terms          Ways to Improve Them
                                 sufficient               Specify how much of something constitutes
                                                          sufficiency.
                                 support, enable          Define exactly what functions the system will perform
                                                          that constitute supporting some capability.
                                 user-friendly, simple,   Describe system characteristics that will achieve the
                                 easy                     customer's usage needs and usability expectations




Copyright © 2012 Aras. All Rights Reserved.                                                                  aras.com

Weitere ähnliche Inhalte

Was ist angesagt?

Scrum process powerpoint ppt templates.
Scrum process powerpoint ppt templates.Scrum process powerpoint ppt templates.
Scrum process powerpoint ppt templates.SlideTeam.net
 
Scrum strategy powerpoint presentation slides.
Scrum strategy powerpoint presentation slides.Scrum strategy powerpoint presentation slides.
Scrum strategy powerpoint presentation slides.SlideTeam.net
 
Scrum process sprint cycles roles powerpoint ppt templates.
Scrum process sprint cycles roles  powerpoint ppt templates.Scrum process sprint cycles roles  powerpoint ppt templates.
Scrum process sprint cycles roles powerpoint ppt templates.SlideTeam.net
 
Scrum strategy sprint cycles roles powerpoint presentation templates.
Scrum strategy sprint cycles roles  powerpoint presentation templates.Scrum strategy sprint cycles roles  powerpoint presentation templates.
Scrum strategy sprint cycles roles powerpoint presentation templates.SlideTeam.net
 
Scrum strategy sprint cycles roles powerpoint presentation slides.
Scrum strategy sprint cycles roles  powerpoint presentation slides.Scrum strategy sprint cycles roles  powerpoint presentation slides.
Scrum strategy sprint cycles roles powerpoint presentation slides.SlideTeam.net
 
Scrum strategy powerpoint presentation templates.
Scrum strategy powerpoint presentation templates.Scrum strategy powerpoint presentation templates.
Scrum strategy powerpoint presentation templates.SlideTeam.net
 
Scrum strategy powerpoint ppt slides.
Scrum strategy powerpoint ppt slides.Scrum strategy powerpoint ppt slides.
Scrum strategy powerpoint ppt slides.SlideTeam.net
 
Scrum process sprint cycles roles powerpoint presentation slides.
Scrum process sprint cycles roles  powerpoint presentation slides.Scrum process sprint cycles roles  powerpoint presentation slides.
Scrum process sprint cycles roles powerpoint presentation slides.SlideTeam.net
 
Scrum process powerpoint presentation slides.
Scrum process powerpoint presentation slides.Scrum process powerpoint presentation slides.
Scrum process powerpoint presentation slides.SlideTeam.net
 
Introduction To Agile
Introduction To AgileIntroduction To Agile
Introduction To AgileTony Deng
 
Rawsthorne | Who is your PO
Rawsthorne | Who is your PORawsthorne | Who is your PO
Rawsthorne | Who is your PONikita Filippov
 
Scaling Scrum with UX
Scaling Scrum with UXScaling Scrum with UX
Scaling Scrum with UXCaleb Jenkins
 
Ken Schwaber chez Microsoft pour le French Scrum User Group
Ken Schwaber chez Microsoft pour le French Scrum User GroupKen Schwaber chez Microsoft pour le French Scrum User Group
Ken Schwaber chez Microsoft pour le French Scrum User GroupXavier Warzee
 

Was ist angesagt? (20)

Scrum process powerpoint ppt templates.
Scrum process powerpoint ppt templates.Scrum process powerpoint ppt templates.
Scrum process powerpoint ppt templates.
 
Scrum strategy powerpoint presentation slides.
Scrum strategy powerpoint presentation slides.Scrum strategy powerpoint presentation slides.
Scrum strategy powerpoint presentation slides.
 
Scrum process sprint cycles roles powerpoint ppt templates.
Scrum process sprint cycles roles  powerpoint ppt templates.Scrum process sprint cycles roles  powerpoint ppt templates.
Scrum process sprint cycles roles powerpoint ppt templates.
 
Scrum strategy sprint cycles roles powerpoint presentation templates.
Scrum strategy sprint cycles roles  powerpoint presentation templates.Scrum strategy sprint cycles roles  powerpoint presentation templates.
Scrum strategy sprint cycles roles powerpoint presentation templates.
 
Scrum strategy sprint cycles roles powerpoint presentation slides.
Scrum strategy sprint cycles roles  powerpoint presentation slides.Scrum strategy sprint cycles roles  powerpoint presentation slides.
Scrum strategy sprint cycles roles powerpoint presentation slides.
 
Scrum strategy powerpoint presentation templates.
Scrum strategy powerpoint presentation templates.Scrum strategy powerpoint presentation templates.
Scrum strategy powerpoint presentation templates.
 
Scrum strategy powerpoint ppt slides.
Scrum strategy powerpoint ppt slides.Scrum strategy powerpoint ppt slides.
Scrum strategy powerpoint ppt slides.
 
Scrum process sprint cycles roles powerpoint presentation slides.
Scrum process sprint cycles roles  powerpoint presentation slides.Scrum process sprint cycles roles  powerpoint presentation slides.
Scrum process sprint cycles roles powerpoint presentation slides.
 
Scrum process powerpoint presentation slides.
Scrum process powerpoint presentation slides.Scrum process powerpoint presentation slides.
Scrum process powerpoint presentation slides.
 
Introduction To Agile
Introduction To AgileIntroduction To Agile
Introduction To Agile
 
Rawsthorne | Who is your PO
Rawsthorne | Who is your PORawsthorne | Who is your PO
Rawsthorne | Who is your PO
 
Introduction to Agile & Scrum
Introduction to Agile & ScrumIntroduction to Agile & Scrum
Introduction to Agile & Scrum
 
Conscires intro to scrum webinar
Conscires intro to scrum webinarConscires intro to scrum webinar
Conscires intro to scrum webinar
 
Intro to scrum webinar
Intro to scrum webinar Intro to scrum webinar
Intro to scrum webinar
 
Intro to scrum webinar
Intro to scrum webinar Intro to scrum webinar
Intro to scrum webinar
 
Conscires intro to scrum webinar
Conscires intro to scrum webinarConscires intro to scrum webinar
Conscires intro to scrum webinar
 
Introduction to Agile & Scrum
Introduction to Agile & ScrumIntroduction to Agile & Scrum
Introduction to Agile & Scrum
 
Agiletools
AgiletoolsAgiletools
Agiletools
 
Scaling Scrum with UX
Scaling Scrum with UXScaling Scrum with UX
Scaling Scrum with UX
 
Ken Schwaber chez Microsoft pour le French Scrum User Group
Ken Schwaber chez Microsoft pour le French Scrum User GroupKen Schwaber chez Microsoft pour le French Scrum User Group
Ken Schwaber chez Microsoft pour le French Scrum User Group
 

Ähnlich wie Aras PLM Software Implementation Methodology

Agile transformation best practices
Agile transformation best practicesAgile transformation best practices
Agile transformation best practicesAllyson Chiarini
 
Introduction to lean and agile
Introduction to lean and agileIntroduction to lean and agile
Introduction to lean and agileTerry Bunio
 
Agile SCRUM Methodology
Agile SCRUM MethodologyAgile SCRUM Methodology
Agile SCRUM MethodologyAngelin R
 
Working with Agile technologies and SCRUM
Working with Agile technologies and SCRUMWorking with Agile technologies and SCRUM
Working with Agile technologies and SCRUMAndrea Tino
 
Agile Requirements by Agile Analysts
Agile Requirements by Agile AnalystsAgile Requirements by Agile Analysts
Agile Requirements by Agile AnalystsKurt Solarte
 
How product designer work in agile scrum team
How product designer work in agile scrum teamHow product designer work in agile scrum team
How product designer work in agile scrum teamMike Li
 
Project Management With Scrum
Project Management With ScrumProject Management With Scrum
Project Management With ScrumTommy Norman
 
Scrum Framework in Agile
Scrum Framework in AgileScrum Framework in Agile
Scrum Framework in AgileWipro
 
Aras Innovator PLM Deployment Methodology
Aras Innovator PLM Deployment MethodologyAras Innovator PLM Deployment Methodology
Aras Innovator PLM Deployment MethodologyAras
 
Product Development using Agile Teams: What? Why? How?
Product Development using Agile Teams: What? Why? How?Product Development using Agile Teams: What? Why? How?
Product Development using Agile Teams: What? Why? How?Brad J. Neiman, MS, CSPO, CSM
 
Flexibility in Software Development Methodologies: Needs and Benefits
Flexibility in Software Development Methodologies: Needs and BenefitsFlexibility in Software Development Methodologies: Needs and Benefits
Flexibility in Software Development Methodologies: Needs and BenefitsCognizant
 
Agile Process Introduction
Agile Process IntroductionAgile Process Introduction
Agile Process IntroductionNguyen Hai
 
How we use SCRUM @ Bluegrass Digital
How we use SCRUM @ Bluegrass DigitalHow we use SCRUM @ Bluegrass Digital
How we use SCRUM @ Bluegrass DigitalMark Hawkins
 
scrum-1-10.pptx
scrum-1-10.pptxscrum-1-10.pptx
scrum-1-10.pptxheelojr
 

Ähnlich wie Aras PLM Software Implementation Methodology (20)

Agile transformation best practices
Agile transformation best practicesAgile transformation best practices
Agile transformation best practices
 
Introduction to lean and agile
Introduction to lean and agileIntroduction to lean and agile
Introduction to lean and agile
 
Agile SCRUM Methodology
Agile SCRUM MethodologyAgile SCRUM Methodology
Agile SCRUM Methodology
 
Working with Agile technologies and SCRUM
Working with Agile technologies and SCRUMWorking with Agile technologies and SCRUM
Working with Agile technologies and SCRUM
 
Agile Requirements by Agile Analysts
Agile Requirements by Agile AnalystsAgile Requirements by Agile Analysts
Agile Requirements by Agile Analysts
 
Seminar On Scrum
Seminar On  ScrumSeminar On  Scrum
Seminar On Scrum
 
Seminar on Scrum
Seminar  on  ScrumSeminar  on  Scrum
Seminar on Scrum
 
How product designer work in agile scrum team
How product designer work in agile scrum teamHow product designer work in agile scrum team
How product designer work in agile scrum team
 
Project Management With Scrum
Project Management With ScrumProject Management With Scrum
Project Management With Scrum
 
Agile
AgileAgile
Agile
 
Scrum Framework in Agile
Scrum Framework in AgileScrum Framework in Agile
Scrum Framework in Agile
 
Aras Innovator PLM Deployment Methodology
Aras Innovator PLM Deployment MethodologyAras Innovator PLM Deployment Methodology
Aras Innovator PLM Deployment Methodology
 
Product Development using Agile Teams: What? Why? How?
Product Development using Agile Teams: What? Why? How?Product Development using Agile Teams: What? Why? How?
Product Development using Agile Teams: What? Why? How?
 
Scrum and Agile SDLC 101
Scrum and Agile SDLC 101Scrum and Agile SDLC 101
Scrum and Agile SDLC 101
 
Flexibility in Software Development Methodologies: Needs and Benefits
Flexibility in Software Development Methodologies: Needs and BenefitsFlexibility in Software Development Methodologies: Needs and Benefits
Flexibility in Software Development Methodologies: Needs and Benefits
 
Agile Process Introduction
Agile Process IntroductionAgile Process Introduction
Agile Process Introduction
 
Azure dev ops
Azure dev opsAzure dev ops
Azure dev ops
 
How we use SCRUM @ Bluegrass Digital
How we use SCRUM @ Bluegrass DigitalHow we use SCRUM @ Bluegrass Digital
How we use SCRUM @ Bluegrass Digital
 
Iss 05
Iss 05Iss 05
Iss 05
 
scrum-1-10.pptx
scrum-1-10.pptxscrum-1-10.pptx
scrum-1-10.pptx
 

Mehr von Aras

Implementing PLM in the Fast-Paced, Innovation Driven Prepared Foods Industry
Implementing PLM in the Fast-Paced, Innovation Driven Prepared Foods IndustryImplementing PLM in the Fast-Paced, Innovation Driven Prepared Foods Industry
Implementing PLM in the Fast-Paced, Innovation Driven Prepared Foods IndustryAras
 
Strategic BOM Management
Strategic BOM ManagementStrategic BOM Management
Strategic BOM ManagementAras
 
Client Technology Directions
Client Technology DirectionsClient Technology Directions
Client Technology DirectionsAras
 
Aras Vision and Roadmap 2016
Aras Vision and Roadmap 2016Aras Vision and Roadmap 2016
Aras Vision and Roadmap 2016Aras
 
Aras Community Update 2016
Aras Community Update 2016Aras Community Update 2016
Aras Community Update 2016Aras
 
MBSE and the Business of Engineering
MBSE and the Business of EngineeringMBSE and the Business of Engineering
MBSE and the Business of EngineeringAras
 
Beyond ECAD Connectors
Beyond ECAD ConnectorsBeyond ECAD Connectors
Beyond ECAD ConnectorsAras
 
The PLM Journey of Justifying Change with Strategic Vision
The PLM Journey of Justifying Change with Strategic VisionThe PLM Journey of Justifying Change with Strategic Vision
The PLM Journey of Justifying Change with Strategic VisionAras
 
The Impact of IoT on Product Design
The Impact of IoT on Product DesignThe Impact of IoT on Product Design
The Impact of IoT on Product DesignAras
 
Enterprise Agile Deployment
Enterprise Agile DeploymentEnterprise Agile Deployment
Enterprise Agile DeploymentAras
 
Taking Manufacturing Process Planning to the Next Level
Taking Manufacturing Process Planning to the Next LevelTaking Manufacturing Process Planning to the Next Level
Taking Manufacturing Process Planning to the Next LevelAras
 
Quality Systems
Quality SystemsQuality Systems
Quality SystemsAras
 
Variant Management
Variant ManagementVariant Management
Variant ManagementAras
 
The Power of Self Service Reporting
The Power of Self Service ReportingThe Power of Self Service Reporting
The Power of Self Service ReportingAras
 
Making users More Productive with Enterprise Search
Making users More Productive with Enterprise SearchMaking users More Productive with Enterprise Search
Making users More Productive with Enterprise SearchAras
 
Understanding the New Content Modeling Framework
Understanding the New Content Modeling FrameworkUnderstanding the New Content Modeling Framework
Understanding the New Content Modeling FrameworkAras
 
Technical Documentation for Technical Publications
Technical Documentation for Technical PublicationsTechnical Documentation for Technical Publications
Technical Documentation for Technical PublicationsAras
 
Supplier Exchange Portal
Supplier Exchange PortalSupplier Exchange Portal
Supplier Exchange PortalAras
 
Quality Planning for Product Risk Management
Quality Planning for Product Risk ManagementQuality Planning for Product Risk Management
Quality Planning for Product Risk ManagementAras
 
How to Configure Tech Docs
How to Configure Tech DocsHow to Configure Tech Docs
How to Configure Tech DocsAras
 

Mehr von Aras (20)

Implementing PLM in the Fast-Paced, Innovation Driven Prepared Foods Industry
Implementing PLM in the Fast-Paced, Innovation Driven Prepared Foods IndustryImplementing PLM in the Fast-Paced, Innovation Driven Prepared Foods Industry
Implementing PLM in the Fast-Paced, Innovation Driven Prepared Foods Industry
 
Strategic BOM Management
Strategic BOM ManagementStrategic BOM Management
Strategic BOM Management
 
Client Technology Directions
Client Technology DirectionsClient Technology Directions
Client Technology Directions
 
Aras Vision and Roadmap 2016
Aras Vision and Roadmap 2016Aras Vision and Roadmap 2016
Aras Vision and Roadmap 2016
 
Aras Community Update 2016
Aras Community Update 2016Aras Community Update 2016
Aras Community Update 2016
 
MBSE and the Business of Engineering
MBSE and the Business of EngineeringMBSE and the Business of Engineering
MBSE and the Business of Engineering
 
Beyond ECAD Connectors
Beyond ECAD ConnectorsBeyond ECAD Connectors
Beyond ECAD Connectors
 
The PLM Journey of Justifying Change with Strategic Vision
The PLM Journey of Justifying Change with Strategic VisionThe PLM Journey of Justifying Change with Strategic Vision
The PLM Journey of Justifying Change with Strategic Vision
 
The Impact of IoT on Product Design
The Impact of IoT on Product DesignThe Impact of IoT on Product Design
The Impact of IoT on Product Design
 
Enterprise Agile Deployment
Enterprise Agile DeploymentEnterprise Agile Deployment
Enterprise Agile Deployment
 
Taking Manufacturing Process Planning to the Next Level
Taking Manufacturing Process Planning to the Next LevelTaking Manufacturing Process Planning to the Next Level
Taking Manufacturing Process Planning to the Next Level
 
Quality Systems
Quality SystemsQuality Systems
Quality Systems
 
Variant Management
Variant ManagementVariant Management
Variant Management
 
The Power of Self Service Reporting
The Power of Self Service ReportingThe Power of Self Service Reporting
The Power of Self Service Reporting
 
Making users More Productive with Enterprise Search
Making users More Productive with Enterprise SearchMaking users More Productive with Enterprise Search
Making users More Productive with Enterprise Search
 
Understanding the New Content Modeling Framework
Understanding the New Content Modeling FrameworkUnderstanding the New Content Modeling Framework
Understanding the New Content Modeling Framework
 
Technical Documentation for Technical Publications
Technical Documentation for Technical PublicationsTechnical Documentation for Technical Publications
Technical Documentation for Technical Publications
 
Supplier Exchange Portal
Supplier Exchange PortalSupplier Exchange Portal
Supplier Exchange Portal
 
Quality Planning for Product Risk Management
Quality Planning for Product Risk ManagementQuality Planning for Product Risk Management
Quality Planning for Product Risk Management
 
How to Configure Tech Docs
How to Configure Tech DocsHow to Configure Tech Docs
How to Configure Tech Docs
 

Kürzlich hochgeladen

Secure your environment with UiPath and CyberArk technologies - Session 1
Secure your environment with UiPath and CyberArk technologies - Session 1Secure your environment with UiPath and CyberArk technologies - Session 1
Secure your environment with UiPath and CyberArk technologies - Session 1DianaGray10
 
Anypoint Code Builder , Google Pub sub connector and MuleSoft RPA
Anypoint Code Builder , Google Pub sub connector and MuleSoft RPAAnypoint Code Builder , Google Pub sub connector and MuleSoft RPA
Anypoint Code Builder , Google Pub sub connector and MuleSoft RPAshyamraj55
 
UiPath Platform: The Backend Engine Powering Your Automation - Session 1
UiPath Platform: The Backend Engine Powering Your Automation - Session 1UiPath Platform: The Backend Engine Powering Your Automation - Session 1
UiPath Platform: The Backend Engine Powering Your Automation - Session 1DianaGray10
 
Machine Learning Model Validation (Aijun Zhang 2024).pdf
Machine Learning Model Validation (Aijun Zhang 2024).pdfMachine Learning Model Validation (Aijun Zhang 2024).pdf
Machine Learning Model Validation (Aijun Zhang 2024).pdfAijun Zhang
 
Artificial Intelligence & SEO Trends for 2024
Artificial Intelligence & SEO Trends for 2024Artificial Intelligence & SEO Trends for 2024
Artificial Intelligence & SEO Trends for 2024D Cloud Solutions
 
Comparing Sidecar-less Service Mesh from Cilium and Istio
Comparing Sidecar-less Service Mesh from Cilium and IstioComparing Sidecar-less Service Mesh from Cilium and Istio
Comparing Sidecar-less Service Mesh from Cilium and IstioChristian Posta
 
UiPath Studio Web workshop series - Day 8
UiPath Studio Web workshop series - Day 8UiPath Studio Web workshop series - Day 8
UiPath Studio Web workshop series - Day 8DianaGray10
 
Bird eye's view on Camunda open source ecosystem
Bird eye's view on Camunda open source ecosystemBird eye's view on Camunda open source ecosystem
Bird eye's view on Camunda open source ecosystemAsko Soukka
 
COMPUTER 10 Lesson 8 - Building a Website
COMPUTER 10 Lesson 8 - Building a WebsiteCOMPUTER 10 Lesson 8 - Building a Website
COMPUTER 10 Lesson 8 - Building a Websitedgelyza
 
IESVE Software for Florida Code Compliance Using ASHRAE 90.1-2019
IESVE Software for Florida Code Compliance Using ASHRAE 90.1-2019IESVE Software for Florida Code Compliance Using ASHRAE 90.1-2019
IESVE Software for Florida Code Compliance Using ASHRAE 90.1-2019IES VE
 
OpenShift Commons Paris - Choose Your Own Observability Adventure
OpenShift Commons Paris - Choose Your Own Observability AdventureOpenShift Commons Paris - Choose Your Own Observability Adventure
OpenShift Commons Paris - Choose Your Own Observability AdventureEric D. Schabell
 
UiPath Solutions Management Preview - Northern CA Chapter - March 22.pdf
UiPath Solutions Management Preview - Northern CA Chapter - March 22.pdfUiPath Solutions Management Preview - Northern CA Chapter - March 22.pdf
UiPath Solutions Management Preview - Northern CA Chapter - March 22.pdfDianaGray10
 
Connector Corner: Extending LLM automation use cases with UiPath GenAI connec...
Connector Corner: Extending LLM automation use cases with UiPath GenAI connec...Connector Corner: Extending LLM automation use cases with UiPath GenAI connec...
Connector Corner: Extending LLM automation use cases with UiPath GenAI connec...DianaGray10
 
Linked Data in Production: Moving Beyond Ontologies
Linked Data in Production: Moving Beyond OntologiesLinked Data in Production: Moving Beyond Ontologies
Linked Data in Production: Moving Beyond OntologiesDavid Newbury
 
UiPath Studio Web workshop series - Day 7
UiPath Studio Web workshop series - Day 7UiPath Studio Web workshop series - Day 7
UiPath Studio Web workshop series - Day 7DianaGray10
 
Apres-Cyber - The Data Dilemma: Bridging Offensive Operations and Machine Lea...
Apres-Cyber - The Data Dilemma: Bridging Offensive Operations and Machine Lea...Apres-Cyber - The Data Dilemma: Bridging Offensive Operations and Machine Lea...
Apres-Cyber - The Data Dilemma: Bridging Offensive Operations and Machine Lea...Will Schroeder
 
IaC & GitOps in a Nutshell - a FridayInANuthshell Episode.pdf
IaC & GitOps in a Nutshell - a FridayInANuthshell Episode.pdfIaC & GitOps in a Nutshell - a FridayInANuthshell Episode.pdf
IaC & GitOps in a Nutshell - a FridayInANuthshell Episode.pdfDaniel Santiago Silva Capera
 
Empowering Africa's Next Generation: The AI Leadership Blueprint
Empowering Africa's Next Generation: The AI Leadership BlueprintEmpowering Africa's Next Generation: The AI Leadership Blueprint
Empowering Africa's Next Generation: The AI Leadership BlueprintMahmoud Rabie
 
COMPUTER 10: Lesson 7 - File Storage and Online Collaboration
COMPUTER 10: Lesson 7 - File Storage and Online CollaborationCOMPUTER 10: Lesson 7 - File Storage and Online Collaboration
COMPUTER 10: Lesson 7 - File Storage and Online Collaborationbruanjhuli
 

Kürzlich hochgeladen (20)

Secure your environment with UiPath and CyberArk technologies - Session 1
Secure your environment with UiPath and CyberArk technologies - Session 1Secure your environment with UiPath and CyberArk technologies - Session 1
Secure your environment with UiPath and CyberArk technologies - Session 1
 
Anypoint Code Builder , Google Pub sub connector and MuleSoft RPA
Anypoint Code Builder , Google Pub sub connector and MuleSoft RPAAnypoint Code Builder , Google Pub sub connector and MuleSoft RPA
Anypoint Code Builder , Google Pub sub connector and MuleSoft RPA
 
UiPath Platform: The Backend Engine Powering Your Automation - Session 1
UiPath Platform: The Backend Engine Powering Your Automation - Session 1UiPath Platform: The Backend Engine Powering Your Automation - Session 1
UiPath Platform: The Backend Engine Powering Your Automation - Session 1
 
Machine Learning Model Validation (Aijun Zhang 2024).pdf
Machine Learning Model Validation (Aijun Zhang 2024).pdfMachine Learning Model Validation (Aijun Zhang 2024).pdf
Machine Learning Model Validation (Aijun Zhang 2024).pdf
 
Artificial Intelligence & SEO Trends for 2024
Artificial Intelligence & SEO Trends for 2024Artificial Intelligence & SEO Trends for 2024
Artificial Intelligence & SEO Trends for 2024
 
Comparing Sidecar-less Service Mesh from Cilium and Istio
Comparing Sidecar-less Service Mesh from Cilium and IstioComparing Sidecar-less Service Mesh from Cilium and Istio
Comparing Sidecar-less Service Mesh from Cilium and Istio
 
UiPath Studio Web workshop series - Day 8
UiPath Studio Web workshop series - Day 8UiPath Studio Web workshop series - Day 8
UiPath Studio Web workshop series - Day 8
 
Bird eye's view on Camunda open source ecosystem
Bird eye's view on Camunda open source ecosystemBird eye's view on Camunda open source ecosystem
Bird eye's view on Camunda open source ecosystem
 
COMPUTER 10 Lesson 8 - Building a Website
COMPUTER 10 Lesson 8 - Building a WebsiteCOMPUTER 10 Lesson 8 - Building a Website
COMPUTER 10 Lesson 8 - Building a Website
 
IESVE Software for Florida Code Compliance Using ASHRAE 90.1-2019
IESVE Software for Florida Code Compliance Using ASHRAE 90.1-2019IESVE Software for Florida Code Compliance Using ASHRAE 90.1-2019
IESVE Software for Florida Code Compliance Using ASHRAE 90.1-2019
 
OpenShift Commons Paris - Choose Your Own Observability Adventure
OpenShift Commons Paris - Choose Your Own Observability AdventureOpenShift Commons Paris - Choose Your Own Observability Adventure
OpenShift Commons Paris - Choose Your Own Observability Adventure
 
UiPath Solutions Management Preview - Northern CA Chapter - March 22.pdf
UiPath Solutions Management Preview - Northern CA Chapter - March 22.pdfUiPath Solutions Management Preview - Northern CA Chapter - March 22.pdf
UiPath Solutions Management Preview - Northern CA Chapter - March 22.pdf
 
Connector Corner: Extending LLM automation use cases with UiPath GenAI connec...
Connector Corner: Extending LLM automation use cases with UiPath GenAI connec...Connector Corner: Extending LLM automation use cases with UiPath GenAI connec...
Connector Corner: Extending LLM automation use cases with UiPath GenAI connec...
 
20150722 - AGV
20150722 - AGV20150722 - AGV
20150722 - AGV
 
Linked Data in Production: Moving Beyond Ontologies
Linked Data in Production: Moving Beyond OntologiesLinked Data in Production: Moving Beyond Ontologies
Linked Data in Production: Moving Beyond Ontologies
 
UiPath Studio Web workshop series - Day 7
UiPath Studio Web workshop series - Day 7UiPath Studio Web workshop series - Day 7
UiPath Studio Web workshop series - Day 7
 
Apres-Cyber - The Data Dilemma: Bridging Offensive Operations and Machine Lea...
Apres-Cyber - The Data Dilemma: Bridging Offensive Operations and Machine Lea...Apres-Cyber - The Data Dilemma: Bridging Offensive Operations and Machine Lea...
Apres-Cyber - The Data Dilemma: Bridging Offensive Operations and Machine Lea...
 
IaC & GitOps in a Nutshell - a FridayInANuthshell Episode.pdf
IaC & GitOps in a Nutshell - a FridayInANuthshell Episode.pdfIaC & GitOps in a Nutshell - a FridayInANuthshell Episode.pdf
IaC & GitOps in a Nutshell - a FridayInANuthshell Episode.pdf
 
Empowering Africa's Next Generation: The AI Leadership Blueprint
Empowering Africa's Next Generation: The AI Leadership BlueprintEmpowering Africa's Next Generation: The AI Leadership Blueprint
Empowering Africa's Next Generation: The AI Leadership Blueprint
 
COMPUTER 10: Lesson 7 - File Storage and Online Collaboration
COMPUTER 10: Lesson 7 - File Storage and Online CollaborationCOMPUTER 10: Lesson 7 - File Storage and Online Collaboration
COMPUTER 10: Lesson 7 - File Storage and Online Collaboration
 

Aras PLM Software Implementation Methodology

  • 1. BEDIFFERENT ACE GERMANY Copyright © 2012 Aras. All Rights Reserved. aras.com
  • 2. ACE Germany Implementation Best Practices Scrum Methodology Patrick Willemsen Senior Consultant ARAS Software AG Copyright © 2012 Aras. All Rights Reserved. aras.com
  • 3. Dilbert says Copyright © 2012 Aras. All Rights Reserved. Slide 3 aras.com
  • 4. Agenda  Agile Methodology – An Overview  Agile Methodology – Applied  Questions Copyright © 2012 Aras. All Rights Reserved. Slide 4 aras.com
  • 5. What is Agile?  Agile is an iterative software development methodology that promotes open collaboration and process adaptability through the life cycle of the project  Is beneficial on projects with many unknowns  Scrum is a framework within Agile methodology Copyright © 2012 Aras. All Rights Reserved. Slide 5 aras.com
  • 6. What Characterizes the Agile Process?  Collaboration and communication  High level of participation and transparency to the users  Dedicated, cross-functional team(s)  Self-organized, where everyone participates in decision making  Development is planned in stages by team members  Testing and documentation are done as you go  Users see working product sooner Copyright © 2012 Aras. All Rights Reserved. Slide 6 aras.com
  • 7. Agile Development Scrum Use Cases (Requirements) Product Product backlog Sprint backlog increment n days UC001 UC003 UC015 … Sprint Copyright © 2012 Aras. All Rights Reserved. Slide 7 aras.com
  • 8. Product Backlog  High-level document for the entire project  Contains backlog items:  brief use case descriptions  wish-list items  prioritized/ranked by business value  The product backlog is property of the Product Owner  Business value is set by the Product Owner http://en.wikipedia.org/wiki/Scrum_(development) Copyright © 2012 Aras. All Rights Reserved. aras.com
  • 9. Product Owner  Represents the voice of the customer and ensures that the Scrum Team works with the "right things" from a business perspective  The Product Owner collects use cases, requirements, prioritizes them, then places them in the product backlog Business Perspective Copyright © 2012 Aras. All Rights Reserved. aras.com
  • 10. Sprint Team Product owner Sprint team Customer Consultant(s) Process owner(s) Architect(s) Scrum master Copyright © 2012 Aras. All Rights Reserved. aras.com
  • 11. Scrum Master  Primary job is to remove obstacles to the ability of the team to deliver the sprint goal  Is not the leader of the team (as the team is self- organizing) but acts as a buffer between the team and any distracting influences  Ensures that the Scrum process is used as intended. The Scrum Master is the enforcer of rules  A key part of the Scrum Masters role is to protect the team and keep them focused on the tasks at hand Copyright © 2012 Aras. All Rights Reserved. aras.com
  • 12. The Team  Has responsibility to deliver the product increment  All team members are responsible to deliver a complete and consistent sprint result  Team is self-organizing in terms of  Task assignment  Task order  Availability  With sprint planning it commits itself to deliver the communicated results  A team is typically made up of up to 6 people Copyright © 2012 Aras. All Rights Reserved. aras.com
  • 13. SCRUM Detailed • Product backlog • Sprint backlog Scrum master Start • Scrum Part 1 Sprint planning Product owner Requirements definition 2 Consultant(s) Customer representatives Product 5 Result presentation increment Demo 4 Implementation Solution specification Sprint 3 n days Architect Copyright © 2012 Aras. All Rights Reserved. aras.com
  • 14. Meetings (1) At the beginning of a sprint cycle resp. daily Meeting Topics Planning  Select what work is to be done limit: 2h  Prepare the sprint backlog that details the time it will take to do that work, with the entire team  Identify and communicate how much of the work is likely to be done during the current sprint  Input: Product Backlog  Result: Sprint Backlog Scrum (Daily)  What have you done since yesterday?  What are you planning to do by today? limit: 15 min  Do you have any problems preventing you from accomplishing your goal? Copyright © 2012 Aras. All Rights Reserved. aras.com
  • 15. Meetings (2) At the end of a sprint cycle Meeting Topics Review (demo)  Present the completed work to the stakeholders (a.k.a. "the demo") limit: 2h  Incomplete work cannot be demonstrated Review (sessions)  Review the work that was completed and not completed by the sprint team limit: 2h Retrospective  All team members reflect on the past sprint limit: 1h  Make continuous process improvement  Two main questions are asked in the sprint retrospective: What went well during the sprint? What could be improved in the next sprint? Copyright © 2012 Aras. All Rights Reserved. aras.com
  • 16. Sprint Backlog  Detailed document containing information about how the team is going to implement the use cases / requirements for the upcoming sprint.  The document contains the availability of the team members during the sprint period.  Work list broken down into doable tasks (between 2 and 8 hours of work). With this level of detail the whole team understands exactly what to do, and anyone can potentially pick a task from the list.  Tasks on the sprint backlog are never assigned by a team lead; rather, tasks are signed up for by the team members as needed, according to the set priority and the team member skills (Self organizing team).  The sprint backlog is property of the Team. Estimations are set by the Team. http://en.wikipedia.org/wiki/Scrum_(development) Copyright © 2012 Aras. All Rights Reserved. aras.com
  • 17. Burn Down Chart  The burn down chart is a publicly displayed chart showing remaining work in the sprint backlog. Updated every day, it gives a simple view of the sprint progress. It also provides quick visualizations for reference.  It should not be confused with an earned value chart. http://en.wikipedia.org/wiki/Scrum_(development) Copyright © 2012 Aras. All Rights Reserved. aras.com
  • 18. OK, GREAT! Now how does this apply to Aras Innovator? Copyright © 2012 Aras. All Rights Reserved. aras.com
  • 19. Implementation Methodology  Aras Innovator is ideally suited for an iterative approach:  Rational Unified Process • Best Practice Presentation ACE 2010 International • Starting Your Aras Implementation ACE 2011 International  Agile / Scrum Software Development • Aras Innovator Deployment Methodology ACE 2012 Germany • wikipedia http://en.wikipedia.org/wiki/Agile_software_development Starting Your Aras Implementation ACE 2011 International Copyright © 2012 Aras. All Rights Reserved. Slide 19 aras.com
  • 20. Aras Methodology Overview  Designed to use the “Small Win” approach  Take a well defined problem(s) and implement with less risk and a higher degree of confidence  Implement a series of product increments (production) releases that comprise the complete solution  Each product increment provides value to the business  Scope each increment to be completed in a defined number of sprints Copyright © 2012 Aras. All Rights Reserved. Slide 20 aras.com
  • 21. Discovery Workshop Customer investigation SoW Customer workshop Result order Business process analysis Process description Business entity model definition Solution description Solution mockup Solution proposal Main Requirements Brief use cases Data model (high level) System architecture Scope of work Project definition Copyright © 2012 Aras. All Rights Reserved. Slide 21 aras.com
  • 22. Use Case Workshops Discovery Workshop Use Case and Design Workshops Product UC001 Customer backlog SoW project order UC001 UC004 UC003 UC003 UC015 … UCnnn Process description Detailed use cases Solution description Requirement definition Solution proposal System design Brief use cases … Copyright © 2012 Aras. All Rights Reserved. Slide 22 aras.com
  • 23. Sprint Plan Discovery Workshops Product backlog System Requirements High Level Use Non-functional UC001 UC003 Architecture definition Cases requirements UC015 … Part & BOM Sprint 1 Management Implementation Test Requirements Requirements Product increment Part & BOM Sprint 2 Management Implementation Test Product increment Change Sprint 3 Management Implementation Test Program and Sprint 4 Project Implementation Test Management Copyright © 2012 Aras. All Rights Reserved. Slide 23 aras.com
  • 24. Part & BOM Management Example Topics System  Requirements Definition  Visual Prototypes  Use case definition  Data model  Numbering scheme  Life cycle  Workflow  Permissions  Revisioning and sequence  Relationships to other items (Part, CAD, documents, …) Copyright © 2012 Aras. All Rights Reserved. Slide 24 aras.com
  • 25. Implementation Sprint Result Presentation  Develop product increment  Live Demo  Write agile documentation  Maintain product backlog Copyright © 2012 Aras. All Rights Reserved. Slide 25 aras.com
  • 26. Final Thoughts  DO  Develop accurate Use Cases and keep them up to date as you go  Prioritize use cases and requirements  Look for “Small Wins” that provide business value  Create visual prototypes and get user validation before developing any method code  Take result presentations seriously: prepare well, show and discuss product increments  DON’T  Spend a significant amount of time developing specifications without prototyping the solution  Worry about not getting 100% of the detailed requirements up front: Iterate! Copyright © 2012 Aras. All Rights Reserved. Slide 26 aras.com
  • 27. ACE Germany Questions ? Patrick Willemsen Senior Consultant ARAS Software AG Copyright © 2012 Aras. All Rights Reserved. aras.com
  • 28. Scrum Project Management Copyright © 2012 Aras. All Rights Reserved. aras.com
  • 29. Project Management Agile Project Management with Scrum  Scrum has not only reinforced the interest in software project management, but also challenged the conventional ideas about such management.  Scrum focuses on project management institutions where it is difficult to plan ahead with mechanisms for empirical process control, such as where feedback loops constitute the core element of product development compared to traditional command-and-control- oriented management.  It represents a radically new approach for planning and managing software projects, bringing decision-making authority to the level of operation properties and certainties.  Scrum reduces defects and makes the development process more efficient, as well as reducing long-term maintenance costs. Copyright © 2012 Aras. All Rights Reserved. Slide 29 aras.com
  • 30. Modeling Basics Use Cases Copyright © 2012 Aras. All Rights Reserved. aras.com
  • 31. Definition (1)  A use case is the specification of a set of actions performed by a system which yields an observable result that is of value to one or more actors or other stakeholders of the system UML 2.0 Specification Copyright © 2012 Aras. All Rights Reserved. aras.com
  • 32. Definition (2)  Use Cases  Use cases are a documentation technique  Use case is a story of using a system to fulfill a goal  Use cases capture functional requirements  Use cases are not diagrams, they are text  Use cases are requirements  Use cases define a contract how the system will behave  Use case model is the set of all use cases  Use cases emphasize the user goals and perspectives  Use Cases do not  Specify user interface design. They specify the intent, not the action detail  Specify implementation detail (unless it is of particular importance to the actor to be assured that the goal is properly met) Copyright © 2012 Aras. All Rights Reserved. aras.com
  • 33. Definition (3)  Name starts with a verb  Create Part  Search on Classification Attributes  Release Part  Assign Review Participants Copyright © 2012 Aras. All Rights Reserved. aras.com
  • 34. Definition (4)  Find the right use case level “A task performed by one person in one place at one time, in response to a business event, which adds measurable business value and leaves the data in a consistent state.”  Known as Elementary Business Process (EBP, also known as user-level goal use cases)  An EBP-level use case usually is composed of several steps, not just one or two Copyright © 2012 Aras. All Rights Reserved. aras.com
  • 35. “Boss Test”  The "boss test" is a naïve approach for determining whether an activity qualifies as an elementary business process.  For example, consider this dialog:  Boss: "What did you do all day today?“  Employee: "I logged in.“  Is the boss happy?  In general, an EBP-level use case usually involves many steps, not just one or two. Copyright © 2012 Aras. All Rights Reserved. aras.com
  • 36. Level of Detail Casual use case  Consists of a few paragraphs of text, summarizing the use case. Brief use case (Cloud level)  Consists of a few sentences summarizing the use case. It can be easily inserted in a spreadsheet cell, and allows the other columns in the spreadsheet to record priority, technical complexity, release number, and so on. Fully dressed use case (Sea level)  Is a formal document based on a detailed template with fields for various sections; and it is the most common understanding of the meaning of a use case. Copyright © 2012 Aras. All Rights Reserved. aras.com
  • 37. Brief Use Case Example  Use Case Name:  Release CAD Drawing  Actors:  Designated User (CMII)  System  Use Case Description: The user selects one or more drawings to be released and then releases the items. The system checks if all release mandatory information – meta data as well as CAD files – has been entered by the user and verifies that all related CAD models have been released. The system shows success or failure to the user. After the release, the system shall create a neutral file format. Copyright © 2012 Aras. All Rights Reserved. Slide 37 aras.com
  • 38. Fully-Dressed  Use case name  Extensions  Brief description  alternate scenarios of success and failure  Scope  Frequency of occurrence  Primary actor  Daily, Weekly, Monthly, Quarterly,  Stakeholders and interests Yearly  who cares about this use case, and  Complexity what do they want?  Concerning logic which corresponds  Preconditions to implementation effort  what must be true on start?  Easy (OOTB), Medium (small  Success guarantee enhancements), Difficult (complex logic) (Post conditions)  what must be true on successful  Miscellaneous completion?  Main success scenario  typical path, happy path alistair.cockburn.us Copyright © 2012 Aras. All Rights Reserved. aras.com
  • 39. Diagrams (1)  UML has use case diagrams  Use cases are text, not diagrams  Use case analysis is a writing effort, not drawing  But a short time drawing a use case diagram provides a context for:  identifying use cases by name  creating a “context diagram” Copyright © 2012 Aras. All Rights Reserved. aras.com
  • 40. Tips & Tricks  Write in an essential UI-free style  Write simple  Write black-box use cases (write what the system must do without deciding how it will be done)  Take an actor and actor-goal perspective  Define use cases properly (name, etc.)  Define more useful use cases first Copyright © 2012 Aras. All Rights Reserved. aras.com
  • 41. Common Problems  The following is a list of the most common problems in writing requirements:  Making bad assumptions  Writing implementation (HOW) instead of requirements (WHAT)  Describing operations instead of writing requirements  Using incorrect terms  Using incorrect sentence structure or bad grammar  Missing requirements  Over-specifying Copyright © 2012 Aras. All Rights Reserved. aras.com
  • 42. Modeling Basics Requirements Copyright © 2012 Aras. All Rights Reserved. aras.com
  • 43. Definition  User Requirements  Statements of fact and assumptions that define the expectations of the system in terms of mission objectives, environment, constraints, and measures of effectiveness and suitability (MOE/MOS)  Functional Requirements  Functional requirements explain what has to be done by identifying the necessary task, action or activity that must be accomplished  Non-Functional Requirements  Specify criteria that can be used to judge the operation of a system, rather than specific behaviors. Non-functional requirements are often called qualities of a system. http://en.wikipedia.org/wiki/Non-functional_requirement Copyright © 2012 Aras. All Rights Reserved. aras.com
  • 44. Terminology (1)  In a specification, there are terms to be avoided and terms that must be used in a very specific manner. Authors need to understand the use of shall, will, and should:  Requirements use shall  Statements of fact use will  Goals use should  Terms such as are, is, and was do not belong in a requirement. The term must shall be handled consciously. Are, is and was may be used in a descriptive section or in the lead-in to a requirements section of the specification. Copyright © 2012 Aras. All Rights Reserved. aras.com
  • 45. Terminology (2)  There are a number of terms to be avoided in writing requirements, because they confuse the issue and can cost you money, e.g.  Support  But not limited to  Etc.  And/or Copyright © 2012 Aras. All Rights Reserved. aras.com
  • 46. Terminology (3)  Requirements should be easy to read and understand. The requirements in a system specification are either for the system or its next level, e.g. subsystem. Each requirement can usually be written in the format:  The System shall provide ........  The System shall be capable of ........  The System shall weigh ........  The Subsystem #1 shall provide ........  The Subsystem #2 shall interface with .....  It is required that … Copyright © 2012 Aras. All Rights Reserved. aras.com
  • 47. Terminology (4) Ambiguous Terms Ways to Improve Them acceptable, adequate Define what constitutes acceptability and how the system can judge this. as much as practicable Don't leave it up to the developers to determine what's practicable. Make it a TBD and set a date to find out. at least, at a minimum, Specify the minimum and maximum acceptable not more than, not to values. exceed between Define whether the end points are included in the range. depends on Describe the nature of the dependency. Does another system provide input to this system, must other software be installed before your software can run, or does your system rely on another one to perform some calculations or services? Copyright © 2012 Aras. All Rights Reserved. aras.com
  • 48. Terminology (5) Ambiguous Terms Ways to Improve Them efficient Define how efficiently the system uses resources, how quickly it performs specific operations, or how easy it is for people to use. flexible Describe the ways in which the system must change in response to changing conditions or business needs. improved, better, faster, Quantify how much better or faster constitutes superior adequate improvement in a specific functional area. including, including but The list of items should include all possibilities. not limited to, and so Otherwise, it can't be used for design or testing. on, such as, etc. maximize, minimize, State the maximum and minimum acceptable values optimize of some parameter. normally, ideally Also describe the system's behavior under abnormal or non-ideal conditions. Copyright © 2012 Aras. All Rights Reserved. aras.com
  • 49. Terminology (6) Ambiguous Terms Ways to Improve Them optionally Clarify whether this means a system choice, a user choice, or a developer choice. reasonable, when Explain how to make this judgment. necessary, where appropriate robust Define how the system is to handle exceptions and respond to unexpected operating conditions. seamless, transparent, Translate the user's expectations into specific graceful observable product characteristics. several State how many, or provide the minimum and maximum bounds of a range. shouldn't Try to state requirements as positives, describing what the system will do. state-of-the-art Define what this means. Copyright © 2012 Aras. All Rights Reserved. aras.com
  • 50. Terminology (7) Ambiguous Terms Ways to Improve Them sufficient Specify how much of something constitutes sufficiency. support, enable Define exactly what functions the system will perform that constitute supporting some capability. user-friendly, simple, Describe system characteristics that will achieve the easy customer's usage needs and usability expectations Copyright © 2012 Aras. All Rights Reserved. aras.com