agile.adoc 28.7 KB
Newer Older
Gerson Sunyé's avatar
Gerson Sunyé committed
1 2 3 4 5 6 7 8 9 10 11 12 13 14
:revealjs_center: false
:revealjs_display: flex
:revealjs_transition: none
:revealjs_slideNumber: c/t
:revealjs_theme: stereopticon
:revealjs_width: 1920
:revealjs_height: 1080
:revealjs_history: true
:revealjs_margin: 0
:source-highlighter: highlightjs
:imagesdir: images
:includedir: includes
:sectids!:

15 16
= Agile Software Development

17
== Preamble
18

19 20 21 22 23 24 25
[.columns]
--
[.col-8]
****
.Methods organize Activities
image::development-activities.png[align=center,height=800px]
****
26

27 28 29 30
[.col-4]
[quote]
Methods are guidelines and rules for activity organization
--
31

32
== Agenda
33

34 35 36 37 38 39
* Introduction
* Agile Development Tools
* Agile Development
* Extreme Programming
* Test-driven Development
* Conclusion
40 41

[.impact]
42
== Introduction
Gerson Sunyé's avatar
Gerson Sunyé committed
43

44
== Rapid Software Development
Gerson Sunyé's avatar
Gerson Sunyé committed
45

46 47 48 49 50
* 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
Gerson Sunyé's avatar
Gerson Sunyé committed
51

52
== Agile Development Characteristics
Gerson Sunyé's avatar
Gerson Sunyé committed
53 54 55 56

* Pragmatic development method
** Rapid feedback on development status
** Short development cycles
57 58 59 60 61 62 63

* 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
Gerson Sunyé's avatar
Gerson Sunyé committed
64
** Fast development feedback
65 66 67 68

== Agile Development Characteristics (Cont.)

* Adaptation
Gerson Sunyé's avatar
Gerson Sunyé committed
69 70
** Regular adjustments
** Flexible planning
71 72 73

* Extensive tool support (e.g. automated testing tools)
* Minimal documentation:  focus on tests and high quality code
Gerson Sunyé's avatar
Gerson Sunyé committed
74
* High human implication
75 76 77 78 79 80 81 82 83 84 85 86 87 88
** 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.)
Gerson Sunyé's avatar
Gerson Sunyé committed
89

90 91 92 93 94 95 96
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.
Gerson Sunyé's avatar
Gerson Sunyé committed
97 98 99

== Agile Methods

100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 159 160 161 162 163 164 165 166 167 168 169 170 171 172 173 174 175 176 177 178 179 180 181 182 183 184 185 186 187 188 189 190 191 192 193 194 195 196 197 198 199 200 201 202 203 204 205 206 207 208 209 210 211 212 213 214 215 216 217 218 219 220 221 222 223 224 225 226 227 228 229 230 231 232 233 234 235 236 237 238 239 240 241 242 243 244 245 246 247 248 249 250 251 252 253 254 255 256 257 258 259 260 261 262 263 264 265 266 267 268 269 270 271 272 273 274 275 276 277 278 279 280 281 282 283 284 285 286 287 288 289 290 291 292 293 294 295 296 297 298 299 300 301 302 303 304 305 306 307 308 309 310 311 312 313 314 315 316 317 318 319 320 321 322 323 324 325 326 327 328 329 330 331 332 333 334 335 336 337 338 339 340 341 342 343 344 345 346 347 348 349 350 351 352 353 354 355 356 357 358 359
* 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.
Gerson Sunyé's avatar
Gerson Sunyé committed
360

361 362 363 364 365 366 367 368 369 370 371 372 373 374 375 376 377 378 379 380 381 382 383 384 385 386 387 388 389 390 391 392 393 394 395 396 397 398 399 400 401 402 403 404 405 406 407 408 409 410 411 412 413 414 415 416 417 418 419 420 421 422 423 424 425 426 427 428 429 430 431 432 433 434 435 436 437 438 439 440 441 442 443 444 445 446 447 448 449 450 451 452 453 454 455 456 457 458 459 460 461 462 463 464 465 466 467 468 469 470 471 472 473 474 475 476 477 478 479 480 481 482 483 484 485 486 487 488 489 490 491 492 493 494 495 496 497
[.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
Gerson Sunyé's avatar
Gerson Sunyé committed
498

499 500 501 502 503 504 505 506 507 508 509 510 511 512 513 514 515 516 517 518 519 520 521 522 523 524 525 526 527 528 529 530 531 532 533 534 535 536 537 538 539 540 541 542 543 544 545 546 547 548 549 550 551 552 553 554 555 556 557 558 559 560 561 562 563 564 565 566 567 568 569 570 571 572 573 574 575 576 577 578 579 580 581 582 583 584 585 586 587 588 589 590 591 592 593 594 595 596 597 598 599 600 601 602 603 604 605 606 607 608 609 610 611 612 613 614 615 616 617 618 619 620 621 622 623 624 625 626 627 628 629 630 631 632 633 634 635 636 637 638 639 640 641 642 643 644 645 646 647 648 649 650 651 652 653 654 655 656 657 658 659 660 661
[.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.






[.impact]
== Test-Driven Development
Gerson Sunyé's avatar
Gerson Sunyé committed
662 663 664 665 666 667 668 669 670 671 672 673 674 675 676 677 678 679 680 681 682 683 684 685 686 687 688 689 690 691 692 693 694 695 696 697 698 699 700 701 702 703 704 705 706 707 708 709 710 711 712 713 714 715 716 717 718 719 720 721 722 723 724 725 726 727 728 729 730 731 732 733 734 735 736 737 738 739 740 741 742 743 744 745 746 747 748 749 750 751 752 753 754 755 756 757 758 759 760 761 762 763 764 765 766 767 768 769 770 771 772 773 774 775 776 777 778 779 780 781 782 783 784 785 786 787 788 789 790 791 792 793 794 795 796 797 798 799 800 801 802 803 804 805 806 807 808 809 810 811 812 813 814 815 816 817 818 819 820 821 822 823 824 825 826 827 828 829 830 831 832 833 834 835 836 837 838 839 840 841 842 843 844 845 846 847 848 849 850 851 852 853 854 855 856 857 858 859 860 861 862 863 864 865 866 867 868 869 870 871 872 873 874 875 876 877 878 879 880 881 882 883 884 885 886 887 888 889 890 891 892 893 894 895 896 897 898 899 900 901 902 903 904 905 906 907 908 909 910 911 912 913 914 915 916 917 918 919 920 921 922 923 924 925 926 927 928 929 930 931 932 933 934 935 936 937 938 939 940 941 942 943 944 945 946 947 948 949 950 951 952 953 954 955 956 957 958 959 960 961 962 963 964 965 966 967 968 969 970 971 972 973 974 975 976 977 978 979 980 981 982 983 984 985 986 987 988 989 990 991 992 993 994 995 996 997 998 999 1000 1001 1002 1003

== Traditional development

image::developpement-traditionnel.png[align=center,height=800px]



== Test-driven development

image::tdd-1.png[align=center,height=800px]



== Test-driven development

image::tdd-2.png[align=center,height=800px]



== Test-driven development

image::tdd-3.png[align=center,height=800px]



== Test-driven development

image::tdd-4.png[align=center,height=800px]



== Approach

. Write test cases before the software unit
** Test cases describe what the unit should do
** Before writing the code, tests fail
. Implement the code that makes the test case pass
** After the implementation, test cases should pass



== Development Style

.TDD Mantra : red/green/refactor
. Write tests and make them fail
. Write code to make tests pass
. Refactor

[.notes]
--
 Style, comme KISS (Keep it simple, stupid) ou YAGNI (You Ain't Gonna Need It).
--


== Consequences

* Test cases specify *what* the unit should do, but not *how*.

[.notes]
--
 Les cas de test spécifient ce que le programme doit faire mais pas comment
 il faut associer TDD à des refactorings fréquentsrevoir la structure du codene pas oublier la conceptionGrande importance du test de non-régression quand on refactore les cas de test qui passaient doivent continuer à passer
--


== Consequences

* First, developers think about how to use the unit.
* Second, they think about how to implement it.

[.notes]
--
But in consequence, it leads the developer to ! first think about “how to use”the component (why do we need the component, what’s it for?) ! and only then about “how to implement”. So, it’s a testing technique as well as a design technique ! It results into components that are easy to test. ! It results into components that are easy to enhance and adapt. In the end, there is no code without a test. The developer can tell at any time ! whether everything still works as it should, or ! what exactly does no longer work as it once did.
--


== Consequences

.It is a development approach that results into units that are easy to:
* Unit test
* Enhance and adapt

[.notes]
--
So, it’s a testing technique as well as a design technique ! It results into components that are easy to test. ! It results into components that are easy to enhance and adapt. In the end, there is no code without a test. 
--


== Consequences

.Developers know at any time:
* What works as it should
* What does no longer work as it once did

[.notes]
--
The developer can tell at any time ! whether everything still works as it should, or ! what exactly does no longer work as it once did.
--


== Motivations

* Developers never have free time to write tests
* Tests help developers to overcome complexity.
** Reduces developer's frustration

[.notes]
--
If you intend to test after you‘ve developed the system, you won‘t have the time for testing. "Write the tests before the code! If things get complicated, you might fear that „the system“doesn‘t work. "Execute the tests and get positive feedback (everything still works) or get pointed to the bit that does not / no longer work. If you‘re overwhelmed by the complexity, you get frustrated. "Start with the simplest thing and proceed in tiny steps! 
--


== Plan

* Introduction.
* *TDD and unit tests*
* Strategies.
* Conclusion.



== Development Cycle

.Five steps cycle:
. Write a unit test
. Make it fail
. Write enough code to make it pass
. Check that the test passes
. Eliminate duplicate code, improve design

[.notes]
--
vérifier qu'il échoue (car le code qu'il teste n'existe pas), afin de vérifier que le test est valide;
--


== Benefits

.Test cases become a support to documentation:
* They specify the expected behavior
* They show examples of code usage

[.notes]
--
The test is the executable specification. ! You start thinking about the goal first, then about the possible implementations. ! You understand the program‘s behavior by looking at the tests. The tests tell you more than just an API description, they show the dynamics, how to use the API. You develop just enough. ! You get to the goal as quick as possible. ! You don‘t develop unnecessary code. ! There is no code without a test. ! There is no test without a user requirement. Once you get one test working, you know it is working now and forever. ! You use the tests as regression tests. The tests give us the courage to refactor. ! You can prove that everything still works after the refactoring by simply executing the tests. It‘s more fun that way, it reduces fear. 
--


== Benefits

____
YAGNI (You Ain't Gonna Need It).
____

* Developers only write necessary code
** They only code when a test fails
* No code without test and no test without a user requirement

[.notes]
--
YAGNI (You Ain't Gonna Need It).
You develop just enough. ! You get to the goal as quick as possible. ! You don‘t develop unnecessary code. ! There is no code without a test. ! There is no test without a user requirement. Once you get one test working, you know it is working now and forever. ! You use the tests as regression tests. The tests give us the courage to refactor. ! You can prove that everything still works after the refactoring by simply executing the tests. It‘s more fun that way, it reduces fear.
Pas de code sans test : donc pas de test structurel, pas évident non plus de se servir d’interface de code qui n’existe pas, on a donc des tests fonctionnels à provenance niveau test système.

--

== Benefits

* Rapid feedback on code quality
* Short development cycle iterations
* Code is executed straight away


== Benefits

.Automatic unit tests are reproducible:
* They can be used as non-regression tests and after refactoring.
* They reduce fear on changes

[.notes]
--
 Once you get one test working, you know it is working now and forever. ! You use the tests as regression tests. The tests give us the courage to refactor. ! You can prove that everything still works after the refactoring by simply executing the tests. It‘s more fun that way, it reduces fear. 
--


== Plan

* Introduction.
* TDD and unit tests
* Strategies.
** *Development*
** Debugging
** Maintenance
* Conclusion.

== Development Strategy

. Test often
** to find errors quickly
** to know when it is finished
. Move forward by small steps
** programming and refactoring
. Use automation tools.


== Development Strategy

image::tdd-5.png[align=center,height=800px]



== Plan

* Introduction.
* TDD and unit tests
* Strategies.
** Development
** *Debugging*
** Maintenance
* Conclusion.

== Debugging Strategy

* Repeat:
. Find the most annoying defect
. Write a unit test that exposes it
. Correct the error
. Test
. Refactor
. Test again


== Debugging Strategy

image::debug.png[align=center,height=800px]


== Plan

* Introduction
* TDD and unit tests
* Strategies
** Development
** Debugging
** *Maintenance*
* Conclusion

[.impact]
== Maintenance

== Maintenance

.Legacy code:
____

— Does someone remember who wrote this code?

— Last time someone touched this, we needed 3 weeks to make it work again.

— The documentation is available, but it does not correspond to the code anymore.
____

[.notes]
--
 Legacy code = code patrimonial
--


== Working with legacy code

* Developers must take small steps, like a tightrope walker
* Without forgetting the safety network:
** Unit tests, versioning, backups

[.notes]
--
Go Hunting for BearBuild the Safety NetWork in small incrementsExpect to slow down, then speed upMeasure the results
--

== Maintenance approach

image::legacy.png[align=center,height=800px]


== Maintenance approach

. Try to understand the legacy code. And don't.
. Try to write a unit test based on what they understood. The test fails.
. Improve the test until it passes
. Restart with the next unit.

[.notes]
--
 Write a test to see if you understand :Test FAILS Adapt test (iteratively): Test PASSES Move on to next piece.
--


== Plan

* Introduction.
* TDD and unit tests
* Strategies.
* *Conclusion*.



== Conclusion

* Requirements drive the tests.
* Tests drive the development of the application code.
* No application code is written without writing a failing test first.
* Tests are executed often.
* Tests and code are written in elementary increments.
* Refactoring becomes a continuous operation and is supported by a passing a suite of tests.

[.notes]
--
Tests are collected in a suite and the suite is run frequently, like every time after code is written.Test and code are written in elementary increments.Refactoring is a continuous operation, and is supported by a passing battery of tests.
--


== Benefits

* Reduces debugging time (and bugs)
* Short development cycles
* Tests become part of the software product
* Improve documentation
* Improve code quality
* Reduce maintenance costs
* Increases development speed (less time is spent chasing bugs)

[.notes]
--
Reduces the number of bugs by orders of magnitude,
Increases development speed, because less time is spent chasing bugs.
Improves code quality because of the increased modularity, and continuous and relentless refactoring.
Decreases maintenance costs because the code is easier to follow.
--


== References

1004
* «Extreme programming explained: embrace change». Kent Beck. Addison-Wesley, 1999.
Gerson Sunyé's avatar
Gerson Sunyé committed
1005 1006 1007 1008 1009 1010 1011 1012 1013 1014 1015 1016
* Kanban: Successful Evolutionary Change for Your Business : David Anderson ISBN 978-0984521401 (existe en français http://tinyurl.com/LivreKanban) 
* Product Development Flow : Don Reinertsen - ISBN 978-1935401001
* Kanban pour l'IT : Laurent Morisseau - ISBN 978-2100578672
* Personal Kanban : Jim Benson - ISBN 978-1453802267

== References (Cont.)

* 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