Commit c86be728 authored by Gerson Sunyé's avatar Gerson Sunyé

Add new course: Agile Software Development

- Add new Images
- Add slides about XP
- Add better introduction
parent 72e5b7e3
Pipeline #16029 failed with stages
in 1 minute and 38 seconds
{
"directory": "bower_components"
}
......@@ -4,3 +4,4 @@ gem 'asciidoctor'
gem 'asciidoctor-revealjs'
gem 'asciidoctor-diagram'
gem 'asciidoctor-pdf'
gem 'prawn-gmagick'
......@@ -14,52 +14,651 @@
= Agile Software Development
* *Introduction*
* TDD and unit tests
* Strategies
* Conclusion
== Preamble
[.columns]
--
[.col-8]
****
.Methods organize Activities
image::development-activities.png[align=center,height=800px]
****
[.col-4]
[quote]
Methods are guidelines and rules for activity organization
--
== Agenda
== Agile Manifesto
* Introduction
* Agile Development Tools
* Agile Development
* Extreme Programming
* Test-driven Development
* Conclusion
[.impact]
== Test-Driven Development
== Introduction
== Rapid Software Development
== Plan
* *Introduction*
* TDD and unit tests
* Strategies
* Conclusion
* 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
== Agile Methods
== Agile Development Characteristics
* Pragmatic development method
** Rapid feedback on development status
** Short development cycles
* Adaptation
* 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
== Agile Development Characteristics (Cont.)
* Adaptation
** Regular adjustments
** Flexible planning
* Incremental development
** No heavy prediction whose errors would be found later
* 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
== Agile vs. Plan-Driven Development
.Plan-driven development
image::plan-driven-development.png[align=center,width=600px]
.Agile development
image::agile-development.png[align=center,width=600px]
== 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.
== Agile Methods
* RAD (Rapid Application Development)
* XP (eXtreme Programming)
* Scrum
* Lean
* Kanban
* 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
== 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.
== Agile Methods Principles
[.font-size-80]
[cols="20,80",frame="sides", options="header"]
|===
| 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.
|===
== 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.
== 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]
[.impact]
== Agile Development Tools
== 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: https://netbeans.org[NetBeans], https://www.eclipse.org[Eclipse], https://www.jetbrains.com/idea/[IntelliJ IDEA].
[.notes]
--
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
--
== Automation Tools
.Build tools:
* Automatic test execution
* Automatic report and website generation
* https://maven.apache.org[Maven], https://gradle.org[Gradle]
.Test evaluation
* PIT, Cobertura
[%notitle]
== Automation Tools (Cont.)
.Static code analysis
* PMD, Checkstyle, Findbugs
.Continuous integration tools:
* Sonar, Jenkins, Travis
.Collaboration tools
* Mattermost, Slack
[.notes]
--
Build environment ! For executing tests automatically and during the build process ! For computing code coverage ! For generating test reports ! E.g. Maven
--
== Gradle / Maven
* Repetitive task automation
* Sequence of different stages of building
== 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
== 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
[.impact]
== Extreme Programming (XP)
== XP
[quote]
____
XP is a lightweight development method for small (or even medium) software development teams whose needs are vague or change frequently.
____
== 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
image::common-sense.png[align=center]
== Extreme Common Sense
[.columns]
--
[.col-8]
* 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).
[.col-4]
****
.Fixie Core Line 4130 Bernard
image::fixie-bernard.png[align=center,width=600px]
****
--
== Extreme Common Sense (Cont.)
[.columns]
--
[.col-8]
* 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).
[.col-4]
[quote, Pablo Neruda, Leaning into the afternoons]
____
Leaning into the afternoons,
I cast my sad nets towards your oceanic eyes.
____
--
== 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).
image::short-iterations.png[align=center]
== Promises to Developers
[.columns]
--
[.col-8]
* Developers will work on important things every day.
* They will not face frightening situations alone.
[.col-4]
****
.Scary Code
image::boo-code.png[align=center,width=400px]
****
--
== 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.
== 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
== 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.
== A different development method
[.columns]
--
[.col-4]
****
.Incremental Planning
image::incremental-planning.png[align=center]
****
[.col-8]
.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.
--
== 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
== 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.
== 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.
[.notes]
--
It's a discipline because you have to respect certain rules.
XP puts different practices under the same umbrella.
--
[.impact]
== The problem: a question of risks
== Typical risks
[.columns]
--
[.col-8]
* Project slips
* Project cancellation
* Systems goes sour
* Defect rate
* Business misunderstood
* Business changes
* False feature rich
* Staff turnover
[.col-4]
image::dynamite.png[align=center]
--
=== 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.
=== 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.
== 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.
== 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 😊
== 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.
[.notes]
--
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.
--
== Avoid Heigh Defect Rate
* Tests are written both by programmers (method by method) and by clients (functionality by functionality).
== 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.
== 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.
== False Feature Rich
* Only the highest priority tasks are addressed.
== 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
[.impact]
== A Development Episode
== An extreme day
. Choose a task
. Choose a pair
. Discuss the previous day's work
. Write tests
. Implement and test
. Write more tests.
. Refactoring, design improvement and tests.
. Integrate and test.
== 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.
== Method Overview
[.columns]
--
[.col-6]
* Planning game
* Short release times
* Metaphors
* Simple design
* Tests
* Refactorings
[.col-6]
* Pair programming
* Collective ownership
* Continuous integration
* 40 hours per week
* On-site costumer
* Coding conventions
--
== Planning game
[.columns]
--
[.col-5]
.Managers decide:
* The scope
* Priorities
* Release composition
* Release dates
[.col-7]
.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 costumer's needs).
--
== 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
== 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.
== 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.
[.notes]
--
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!
--
== 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.
== Code Refactoring
[.columns]
--
[.col-8]
* Design simplification after adding a feature.
* The new design must pass the tests
[.col-4]
image::code-refactoring.png[align=center]
--
== Pair Programming
[.center]
[.block]
1 computer, 2 programmers.
[.columns]
--
[.col-8]
****
.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?
****
[.col-4]
****
.Pair Programming
[link=http://geek-and-poke.com/]
image::pair-programming.png[align=center]
****
--
== Collective Ownership
[.columns]
--
[.col-5]
****
.Collective ownership
image::collective-ownership.png[align=center]
****
[.col-7]
* Any programmer can change any piece of code at any time.
* Every team member is responsible for the entire system.
--
== 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
== 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.
== Onsite Costumer
* To answer questions, resolve conflicts, set low-level priorities.
* Expensive, but brings a lot to the project.
== Code Conventions
* If anyone can change the code, everyone should use the same convention.
* They have to be adopted by the whole team.
== 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.
== Conclusion (Cont.)
* Simple design
* Automated testing
* Practice in design modification.