Advanced Software Engineering Agile Software Engineering. Version 1.0

Transcription

1 Advanced Software Engineering Agile Software Engineering 1 Version 1.0

2 Basic direction A agile method has to be A method is called agile if it follows Incremental the principles of the agile manifest. Cooperative Easy Based on Haneberg 2009 Adaptive Based on Abrahamsson et al

3 The agile manifest We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value: Individuals and interactions over processes and tools Working software over comprehensive documentation Customer collaboration over contract negotiation Responding to change over following a plan That is, while there is value in the items on the right, we value the items on the left more. 3

4 The twelve principles Our highest priority is to satisfy the customer through early and continuous delivery of valuable software. Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage. Notre plus haute priorité est de satisfaire le client en livrant rapidement et régulièrement des fonctionnalités à grande valeur ajoutée. Accueillez positivement les changements de besoins, même tard dans le projet. Les processus Agiles exploitent le changement pour donner un avantage compétitif au client. 4

5 The twelve principles Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale. Business people and developers must work together daily throughout the project. Livrez fréquemment un logiciel opérationnel avec des cycles de quelques semaines à quelques mois et une préférence pour les plus courts. Les utilisateurs ou leurs représentants et les développeurs doivent travailler ensemble quotidiennement tout au long du projet. 5

6 The twelve principles Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done. The most efficient and effective method of conveying information to and within a development team is face-to-face conversation. Réalisez les projets avec des personnes motivées. Fournissez-leur l environnement et le soutien dont ils ont besoin et faites-leur confiance pour atteindre les objectifs fixés. La méthode la plus simple et la plus efficace pour transmettre de l information à l'équipe de développement et à l intérieur de celle-ci est le dialogue en face à face. 6

7 The twelve principles Working software is the primary measure of progress. Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely. Un logiciel opérationnel est la principale mesure d avancement. Les processus Agiles encouragent un rythme de développement soutenable. Ensemble, les commanditaires, les développeurs et les utilisateurs devraient être capables de maintenir indéfiniment un rythme constant. 7

8 The twelve principles Continuous attention to technical excellence and good design enhances agility. Simplicity--the art of maximizing the amount of work not done--is essential. Une attention continue à l'excellence technique et à une bonne conception renforce l Agilité. La simplicité c est-à-dire l art de minimiser la quantité de travail inutile est essentielle 8

9 The twelve principles The best architectures, requirements, and designs emerge from self-organizing teams. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behaviour accordingly Les meilleures architectures, spécifications et conceptions émergent d'équipes autoorganisées. À intervalles réguliers, l'équipe réfléchit aux moyens de devenir plus efficace, puis règle et modifie son comportement en conséquence. 9

10 The agile manifesto focused statements Individuals and interactions Working software Customer collaboration over over over Process and tools Comprehensive documentation Contract negotiation Responding to change over Following a plan 10

11 What is Scrum? Scrum is a action in Rugby The action is complex and have to be planned and orchestrated Requires disciplined teamwork 11

12 Scrum scope Identify reasons, develop solutions To check the realisation of requirements inside software frequently Identify problems and handicaps early To perform the correct activities 12

13 Scrum process Product increment 13

14 Scrum-Philosophy Requirement for a new version should be minimal Deliver functionality as fast as possible and frequently No Big-Bang -Release with extensive amount of new functionality Every sprint create a product increment Procedure: Identify the lowest number of marketable attributes, which have a real added value 14

15 Scrum roles Product owner Roles Scrum Team Scrum master 15

16 Scrum process Requirement description Realisation Common procedure Requirement description Realisation Sprint 1 Scrum procedure Sprint N 16

17 Scrum process Customer End-user Stakeholder Product Backlog Team 17

18 Scrum Process Daily scrum 24 hours Sprint backlog Sprint planning meeting Part 2 Part 1 Sprint goal Return Return Cancel Gift Coupons wrap Sprint Backlog task 2-4 weeks (worked by the team) Gift Cancel wrap Coupons Product Backlog (prioritised by product owner) Sprint review meeting Potentially shippable product increment 18

19 Product Backlog Not fixed, it is a living document Iterative an incremental development Scrum does not know Change requests, but the Product Backlog should include changes All entries should be prioritised and the effort should be estimated 19

20 Product Backlog 20

21 Product Backlog Attributes, from the product concept, will be included in the product backlog. Product Owner group requirements to topics Product Owner has to set priority to the topic Product Owner refines the high priority requirements with the team Actualisation, refinement or cancellation of existing requirement Inclusion of new requirements 21

22 Set priority Prio Topic Description Acceptance criteria Effort 1 Calendar User wants to create a meeting 2 Calendar User wants to delete a meeting 3 Calendar User wants to change a meeting Test the input of false values, e.g. End time before start time Test if a meeting can be delete twice Test if changes are applied 2h 3h 1h 22

23 Requirement workshop Helpful tool for the identification of requirements All on one table Support for a common understanding, a common language and Establish a common understanding, language and adequate description More then one before the first sprint, regular during the sprints, to identify new sprints 23

24 Set priority Why? Relevant things first Precise refinement on the relevant requirements Team knows what is necessary for the success of the project and it is focused on this Setting priority is difficult! Product owner has to know customer requirement, and has to know which function relevant is. 24

25 Set priority Aim of the project is the generation of added values Primary question: How much added value is created by a requirement Risk, value, and costs Priority 25

26 Set priority Risk High Avoiding First Value Low Last Second Low High 26

27 Won t have 27 Set priority (MuSCoW pyramid) Must have Should have Could have

28 Scrum process Product increment Sprint 28

29 Scrum process Product Backlog Actual progress and current problems Release planning Sprint planning Daily planning Release plan Release plan 29

30 Release Burn down Chart 30

31 Sprints Standard sprint Smallest unit, to create an useable product Time frame is fixed Max 30 day Explorations sprint For trial Release sprint For configuration 31

32 Sprints Improvement activities Product Backlog Sprint planning Conversion activity and daily scrum Sprint review and sprint retrospective 32

33 Sprints Standards prints Start with a Sprint planning meeting Are used in analyse, design, implementation and test phase Use Agile techniques as TDD, FDD, Pair Programming, Refactoring etc. Deliver a product at Sprint Review Support the improvement of process in the Sprint retrospective 33

34 Sprint planning meeting Moderation by scrum master Product owner Sprint aims and requirements Add requirements, if realisable Sprint Team Activity definition estimation 34

35 Sprint backlog Priority Requirement To Do In Progress Done

36 Sprint burn down Activities Days 36

37 Daily scrum Max. 15 Min. Same time Same place Moderation by Scrum Master All have to participate (passive Product Owner) Organisation, address problems (do not solve it!) 37

38 Daily scrum Preparation: Sprint Backlog Sprint Burn down Chart Three question to everybody: Work done?? Work planned? Problems? Write down all problems Use speech token if necessary 38

39 Sprint review Approval of work results Only requirements are discussed, which are completely and error free implemented (no 99% solutions) ~ 1 hour. Moderated by Scrum Master All have to participate 39

40 Sprint review Sprint aim Live-Demo of working result Product Owner analysis Product Owner decide 40

41 Sprint Retrospective Aim: Work together to improve the process When: Direct after the Sprint review Duration: ~ 1 hour. Who: all Moderation by Scrum Master 41

42 Sprint Retrospective Check -In, Jump outside the box Collect information max. 3 pos. and 3 neg./person all group Gain experience, group set priority, how this could happen? Take decision Conclusion 42

43 Training SCRUM ON ONE DAY (SOOD) Rules We are simulating SCRUM 3 Groups Aim is to develop a software architecture for program controlling ALL things necessary for the METRO in Paris (Ticketsystem, Train cotnrolling, Timeplan, Web, Mobile access,..) Simulation A working task (45 minutes is a day in real life) 43

44 SOOD - Initial Steps Step 0: Decide who is the Product Owner and who is the Scrum Master Step 1: Make a Requirement Session with the Product Owner ~ 60 Minutens Find as much requirement as you can find even you cannot focus all today Make a Product Backlog with Priorities Create a Burndown Chart Step 2: Make a Sprint Planning Meeting ~ 15 Minutes Plan 2 Weeks (Simulation) Plan 1 Task (UML Diagramm) per Person Create a Sprint Burndown Chart Create a Sprint Backlog 44

45 SOOD - Daily Scrum Step 3 - Each person work on your Topics (45 Minutes) Step 4 Make a first Daily Scrum Session (15 Minutes) Product Owner (Passiv) Scrum Master (Looking at the time and make Notes) Update your Sprint Backlog with history Each person should say Work done?? Work planned? Problems? Write down all problems 45

46 SOOD - Daily Scrum Step 5: Work on your next topics (45 Minutes) Step 6: Make a second Daily Scrum Session (15 Minutes) Step 7: Work on your next topics (45 Minutes) See Step 4 Step 8: Make a Sprint Review (See slide 39; 20 Minutes) Step 9: Make a Sprint Retrospective (20 Minutes) Remember Focus is to make your process better not the product 46