Add new course: Agile Software Development

- Add new Images
- Add slides about XP
- Add better introduction

.bowerrc

-{
-  "directory": "bower_components"
-}

Gemfile

@@ -4,3 +4,4 @@ gem 'asciidoctor'
 gem 'asciidoctor-revealjs'
 gem 'asciidoctor-diagram'
 gem 'asciidoctor-pdf'
+gem 'prawn-gmagick'

src/asciidoc/agile.adoc

@@ -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.
+