Agile Software Development. Stefan Balbo / Patrick Dolemieux

Transcription

1 Agile Software Development Stefan Balbo / Patrick Dolemieux

2 Content Why go Agile? Introduction to Scrum - Process - Roles Agile Estimating and Tracking Scaling Scrum Design in the Scrum Process Benefits Pitfalls and Best Practices Resources

3 Why go Agile? Development projects have progressed over time More complex More scope changes

4 Why go Agile? IT Project Survey (Standish 2009) Development process has stayed the same Inadequate process results in projects that 24% 44% 32% Success Failing Failure - Fail - Have poor quality - Are frustrating to work on - Take longer than expected

5 The Waterfall Model Requirements Design Implementation Test

6 What is Agile Software Development? The Agile Manifesto (2001): Individuals and interactions over processes and tools Working software over comprehensive documentation Customer collaboration over contract negotiation Responding to change over following a plan

7 What is Scrum? Framework - for agile software development Key concepts: - Iterative and incremental - Small self-organizing teams - Short feedback loops - Priority by business value

8 Starting a Scrum Project - Envisioning Articulate the project vision Determine and prioritize goals and objectives Define incremental releases Get vision accepted by all stakeholders

9 Mars.NET Project Vision Mars.Net is a project dedicated to the WPF.Net developer community that is aiming the following objectives: - Integrated into the ArcGIS Ecosystem - Fast Display - Small Footprint - Easy to Deploy Mars.Net is a code name The product name is ArcGIS Runtime SDK for WPF Mars logo is Project started in Q Current sprint is #26

10 Mars.Net The Context Mars.Net Android SDK ios SDK WPF SDK Java SE SDK Software Developer Kits Android API ios API WPF API Java SE API Object Models ArcGIS Runtime Core Runtime Local Server Runtime

11 Starting a Scrum Project - Release Planning Create a prioritized list of Epics Create a prioritized backlog of items (PBIs) - Tip: INVEST in your backlog - Independent, Negotiable, Valuable, Estimable, Small, Testable renjith krishnan / FreeDigitalPhotos.net Estimate the items Estimate team s velocity Calculate preliminary date Get stakeholder consensus and commitment to proceed

12 Mars.NET Releases and PBIs

13 Mars.NET Backlog description

14 Scrum Framework Product Backlog Daily Scrum Scrum Questions: Done? Do? Impediments? Iteration Planning Iteration Backlog Iteration 3 weeks Done Potentially Shippable Product Iteration Retrospective Iteration Review

15 Responsibilities of a Scrum Team Cross-Functional (5-9 members) Agrees to iteration goal and specifies work results Empowered to do anything to reach the iteration goals - within the project guideline boundaries renjith krishnan / FreeDigitalPhotos.net Organizes itself and its work Demos work results to the stakeholders

16 Product Owner Responsibilities Defines product features Prioritizes product backlog Establishes, communicates and nurtures the vision Accepts or rejects work results Grooms the product backlog Product Owner is the - vision keeper - daily decision maker - single wringable neck

17 Scrum Master (Agile Coach) Responsibilities Ensures team is productive Enables close cooperation Removes barriers Shields team from interferences Ensures the process is followed Invites to Scrum meetings The Scrum Master is the - Shepherd - Bulldozer - servant leader

18 Mars.NET The Team Product Engineers Developers Adrien (samples) Chris (Dev Lead) Dara (Doc & Test) Innes Kerrie (Test) Morten Mike (Product Owner) Mary (Scrummaster) The team works in coordination with: Mara Documentation/Resources Center Coordinator Lindsay Release Coordinator Rob Product Manager Patrick Program Manager Scott, Clint, Jim, Euan Stakeholders

19 Sprint planning Prerequisite: - PBIs considered in Sprint are fully defined (What?) Team effort (1/2 to 1day) Define Goals Select PBI s Determine implementation (How?) - Define Tasks for each PBI - UI Design - Architecture - Dev - Test - Doc - Estimate tasks in hours (2-24)

20 Mars.NET Sprint Planning Sprint Goals

21 Mars.NET Sprint Planning PBI and Tasks

22 Mars.NET Sprint Planning Task description

23 Agile estimating and tracking How long will it take? - Is a legitimate question - Based on past performance rather than guessing - Agile estimating works

24 Agile estimating and tracking Relative estimating - against baseline PBI Backlog Items in story points During a Planning Poker game - Fun - Entire team participates - Gain mutual understanding Measure velocity each iteration

25 Agile estimating and tracking MapX Burndown Chart Effort in Points Velocity Trend Scope change Trend Mar 1 10-Apr 2 1-May 3 22-May 4 12-Jun 5 3-Jul 6 24-Jul 7 14-Aug 8-40 Iteration

26 Mars.NET - Estimating Product Backlog Items Story points It is not time Based on 3 criterias Compare to a baseline story Using Fibonacci suite (1,2,3,5,8,13) 13 story points is the maximum Effort Uncertainty Complexity Tasks Hours Use ideal time for estimates Only remaining hours are tracked Generally between 1-24 hours 40 hours maximum

27 Mars.NET reports and charts Sprint Burndown Chart

28 Mars.NET reports and charts Team Member Load Chart

29 Mars.NET reports and charts

30 Mars.NET reports and charts

31 Mars.NET reports and charts ArcGIS Runtime for WPF (Mars.Net) 10% 9% 28% 30% Design Development Test Documentation Event 24%

32 Scaling Scrum Define Team Structure - Feature vs. Component Teams - Lean towards Feature Teams Establish Communities of Practice Filomena Scalice / FreeDigitalPhotos.net - Topics affecting many teams Hold Scrum of Scrums meetings - Share information between teams Look two to three iterations ahead - Coordinate between teams each iteration Use Epics to track and communicate - High level Stories

33 Mars.Net Dimensioning the Teams 8 members 6 members 7 members 8 members Android SDK ios SDK WPF SDK Java SE SDK Software Developer Kits Android API ios API WPF API Java SE API Object Models ArcGIS Runtime Core Runtime Local Server 8 members 5 members Runtime

34 Design in the Scrum Process Design and Architecture - Architecture is on the system and sub system level design is at the class level - Same principles apply - Architecture evolves Architecture owner - includes the entire team - coordinates - doesn't dictate architecture

35 Design in the Scrum Process (cont.) Agile Architecture and Design - evolve iteratively through - an initial envisioning - implementation of backlog items - refactoring and restructuring avoid waterfall BDUF (Big Design Up Front) that doesn t mean no design up front

36 Design in Scrum: Architecture Envisioning - When? Sprint 0 - Where? Architecture workshop (whole team) 1-3 days - Architecture Workshop - domain modeling - UI prototyping - identify desired architecture qualities and concerns (e.g. Portability, Usability, Modifiability, Performance, Security) - identify cross-cutting requirements - Prioritize architecture features by business value - include architectural features into the user stories - Benefits: - clarity of critical technical issues - shared understanding of architecture and design

37 Design in Scrum: Architecture Implementation - select a story and include an architectural feature - select a second story and evolve architecture by refactoring common functionality - select a third story extending and validating the architecture - have brainstorming session before and after a architectural feature is implemented - decide on which/how architectural features to build during iteration planning - Important - Hold a technical debt workshop - Document architectural decisions

38 Benefits Bring the maximum value to our users More productive Successful Projects Accurate Estimates Transparency to Stakeholders All team members participate Continuous process improvement

39 Pitfalls when using Scrum Backlog Items are too big Backlog Items not fully defined Team over-commits Unclear definition of Done Team is too large Distributed Teams Product owner proxies Team members assigned to multiple Scrum teams Too many hats Little or no Release Planning

40 Mars.NET Best Practices Estimates Always have a baseline PBI in mind When a PBI is estimated at 13 story points, consider splitting it When a task is estimated at 40 hours, consider splitting it What means done? PBI done = Design, implementation, testing, and documentation is done This must be a goal for the team A Design task is never completely done It is an iterative process The first level of being done is the ability to start securely an implementation task An Implementation task is done when it is ready to test A Test task is done when all testing has been achieved and the tester has a list of Change Requests to assign to the developer

41 Mars.NET Best Practices Do design at the earliest Avoid having many tasks in progress unless there are impeded Speak loud and clear Be specific and concise Days off and working days on other projects Must be known in front of sprint Goal is to better balance the workload

42 Links, Tools and Literature Scrumworks by CollabNet [easy to use, focused Scrum Tool] Agile Software Development with Scrum - by Ken Schwaber and Mike Beedle [The first Scrum book] Scrum and XP from the Trenches - by Henrik Kniberg [very practical how-to-guide] Succeeding with Agile Software Development Using Scrum - by Mike Cohn (2010) [Helpful for larger scrum implementations] Lean Software Development - by Mary Poppendieck and Tom Poppendieck [A good intro to Lean]

43 Summary Why go Agile? Introduction to Scrum - Process - Roles Agile Estimating and Tracking Scaling Scrum Design in the Scrum Process Benefits Pitfalls and Best Practices Resources