Agile, a software development model or a religion? Pablo Garcia Munos Knowit AB

Size: px
Start display at page:

Download "Agile, a software development model or a religion? Pablo Garcia Munos Knowit AB"

Transcription

1 1 Agile, a software development model or a religion? Pablo Garcia Munos Knowit AB

2 2 Disclosure You are listening to this presentation on your own risk. Listening to this presentation will NOT guarantee that you have learned a development methodology that solves all your problems. If this presentation creates sleeping disorders or any kind of depression the speaker bears no responsibility. o

3 3 Agile methods and Scrum are very vaguely defined, this allows the methods to be interpreted in many ways. This has created a group of fanatic followers that really see Agile and Scrum as the only real religion. There is no real way of executing Agile or Scrum, the experience and competence in every ITprofessional creates a personal view of how things have to be done. o

4 4 The overall aim for tests: Priority rule nr 1 Priority the testing so that whenever you stop testing you have done the best possible testing on the given time. o

5 5 What is Agile

6 The definition of Agile. (

7 Manifesto for Agile Software Development 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. Kent Beck Mike Beedle Arie van Bennekum Alistair Cockburn Ward Cunningham Martin Fowler James Grenning Jim Highsmith Andrew Hunt Ron Jeffries Jon Kern Brian Marick Robert C. Martin Steve Mellor Ken Schwaber Jeff Sutherland Dave Thomas

8 Principles behind the Agile Manifesto We follow these principles (1): 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. 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. 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.

9 Principles behind the Agile Manifesto We follow these principles (2): 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. Continuous attention to technical excellence and good design enhances agility. Simplicity--the art of maximizing the amount of work not done--is essential. 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 behavior accordingly.

10 Is this enough for developing good software?

11 Is this enough for starting a new religion?

12 Answer : The answer for every testing question is: It depends.

13 13 A closer look at Scrum

14

15 15 A simple framework Scrum is made up of three roles, three ceremonies, and three artifacts. Three roles: the Product Owner, who is responsible for the business value of the project; the ScrumMaster, who ensures that the team is functional and productive; and the self-organized team. Three ceremonies: the sprint planning meeting, daily scrum meetings, and sprint review meetings. Three artifacts for prioritizing and tracking tasks: the product backlog, the sprint backlog, and a burndown chart

16 Scrum Artifacts *Sprint Backlog

17 Scrum Artifacts * Burndown Chart

18 Priority of work

19 Prerequisites to become a Certified Scrum Trainer Must be a CSP for at least one year before applying Must also be an active contributor in the Scrum community. To teach CSM courses, you must hold a CSM designation (in addition to CSP). To teach CSPO couses, you must hold a CSPO designation or have written approval from the Scrum Alliance (in addition to CSP). While not yet a prerequisite, those pursuing the CST designation are urged to co-train with at least two CSTs before submitting an application. Documented evidence of successful co-training with CSTs will weigh favorably in receiving a positive recommendation for CST status from the Certification Review Committee. The Certification Review Committee recommends candidates to the Scrum Alliance Board for final approval.

20 20 Different Processes

21 Waterfall model V-model W-model RUP SCRUM

22 Waterfall model Message: Do what you should or get hurt!

23 23 V-model and testlevels ISTQB way. Maintenance testing System req. Acceptance testing System test High level design Integration test Detailed design Code Unit test o Message: Don t do what you should and become a hero!

24 W-model and testlevels W-modellen april Message: Big Brother is watching!

25 RUP Message: Do the same mistake over and over again! Vad Hur Bygg Leverera Milestones DP1 DP2 DP2 DP3 april What to build Architecture is OK Are we done?

26 26 Message: Scrum is the light and the only thruth!

27 27 Different Groups of Processes Sequential V-model Waterfall model W-model PROPS Iterative RUP RAD Incremental Agile Scrum System req. System test High level design Integration test Detailed design Unit test Code But It Depends!?!

28 28 Different Processes for different purposes: Scrum is mostly better for: Small Products When customers do not know what they want Not critical products Experienced team members Sequential models are mostly for: Larger Products When customers know what they want Safety critical critical products Unexperienced team members But It Depends

29 29 Testing in Scrum

30 The most common way of testing in Scrum projects is by having two different test focuses (levels) and most of the times two different approaches to test. Why is this so?

31 The normal process. SR FR DS FT BT ST SR FR DS BT FT ST SR FR DS BT FT ST Code

32 What is optimal? Make a well informed decision about the following 3 variables: Product management and requirement definition. -How well defined requirements are needed before starting the sprint? Who will define them? The Teams responsibility: -Quality responsibility for the code, function and/or System. -Shall we have testers in the team, and what are their goals. -Who corrects the found faults? The Test Groups Responsibility: -Quality Goals, Strategy, approach, process -What kind of testers are needed.

33 Different Solutions ST SR SR BT FT FR DS ST ST SR SR FT FR ST FR BT FT

34 Most Common Solutions V-model with Scrum in the lowest layer. High Quality demands SR ST Normally, 2 test groups, FT and ST. FR FT DS BT V-model with Scrum in the middle layer. HLow Quality demands SR ST Normally, 1 external FR FT test group ST and testers in team. DS BT

35 A different view The following test levels are defined: Basic Test. (planned and executed within the sprint) Function Test. (planned and executed within the sprint) System Test. (planned and executed sequentially after the concurrent sprint)

36 36 Argumentation, a good solution?!?

37 Difficulties with testing in Agile processes Developers tend to have a lot of power in Agile environments, mainly because the Agile methodology is primarily defined by developers for developers. The requirement problem is allways present, since the requirements are written by developers when they are developing the tests can not be prepared in time. You are not sure that the functionality you are preparing tests for will really be released. The test competence exists only in the testers head. Test environment problems kill testing time.

38 Solutions Learn the process in detail Show your test expertise by founding many faults and gain trust Use metrics Never stop developing your testing skills Have release meetings with exit criterias from developers Allways be on top of the requirements Be a quality controller Use your common sence

39 Summary Agile Methods are often better suited if the recources are experienced. Often very effective for code writing. Creates often a uncontrolled amount of testing. Percieved as fun. Make a selection of the three variables. Agile is just another software development model, not a religion.

40 Questions?