Agile and lean methods for managing application development process

Transcription

1 Agile and lean methods for managing application development process Hannu Markkanen

2 Application development lifecycle model To support the planning and management of activities required in the production of e.g. goods, software, or information systems, various lifecycle models have been developed A lifecycle model establish the order in which a project designs, prototypes, implements, tests, etc., i.e. performs its activities. Waterfall Code-and-Fix Prototyping 2

3 Waterfall model Strenghts The waterfall model performs well for projects in which you have a stable product definition Do such projects exist? Weaknesses The waterfall model is inflexible. Is it possible to specify the requirements at the beginning of the project? Is it possible to design and implement all parts of the application at the same pace? 3

4 Code-and-Fix Strenghts No planning and design overhead, time is spend on pure coding Requires no process management experience. Weaknesses Useful only for tiny applications. In case of real life projects, dangerous! 4

5 Prototyping Develop a prototype, show it to your customer, and refine it based on the feedback Strenghts Flexibility (with changing requirements) Reduced time and cost Weaknesses Can distract developers from properly analyzing the complete project Can easily result in the code-and-fix development. Good for applications with lots of user interaction Most Agile Methods rely heavily upon prototyping techniques. 5

6 Overview of lean and agile software development

7 Lean software development Lean software development is an adaptation of Lean manufacturing principles and practices Based on the Toyota Production System The core lean principles: Eliminate waste Extra features (unnecessary functionality) Partially done work Task switching Delays (waiting for work) Bureaucracy Defects Focus on learning and improvement Build quality in the process Decide as late as possible Deliver as fast as possible (customer value) Empower the team 7

8 Two Axioms of Lean Software Engineering (David Joyce) 1. It is possible to divide the work into small (value adding) increments, that can be independently scheduled 2. It is possible to develop any increment in a continuous flow, from requirement to deployment 8

9 Dividing the work to small increments 9

10 Dividing the work to small increments Time on the job Client Time of getting the first batch Time of whole production 10

11 Agile software development A group of software development methodologies based on iterative and incremental development Requirements and solutions evolve through collaboration between self-organized cross-functional teams Agile Manifesto - values: 1. Individuals and interactions over processes and tools 2. Working software over comprehensive documentation 3. Customer collaboration over contract negotiation 4. Responding to change over following a detailed plan Popular Agile methods Scrum Extreme Programming (XP) 11

12 Scrum overview Short, time-boxed iterations 12

13 Agile practices User stories Regular meetings Planning meeting Daily Stand-up meeting Retrospective meeting Continuous integration Refactoring of code (*) (*) Restructuring existing code without changing its external behavior in order to improve its maintainability and extensibility (more readable, less complex, better architecture) 13

14 Kanban

15 Background of Kanban Kanban is a Japanese word that literally means signal card In a manufacturing environment, this card is used as a signal to tell an upstream stage in a process to produce more Kanban is a pull system New work is pulled into a stage in the system when there is capacity to handle it, rather than being pushed based on demand The workers at each stage in the process are not allowed to do work unless they are signaled from a downstream stage A pull system cannot be overloaded if the capacity of each step has been set appropriately The first kanban system for software engineering was implemented at Microsoft beginning in

16 Kanban as an Adaptive System to achieve Lean The Kanban Method is an adaptive system for catalyzing Lean behaviour (complex, adaptive, emergent behavior) Kanban core concepts Visualize workflow Limit Work-in-Process Help work to flow Kanban is not a software development methodology Does not provide methods for any particular development task, like design or testing Kanban teams adopt practices e.g. from agile methods (such as daily stand-up meetings) 16

17 Implementing Kanban

18 Kanban workflow There is a queue of work, which goes through a number of stages until its done When work is completed in a stage, it is pulled downstream for the next stage 18

19 Kanban board WIP limit Vertical columns for stages (phases) in the workflow, i.e. activities through which the work progresses Input queue ( Backlog ) Done stage ( RTS ) Work items on cards that are moved from column to column Work-In-Process (WIP) limits The max number of work items that can be in a stage at any moment Typically, the work-in-process limits are drawn on the board at the top of each column (or across a span of columns) Pull is signaled if the number of cards in a column is less than the indicated limit Why WIP is important? To deliver new value (e.g. feature) quickly, limit the amount of work done at one time Context switching costs 20% productivity 19

20 Typical Work Item Types (for Kanban cards) Incoming work E.g. User Story, Use Case, functional requirement, feature, The incoming work type might be hierarchical, such as Epic, a collection of user stories. Bug (issue) Change Request Maintenance Refactoring Improvement Suggestion Blocking Issue Support task 20

21 Setting the WIP limits WIP limits for work tasks should be set as an average number of items per person, developer pair, or small, collaborative team Typically, the limit should be in the range of one to three items per person, pair, or team Do not waste time in trying to determine the perfect WIP limit; simply pick a number based on best guess, and make progress Adjust the WIP limit empirically if necessary There is no magic formula for your choice. You can select a number and then observe whether it is working well. If not, adjust it up or down 21

22 Kanban card conventions Use text or color to communicate the type of work Write other necessary information on the card, e.g. work description tasks assigned team member due date tracking number with digital Kanban board attachments possible 22

23 Web based Kanban boards Product offer has grown rapidly in last years In your project, use the free Trello tool: 23

24 Writing user stories

25 Writing a user story Template: As a <some role>, I want <something>, [so that <some value>] Describe who wants, what wants [and what for] in one sentence. Do not define any details of the implementation in the user story. Examples: As an end user I want to be able to upload my picture to my profile page, so that people can easily identify me As a knight I want to be able to ride a horse, so that I can move faster (game character) 25

26 Writing a user story Example of breaking down a story into smaller stories: Example of breaking down a story into tasks: Henrik Kniberg: Scrum and XP from the Trenches 26