Agile, XP and Scrum

1. Agile, XP and Scrum

2. Overview • Development Methodologies (until this point) • Agile Development • Extreme Programming (XP) • Scrum • Develop Your Own Methodology

3. Methodologies

4. What is a Software DevelopmentMethodology? • formalized process or set of practices for creating and maintaining software • It’s a Life Cycle • A set of rules you have to follow • Standardization • System building and engineering approach for organizing software projects

5. Or at worst … • But this always ends up happening! The Waterfall Process • The traditional development process: System Requirements Software Requirements Analysis Program Design Coding Testing Operations

6. Formal Processes • Formal efforts to “fix” the problem System Requirements Preliminary Design Analysis Software Requirements Program Design Preliminary Design Coding Software Requirements Specification Testing Usage Analysis Prelim. Review Program Design Operating Instructions Preliminary Design Document Coding Final Design Testing Design Review UI Design Document Test Plan Operations

7. Agile Development

8. Manifesto

9. Agile Manifesto “Our highest priority is to satisfy the customer through early and continuous delivery of valuable software“ Source: http://agilemanifesto.org/

10. Agile Methodologies • eXtreme Programming (XP) • Scrum • Feature-Driven Development (FDD) • Adaptive Software Development (ASD) • Dynamic System Development Model (DSDM) • Agile Unified Process (AUP) • Crystal family of methodologies • Software Oriented Architecture (SOA) • Microservices

11. eXtreme Programming

12. Kent Beck The XP Guru: Kent Beck • eXtreme Programming • The most prominent agile development methodology 1st ed. Oct 1999 2nd ed. Nov 2004

13. XP

14. The 12 Key Practices • The Planning Game • Small Releases • Metaphor • Simple Design • Test-Driven Development • Refactoring • Pair Programming • Collective Ownership • Continuous Integration • 40-Hour Workweek • On-site Customer • Coding Standards

15. Game Theory • In economics, a game is something in which "players select actions and the payoffs depend on the actions of all players.” • The study of these games "deals with strategies for maximizing gains and minimizing losses... [and are] widely applied in the solution of various decision making problems."

16. 1. Planning Game

17. Plannig Game

18. Before the game • Accordingly, the planning game requires the participation of both customers and programmers. • (Testers may assist, but they do not have an explicit role in the planning game.) • It's a cooperative game; the team as a whole wins or loses, not individual players.

19. Assumptions • programmers have the most information about costs—they're most qualified to say how long it will take to implement a story—they estimate. • customers have the most information about value—they're most qualified to say what is important—they prioritize.

20. Planning Steps • Anyone creates a story or selects an unplanned story. • Programmers estimate the story. • Customers place the story into the plan in order of its relative priority. • Repeat until all stories have been estimated and placed into the plan.

21. What is Story? • Although stories are short, they still have two important characteristics. • Stories represent customer value and are written in the customers' terminology. (The best stories are actually written by customers.) They describe an end-result that the customer values, not implementation details. • Stories have clear completion criteria. Customers can describe an objective test that would allow programmers to tell when they've successfully implemented the story.

22. What is not Story? • The following examples are not stories: • "Automate integration build" does not represent customer value. • "Deploy to staging server outside of the firewall" describes implementation details rather than an end-result, and it doesn't use customer terminology. "Provide demo that customer review board can use" would be better. • "Improve performance" has no clear completion criteria. Similarly, "Make it fast enough for my boss to be happy" lacks objective completion criteria. "Searches complete within one second" is better.

23. Stories • Story Cards • Customer Centric • Splitting and Combining Stories • Some Special Types • Documentation Stories • Bug Stories • Non-Functional Stories • Spike Stories

24. User Stories

25. Game Process • The team goes through all the items and chooses the one which has the lowest effort. Write the number “2” on this card (usually in the bottom right corner). • The team looks at the item with the highest value. • Each team member thinks about how much effort the team will expend to fully complete all the work for the item. Comparing this work to the work effort for the smallest item, each team member selects a card that represents this relative effort. For example, if you think that it requires ten times the effort, you would select the “20” card. It is not permissible to select two cards. • Each team member places their selected card, face down, on the table. Once all team members have done this, turn the cards over. • If all team members show the same value, then write the value on the item and go back to step three for the next item. (Or if there are no more items, then the process is complete.) • The person with the highest and the lowest value cards both briefly explain why they voted the way they did. If there is a Product Owner present, this person can add any clarifications about the item. • For any given item, if a person is highest or lowest more than once, then each explanation must include new information or reasoning. • Once explanations are complete, the team members collect their cards and go back to step three.

26. 2. Metaphor • Guide all development and conversations with a simple shared story of how the whole system works • Gives the team a whole picture of describing the system, where new parts fit, etc. • Words used to identify technical entities should be chosen from the metaphor • The default metaphor is the business domain, and it’s usually just fine

27. Experience • Metaphors are good idea • People should know the business needs and how their work fits in the project

28. Domain-Driven Design

29. 3. Release Planning • Requirements via User Stories • Short cards with natural language description of what a customer wants • Prioritized by customer • Resource and risk estimated by developers • Via “The Planning Game” • Play the Planning Game after each increment

30. Experience • Requirements specification (SRS) is better than user stories • Written documentation works well for large projects • I prefer prototyping the user interface as source of documentation • Sometimes its is hard to estimate the required resources • Small releases have less risk

31. 4. Testing • Test-Driven Development (TDD) • Write tests before code • Tests are automated • Often use xUnit framework • Must run at 100% before proceeding • Acceptance Tests • Written with the customer • Acts as “contract” • Measure of progress

32. Developers write unit tests before coding Motivates coding Improves design: cohesion and coupling Provides regression tests Provides specification by example Test-Driven Development public void TestMultiplication() { Dollar five = Money.dollar(5); AssertEqual(new Dollar(10), five.times(2)); AssertEqual(new Dollar(15), five.times(3)); }

33. TDD, BDD, ATDD ATDD(Acceptance Test Driven Design), STDD(Story Test Driven Design) TDD(Test Driven Design): Get Something working now And perfect it later BDD(Behaviour-Driven Development) A part of DDD(domain driven design) Functional Documentation

34. TDD, BDD, ATDD

35. Experience • TDD is good for most projects, not for all • The real world is different: you always need the functionality "for tomorrow"! • I use unit testing for complex logic only • Testing simple logic is overhead

36. 5. Pair Programming • Two software engineers work on one task at one computer • The driver has control of the keyboard and mouse and creates the implementation • The navigatorwatches the driver’s implementation • Identifies defects and participates in on-demand brainstorming • The roles of driver and observer are periodically rotated

37. Pair Programming • Pairs produce higher quality code • Pairs complete their tasks faster • Pairs enjoy their work more • Pairs feel more confident in their work

38. Pair Programming

39. Experience • Pair programming is great for complex and critical logic • When developers need good concentration • Where quality is really important • Especially during design • Reduces time wasting, e.g. ICQ chatting • Trivial tasks can be done alone • Peer reviews instead pair programming is often alternative

40. 6. Refactoring • Improve the design of existing code without changing its functionality • Relies on unit testing to ensure the code is not broken • Bad smells in code: • Long method / class • Duplicate code • Methods does several different things (bad cohesion) • Too much dependencies (bad coupling) • Complex / unreadable code

41. Refactoring

42. Experience • Delivering working software faster is important! • You can write the code to run somehow • With simple design • With less effort • Later you can refactor the code if necessary • Refactoring is not a reason to intentionally write bad code! • Good coding style is always important!

43. 6. Simple Design • No Big Design Up Front (BDUF) • Reduces the overhead • Ship working functionality faster and get feedback early • “Do The Simplest Thing That Could Possibly Work” • Later use refactoring to change it • Not too much formal documentation

44. Simple Design

45. How It Works for Me? • Simple design does not mean "no design" • It is about establishing priorities • It's a set of tradeoffs you make • If something is important for this release and for the whole system, it should be designed well • Don't lose time to design something you will not use soon!

46. 7. Collective Code Ownership • Code to belongs to the project (team), not to an individual engineer! • Any engineer can modify any code • Better quality of the code • Engineers are not required to work around deficiencies in code they do not own • Faster progress • No need to wait for someone else to fix something

47. Collective Code Ownership?

48. Experience • Collective code ownership is absolutely indispensable • You need to fight the people who don't agree with this! • Fire people writing unreadable and unmaintainable code • Don't allow somebody to own some module and be irreplaceable

49. 8. Continuous Integration • Pair writes up unit test cases and code for a task (part of a user story) • Pair unit tests code to 100% • Pair integrates • Pair runs ALL unit test cases to 100% • Pair moves on to next task with clean slate and clear mind • Should happen once or twice a day

50. How It Works for Me? • Integrating often is really valuable • Sometimes you cannot finish a task for one day and integrate it • For small projects with small teams integration is not an issue • For large and complex projects it's crucial • Think of automated build environment Make it Painless: integrate often