Development Agile

1. Introduction

2. Preamble

development activities
Figure 1. Methods organize Activities
Methods are guidelines and rules for activity organization

3. Rapid Software Development

  • Rapid development and release are often the most important requirements for software

    • Businesses operate in a fast–changing requirement and it is practically impossible to produce a set of stable software requirements

    • Software has to evolve quickly to reflect changing business requirements

  • Classic plan-driven development is essential for some types of system but does not meet these business needs

  • Agile development methods emerged in the late '90s whose aim was to radically reduce the delivery time for working software systems

4. Agile Development Characteristics

  • Pragmatic development method

    • Rapid feedback on development status

    • Short development cycles

  • Design and implementation are interleaved

  • Incremental development

    • No heavy prediction whose errors would be found later

    • The system is developed as a sequence of versions or increments

    • Frequent releases

    • Fast development feedback

5. Agile Development Characteristics (Cont.)

  • Adaptation

    • Regular adjustments

    • Flexible planning

  • Extensive tool support (e.g. automated testing tools)

  • Minimal documentation: focus on tests and high quality code

  • High human implication

    • Stakeholders are involved in version specification and evaluation

6. Agile vs. Plan-Driven Development

plan driven development
Figure 2. Plan-driven development
agile development
Figure 3. Agile development

7. Agile vs. Plan-Driven Development (Cont.)

Plan-driven development

A plan-driven approach to software engineering is based around separate development stages with the outputs to be produced at each of these stages planned in advance. Not necessarily waterfall model – plan-driven, incremental development is possible Iteration occurs within activities.

Agile development

Specification, design, implementation and testing are inter-leaved and the outputs from the development process are decided through a process of negotiation during the software development process.

8. Agile Methods

  • Dissatisfaction with the overheads involved in software design methods of the 1980s and 1990s led to the creation of agile methods. These methods:

    • focus on code and tests rather than heavy design

    • are based on an iterative software development approach

    • are intended to deliver working software quickly and evolve this quickly to meet changing requirements

  • Agile methods aim at reducing overheads in the software process and to be able to respond quickly to changing requirements without excessive rework

9. Agile Manifesto

  • 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.

10. Agile Methods Principles

Principle Description

Customer involvement

Customers should be closely involved throughout the development process. Their role is provide and prioritize new system requirements and to evaluate the iterations of the system.

Incremental delivery

The software is developed in increments with the customer specifying the requirements to be included in each increment.

People not process

The skills of the development team should be recognized and exploited. Team members should be left to develop their own ways of working without prescriptive processes.

Embrace change

Expect the system requirements to change and so design the system to accommodate these changes.

Maintain simplicity

Focus on simplicity in both the software being developed and in the development process. Wherever possible, actively work to eliminate complexity from the system.

11. Agile Method Applicability

  • Small or medium-sized product development

    • Virtually all software products and apps are now developed using an agile approach

  • Custom system development within an organization, where there is a clear commitment from the customer to become involved in the development process and where there are few external rules and regulations that affect the software.

12. Agile Method Examples

  • Rapid Application Development - RAD [James Martin, 1991]

  • eXtreme Programming - XP [Kent Beck, 1999]

  • Test-Driven Development - TDD [Robert C. Martin, 2007]

  • Scrum [Ken Schwaber, 1995]

  • Lean [Poppendieck, 2003]

  • Kanban [David Anderson, 2010]

13. Agile Development Tools

14. Automation Tools

For unit tests:

  • Easy unit tests writing

  • Fast test execution

  • Re-execution facilities

Integrated Development Environment

  • Improves coding: autocompletion, method generation, code formatting

  • Quick test execution

  • Refactoring

  • Examples: NetBeans, Eclipse, IntelliJ IDEA.

Integrated development environment ! For writing tests, using auto-completion and generation of missing code. ! For running the tests ! For refactoring ! E.g. Eclipse Build environment ! For executing tests automatically and during the build process ! For computing code coverage ! For generating test reports ! E.g. Maven

15. Automation Tools

Build tools:

  • Automatic test execution

  • Automatic report and website generation

  • Maven, Gradle

Test evaluation

  • PIT, Cobertura

16. Automation Tools (Cont.)

Static code analysis

  • PMD, Checkstyle, Findbugs

Continuous integration tools:

  • Sonar, Jenkins, Travis

Collaboration tools

  • Mattermost, Slack

Build environment ! For executing tests automatically and during the build process ! For computing code coverage ! For generating test reports ! E.g. Maven

17. Gradle / Maven

  • Repetitive task automation

  • Sequence of different stages of building

18. PMD

  • Open-source tool for static code analysis

  • Available as a plugin for most IDEs (Eclipse, Netbeans, JEdit, IDEA, etc.)

  • Available for Maven

  • Detects:

    • Dead code: unused variables, parameters, and methods

    • Unused objects

    • Empty code blocks: try / catch / finally / switch

    • Duplicate code

    • Unnecessarily complex expressions

https://pmd.github.io

19. Checkstyle

  • Open-source tool for checking code formatting and presentation

  • Support different code conventions

  • Available as a plugin for most IDEs (Eclipse, Netbeans, IDEA, etc.)

  • Available for Maven and Gradle

  • http://checkstyle.sourceforge.net

20. Extreme Programming (XP)

21. XP

XP is a lightweight development method for small (or even medium) software development teams whose needs are vague or change frequently.

22. Why Extreme?

Pushing common sense to the extreme:

  • Since code reviews are good, do it all the time (pair programming)

  • Since tests are good, test all time (unit testing) and include clients (acceptance testing)

common sense
Figure 4. Common Sense

23. Extreme Common Sense

  • Since design is good, make it everyone’s daily occupations (code refactoring).

  • Since simplicity is good, make the system have the simplest design to meet current requirements (do the simplest thing that can possibly work).

fixie bernard
Figure 5. Fixie Core Line 4130 Bernard

24. Extreme Common Sense (Cont.)

  • Since architecture is good, make everyone define and refine it all the time (metaphor).

  • Since integration test is good, integrate and test several times a day (continuous integration).

Leaning into the afternoons, I cast my sad nets towards your oceanic eyes.

— Pablo Neruda
Leaning into the afternoons

25. Extreme Common Sense (Cont.)

  • Since short iterations are good, do iterations that are really, but really very short: seconds, minutes or hours, not weeks, months or years (the planning game).

short iterations

26. Promises to Developers

  • Developers will work on important things every day.

  • They will not face frightening situations alone.

boo code
Figure 6. Scary Code

27. Promises to Developers (Cont.)

  • Developers can do everything in their power to make the system work

  • They will make decisions for which they are best qualified and will not make decisions for which they are not.

28. Promises to Customers and Managers

  • They will receive the most possible value out of every programming week

  • Every week they will be able to see concrete progress on the goals they care about

  • They will be able to change the direction in the middle of the project without incurring exorbitant costs

29. Summary of XP’s promises

  • Risk reduction

  • Improved response time to changes

  • Improved productivity throughout the development cycle

  • Bring a little fun to team-based software development.

30. A different development method

incremental planning
Figure 7. Incremental Planning
XP differs from other methods by:

  • its short cycles, which give early, concrete and continuous feedback.

  • its incremental planning approach.

  • its ability to flexibly plan the implementation of new functionalities and respond to changing needs.

31. A different development method (Cont.)

  • XP relies on both automated tests and acceptance tests for the evaluation of the evolution and for the early detection of errors

  • It also relies on oral communication, testing, and source code to describe the objectives and structure of the system

32. A different development method (Cont.)

  • XP is based on an evolutionary design process, which lasts as long as the system.

  • XP relies on close collaboration between regular programmers.

  • It relies on practices that work with both: the short-term instincts of programmers and the long-term interest of the project.

33. A Software Engineering Discipline

  • For projects carried out by small development teams (between 2 and 10 people), without strong hardware constraints and where tests can be carried out in less than half a day.

  • XP may scare or annoy some people, but its ideas are not new.

It’s a discipline because you have to respect certain rules. XP puts different practices under the same umbrella.

34. The problem: a question of risks

35. Typical risks

  • Project slips

  • Project cancellation

  • Systems goes sour

  • Defect rate

  • Business misunderstood

  • Business changes

  • False feature rich

  • Staff turnover

dynamite

35.1. Detailed Typical risks

Schedule slips

the day for delivery comes, and you have to tell the customer that the software won’t be ready for another six months.

Project canceled

after numerous slips, the project is canceled without ever going into production.

System goes sour

the software is successfully put into production, but after a couple of years the cost of making changes or the defect rate rises so much that the system must be replaced.

Defect rate

the software is put into production, but the defect rate is so high that it isn’t used.

35.2. Detailed Typical risks (Cont.)

Business misunderstood

the software is put into production, but it doesn’t solve the business problem that was originally posed.

Business changes

the software is put into production, but the business problem it was designed to solve was replaced six months ago by another, more pressing, business problem.

False feature rich

the software has a host of potentially interesting features, all of which were fun to program, but none of which makes the customer much money.

Staff turnover

after two years, all the good programmers on the project begin to hate the program and leave.

36. Reduce Schedule Slips

  • Short cycles.

  • The customer checks the progress of the work every one to four weeks.

  • A job lasts between one and three days.

  • The most important features are implemented first: in case of a delay, features that are not present will have a lower priority.

37. Avoid Project Cancellation

Developers ask the customer for the smallest delivery of the system which gives it an elementary meaning

  • If the project fails, it will fail quickly 😊

38. Prevent System to go Sour

  • A comprehensive test suite is executed and rerun after every change, to ensure quality baseline

  • The system always remains in prime condition.

XP creates and maintains a comprehensive suite of tests, which are run and re-run after every change (several times a day), to ensure a quality baseline. XP always keeps the system in prime condition. Cruft is not allowed to accumulate.

39. Avoid Heigh Defect Rate

  • Tests are written both by programmers (method by method) and by clients (functionality by functionality).

40. Avoid Business Misunderstanding

  • The customer must be part of the team.

  • The project specification is continuously refined: the common know-how of the customer and the programmers is reflected in the software.

41. Managing Changing Requirements

  • Since the cycles are short, there is little change in requirements between the start and end of a cycle.

  • After every release, the customer can replace some unimplemented functionality with new ones.

42. False Feature Rich

  • Only the highest priority tasks are addressed.

43. Reduce Staff Turnover

  • Each programmer estimates the time needed to complete a task and receives feedback to improve his or her estimative

  • The programmer will not be frustrated by the assignment of tasks that are underestimated or even impossible

  • Encouragement of human relations within the team

    • reduced loneliness and dissatisfaction.

  • Pre-established pattern of change:

    • newcomers accept more and more responsibility and are helped by more experienced programmers

44. A Development Episode

45. An extreme day

  1. Choose a task

  2. Choose a pair

  3. Discuss the previous day’s work

  4. Write tests

  5. Implement and test

  6. Write more tests.

  7. Refactoring, design improvement and tests.

  8. Integrate and test.

46. Conclusion of the day

  • Pairs program together

  • Development is test-driven: test first, code later

  • A task is not finished until all the tests succeed

The pair is not restricted to the execution of tests:

  • It evolves the design of the system

  • Changes are not limited to one region: they can be made anywhere in the code.

  • The pair improves analysis, design, implementation and testing.

  • The integration and its tests are done right after the development.

47. Method Overview

  • Planning game

  • Short release times

  • Metaphors

  • Simple design

  • Tests

  • Refactorings

  • Pair programming

  • Collective ownership

  • Continuous integration

  • 40 hours per week

  • On-site customer

  • Coding conventions

48. Planning game

Managers decide:

  • The scope

  • Priorities

  • Release composition

  • Release dates

Developers decide:

  • Estimations

  • The consequences of technical choices.

  • The process (organization).

  • The detailed planning (high-risk tasks first, flexible enough to take into account the customer’s needs).

49. Short Release Times

A release must:

  • contain the customer’s most important requirements

  • be consistent: we don’t do the job by halves to reduce the time to production

  • have a lead time of one or two months rather than 6 months or a year

50. Metaphors

  • Each project is guided by a single metaphor: the computer should look like a desk, calculating pensions is like a spreadsheet, etc.

  • Metaphors replace traditional development architectures.

  • They bring an overall cohesion that is easy to share.

51. Simple Design

A good design:

  • passes all tests.

  • has no duplication.

  • declares that every intention is important to programmers.

  • contains as few classes and methods as possible.

Contains as few classes and methods as possible How to do it? Make a first draft and remove all classes whose absence does not violate these rules!

52. Tests

  • Programmers write tests to trust their code.

  • Customers write tests to trust the functionality of the system.

  • The result is a reliable program that accepts changes

  • It is not necessary to write one test per method.

53. Code Refactoring

  • Design simplification after adding a feature.

  • The new design must pass the tests

code refactoring

54. Pair Programming

1 computer, 2 programmers.

The first one thinks locally:

  • What is the code needed to implement a method?

The second one thinks strategically:

  • Will the approach you’re taking work?

  • Which test cases will not work?

  • Isn’t there a more global solution to solve this specific problem?

pair programming
Figure 8. Pair Programming

55. Collective Ownership

collective ownership
Figure 9. Collective ownership

  • Any programmer can change any piece of code at any time.

  • Every team member is responsible for the entire system.

56. Continuous Integration

  • The code is integrated and tested after a few hours, a day at the most

  • Use a dedicated machine for integration

  • Integration tests must pass. If they don’t:

    • Solve the problems

    • Start development from scratch

57. 40 hours per week

  • Or, 35 (🇫🇷)

  • You have to be fresh and passionate to work well.

  • No one can work 60 hours a week, for more than a week, and stay fresh, creative, careful and confident.

58. Onsite Customer

  • To answer questions, resolve conflicts, set low-level priorities.

  • Expensive, but brings a lot to the project.

59. Code Conventions

  • If anyone can change the code, everyone should use the same convention.

  • They have to be adopted by the whole team.

60. Conclusion

Tests are very important:

  • Tests passed = confidence.

  • More confidence = more efficiency.

Extreme Programming Particularity:

  • XP is against the hypothesis: "the cost of change increases exponentially over time".

  • On the contrary, it is better to delay any decision that is not sure.

61. Conclusion (Cont.)

  • Simple design

  • Automated testing

  • Practice in design modification.

References

  • «Extreme programming explained: embrace change». Kent Beck. Addison-Wesley, 1999.

  • Kanban: Successful Evolutionary Change for Your Business : David Anderson ISBN 978-0984521401 (existe en français)

  • Product Development Flow : Don Reinertsen - ISBN 978-1935401001

  • Kanban pour l’IT : Laurent Morisseau - ISBN 978-2100578672

  • Personal Kanban : Jim Benson - ISBN 978-1453802267

  • Scrumban : Corey Ladas - ISBN 978-0578002149

  • Kanban for the skeptics : Nick Oostvogels https://leanpub.com/kanbanforskeptics

  • Kanban and Scrum : Henrik Kniberg, Mattias Skarin ISBN 978-0557138326

  • The Goal : Eliyahu Goldratt (1984) ISBN 978-0884270614

  • The Lean Startup : Eric Ries ISBN 978-0307887894