Post on 10-May-2015
transcript
aras.com Copyright © 2012 Aras. All Rights Reserved.
A C E G E R M A N Y
BEDIFFERENT
aras.com Copyright © 2012 Aras. All Rights Reserved.
ACE
Germany
Implementation Best Practices Scrum Methodology
Patrick Willemsen Senior Consultant
ARAS Software AG
aras.com Copyright © 2012 Aras. All Rights Reserved.
Dilbert says
Slide 3
aras.com Copyright © 2012 Aras. All Rights Reserved.
Agenda
Agile Methodology – An Overview
Agile Methodology – Applied
Questions
Slide 4
aras.com Copyright © 2012 Aras. All Rights Reserved.
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
Slide 5
aras.com Copyright © 2012 Aras. All Rights Reserved.
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
Slide 6
aras.com Copyright © 2012 Aras. All Rights Reserved.
Agile Development
Slide 7
Product backlog Sprint backlog
Scrum
Product increment
Sprint
n days
Use Cases (Requirements)
UC001 UC003 UC015
…
aras.com Copyright © 2012 Aras. All Rights Reserved.
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)
aras.com Copyright © 2012 Aras. All Rights Reserved.
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
aras.com Copyright © 2012 Aras. All Rights Reserved.
Sprint Team
Product owner
Sprint team
Scrum master
Customer Process owner(s)
Consultant(s)
Architect(s)
aras.com Copyright © 2012 Aras. All Rights Reserved.
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
aras.com Copyright © 2012 Aras. All Rights Reserved.
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
aras.com Copyright © 2012 Aras. All Rights Reserved.
SCRUM Detailed
• Product backlog • Sprint backlog
Sprint n days
1
Sprint planning
Requirements definition 2
Sta
rt
3
Solution specification
4 Implementation
Part
Result presentation
Demo
Consultant(s) Customer representatives
Scrum master
Architect
Product owner
• Scrum
5 Product increment
aras.com Copyright © 2012 Aras. All Rights Reserved.
Meetings (1)
Meeting Topics
Planning 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
Scrum (Daily) 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?
limit: 2h
limit: 15 min
At the beginning of a sprint cycle resp. daily
aras.com Copyright © 2012 Aras. All Rights Reserved.
Meetings (2)
Meeting Topics
Review (demo) Present the completed work to the stakeholders (a.k.a. "the demo")
Incomplete work cannot be demonstrated
Review (sessions)
Review the work that was completed and not completed by the sprint team
Retrospective 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?
limit: 2h
limit: 2h
limit: 1h
At the end of a sprint cycle
aras.com Copyright © 2012 Aras. All Rights Reserved.
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)
aras.com Copyright © 2012 Aras. All Rights Reserved.
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)
aras.com Copyright © 2012 Aras. All Rights Reserved.
Now how does this apply to Aras Innovator?
OK, GREAT!
aras.com Copyright © 2012 Aras. All Rights Reserved.
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
Slide 19
Starting Your Aras Implementation
ACE 2011 International
aras.com Copyright © 2012 Aras. All Rights Reserved.
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
Slide 20
aras.com Copyright © 2012 Aras. All Rights Reserved.
Discovery Workshop
Slide 21
SoW
Customer investigation
Process description Solution description Solution proposal Main Requirements Brief use cases Data model (high level) System architecture Scope of work Project definition
Business process analysis Business entity model definition Solution mockup
Customer workshop
order Result
aras.com Copyright © 2012 Aras. All Rights Reserved.
UC001 UC003 UC015
…
Use Case Workshops
Slide 22
SoW
Detailed use cases Requirement definition System design
Product backlog
Discovery Workshop
Process description Solution description Solution proposal Brief use cases …
UC001
UC003 UC004
UCnnn
Customer project order
Use Case and Design Workshops
aras.com Copyright © 2012 Aras. All Rights Reserved.
Sprint Plan
System Architecture
High Level Use Cases
Non-functional requirements
Sprint 1 Part & BOM Management
Implementation Test
Sprint 2 Part & BOM Management
Implementation Test
Sprint 3 Change Management
Implementation Test
Sprint 4 Program and
Project Management
Implementation Test
Slide 23
Product increment
Product increment
Product backlog
UC001 UC003 UC015
…
Requirements definition
Discovery Workshops
Requirements Requirements
aras.com Copyright © 2012 Aras. All Rights Reserved.
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
Slide 24
Visual Prototypes
aras.com Copyright © 2012 Aras. All Rights Reserved.
Implementation
Sprint
Develop product increment
Write agile documentation
Maintain product backlog
Result Presentation
Live Demo
Slide 25
aras.com Copyright © 2012 Aras. All Rights Reserved.
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!
Slide 26
aras.com Copyright © 2012 Aras. All Rights Reserved.
ACE Germany
Questions?
Patrick Willemsen Senior Consultant
ARAS Software AG
aras.com Copyright © 2012 Aras. All Rights Reserved.
Project Management Scrum
aras.com Copyright © 2012 Aras. All Rights Reserved.
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.
Slide 29
aras.com Copyright © 2012 Aras. All Rights Reserved.
Use Cases Modeling Basics
aras.com Copyright © 2012 Aras. All Rights Reserved.
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
aras.com Copyright © 2012 Aras. All Rights Reserved.
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)
aras.com Copyright © 2012 Aras. All Rights Reserved.
Definition (3)
Name starts with a verb
Create Part
Search on Classification Attributes
Release Part
Assign Review Participants
aras.com Copyright © 2012 Aras. All Rights Reserved.
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
aras.com Copyright © 2012 Aras. All Rights Reserved.
“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.
aras.com Copyright © 2012 Aras. All Rights Reserved.
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.
aras.com Copyright © 2012 Aras. All Rights Reserved.
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.
Slide 37
aras.com Copyright © 2012 Aras. All Rights Reserved.
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
aras.com Copyright © 2012 Aras. All Rights Reserved.
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”
aras.com Copyright © 2012 Aras. All Rights Reserved.
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
aras.com Copyright © 2012 Aras. All Rights Reserved.
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
aras.com Copyright © 2012 Aras. All Rights Reserved.
Requirements Modeling Basics
aras.com Copyright © 2012 Aras. All Rights Reserved.
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
aras.com Copyright © 2012 Aras. All Rights Reserved.
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.
aras.com Copyright © 2012 Aras. All Rights Reserved.
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
aras.com Copyright © 2012 Aras. All Rights Reserved.
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 …
aras.com Copyright © 2012 Aras. All Rights Reserved.
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, not more than, not to exceed
Specify the minimum and maximum acceptable values.
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?
aras.com Copyright © 2012 Aras. All Rights Reserved.
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, superior
Quantify how much better or faster constitutes adequate improvement in a specific functional area.
including, including but not limited to, and so on, such as, etc.
The list of items should include all possibilities. Otherwise, it can't be used for design or testing.
maximize, minimize, optimize
State the maximum and minimum acceptable values of some parameter.
normally, ideally Also describe the system's behavior under abnormal or non-ideal conditions.
aras.com Copyright © 2012 Aras. All Rights Reserved.
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 necessary, where appropriate
Explain how to make this judgment.
robust Define how the system is to handle exceptions and respond to unexpected operating conditions.
seamless, transparent, graceful
Translate the user's expectations into specific 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.
aras.com Copyright © 2012 Aras. All Rights Reserved.
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, easy
Describe system characteristics that will achieve the customer's usage needs and usability expectations