BEDIFFERENT ACE G E R M A N Y. aras.com. Copyright 2012 Aras. All Rights Reserved.

Transcription

1 BEDIFFERENT ACE G E R M A N Y

2 ACE Germany Implementation Best Practices Scrum Methodology Patrick Willemsen Senior Consultant ARAS Software AG

3 Slide 3 Dilbert says

4 Slide 4 Agenda Agile Methodology An Overview Agile Methodology Applied Questions

5 Slide 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

6 What Characterizes the Agile Process? Copyright 2012 Aras. All Rights Reserved. Slide 6 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

7 Slide 7 Agile Development Scrum Use Cases (Requirements) Product backlog Sprint backlog n days Product increment UC001 UC003 UC015 Sprint

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

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

10 Sprint Team Product owner Sprint team Customer Process owner(s) Consultant(s) Architect(s) Scrum master

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 selforganizing) 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

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

13 Start SCRUM Detailed Product backlog Sprint backlog Scrum master Scrum Product owner Part 1 Sprint planning Requirements definition 2 Consultant(s) Customer representatives 5 Result presentation Demo Product increment 4 Implementation Solution specification 3 Sprint n days Architect

14 Meetings (1) At the beginning of a sprint cycle resp. daily Meeting Planning limit: 2h Scrum (Daily) limit: 15 min Topics Select what work is to be done 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 What have you done since yesterday? What are you planning to do by today? Do you have any problems preventing you from accomplishing your goal?

15 Meetings (2) At the end of a sprint cycle Meeting Review (demo) limit: 2h Review (sessions) limit: 2h Retrospective limit: 1h Topics Present the completed work to the stakeholders (a.k.a. "the demo") Incomplete work cannot be demonstrated Review the work that was completed and not completed by the sprint team All team members reflect on the past sprint 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?

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.

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.

18 OK, GREAT! Now how does this apply to Aras Innovator?

19 Slide 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 Starting Your Aras Implementation ACE 2011 International

20 Slide 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

21 Slide 21 Discovery Workshop Customer investigation SoW Customer workshop order Result Business process analysis Business entity model definition Solution mockup Process description Solution description Solution proposal Main Requirements Brief use cases Data model (high level) System architecture Scope of work Project definition

22 Slide 22 Use Case Workshops Discovery Workshop Use Case and Design Workshops SoW Customer project order UC004 UC003 UC001 Product backlog UC001 UC003 UC015 UCnnn Process description Solution description Solution proposal Brief use cases Detailed use cases Requirement definition System design

23 Slide 23 Sprint Plan Discovery Workshops Product backlog System Architecture Requirements definition High Level Use Cases Non-functional requirements UC001 UC003 UC015 Sprint 1 Part & BOM Management Implementation Test Sprint 2 Part & BOM Management Requirements Implementation Requirements Test Product increment Sprint 3 Change Management Implementation Test Product increment Sprint 4 Program and Project Management Implementation Test

24 Slide 24 Part & BOM Management Example Topics Requirements Definition Use case definition Data model Numbering scheme Life cycle Workflow Permissions Revisioning and sequence Relationships to other items (Part, CAD, documents, ) System Visual Prototypes

25 Slide 25 Implementation Sprint Develop product increment Write agile documentation Maintain product backlog Result Presentation Live Demo

26 Slide 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!

27 ACE Germany Questions? Patrick Willemsen Senior Consultant ARAS Software AG

28 Scrum Project Management

29 Slide 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-controloriented 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.

30 Modeling Basics Use Cases

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

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.

33 Definition (3) Name starts with a verb Create Part Search on Classification Attributes Release Part Assign Review Participants

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.

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.

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.

37 Slide 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.

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

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.

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

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

42 Modeling Basics Requirements

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.

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.

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

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

47 Terminology (4) Ambiguous Terms acceptable, adequate as much as practicable at least, at a minimum, not more than, not to exceed between depends on Ways to Improve Them Define what constitutes acceptability and how the system can judge this. Don't leave it up to the developers to determine what's practicable. Make it a TBD and set a date to find out. Specify the minimum and maximum acceptable values. Define whether the end points are included in the range. 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?

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

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

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