Stop the line

Detta är en Ignite spoken word performance, första gången framförd på konferensen Agila Sverige 2012.

Av Peter Antman

Peter Antman är agil management coach på Crisp, just nu med uppdrag på Spotify. Hans vision är den goda arbetsplatsen som skapar värde till kunderna, medarbetarna, företaget och samhället.

Transcript

1. Stop the line Ignite Peter Antman April 2012
2. The Atex Polopoly WebCMS product !Existed for 16 year !Large code base !Large user base !Thousands of editors, millions of users, billions of page views 2
3. Organized around lean principles 3 Pull based Flow Kaizen Stop the line One Feature One Team
4. The Type-G Toyoda Automatic Loom, the world's first automatic loom with a non-stop shuttle-change motion, was invented by Sakichi Toyoda in 1924. This loom automatically stopped when it detected a problem such as thread breakage. 4 http://commons.wikimedia.org/wiki/File:1924_Non-Stop_Shuttle_Change_Toyoda_Automatic_Loom,_Type_G_2.jpg
5. Integrate -> Fix -> Integrate -> Fix ... 5 Compile class Test class Compile module Test module Build product Test product Acceptance test product Test on specific plattform Test with specific configuration At what stage is it possible to continue working even if it’s broken?
6. When work is not automatically stoped - attitudes matter (most) 6 http://geekandpoke.typepad.com/.a/6a00d8341d3df553ef014e8adc7838970d-pi
7. Urban Decay 7 http://fixedgear.se/forum/viewtopic.php?f=1&t=2650&start=20
8. Broken Windows - a sociological theory from 1982 8 http://www.codinghorror.com/blog/2005/06/the-broken-window-theory.html
9. The New York Theorem: Fight big crime by picking litter 9 http://huntington.patch.com/articles/volunteers-clean-up-in-the-station#photo-5852615
10. Broken builds are broken windows 10 http://www.makefive.com/categories/news-business/business/top-5-items-i-sold-on-ebay
11. 11 Clean up GoGreen (adapt to capacity) FixNextSprint (Stop-the-line)
12. A lot of tests - 596 570 12
13. 13 Number of potential, executed and failed test in first half of november 2011
14. 14 Tools Culture
15. How do we fix problems? !Everything must be tested !Faults should be fixed as close to the source as possible !Fix when integration of new code fail !Errors are fixed immediately (if possible) !Examine each failed test, always !New bugs are, !either fixed when standing on them !handled as a ”fix next sprint” (first in line) !put into drawer 15
16. How do we handle all those tests? !Run only when changed (600 000 -> 100 000) !Hide known bugs (KnownBugs) !Integrate !first on ticket branch, !then team test branch, !then team branch, !then branch !Nightly test check responsibility (rotate between teams) !Daily mail on test faults !Tickets for test faults !Indexed in Solr !Annotate in Jenkins 16
17. Fix Next Sprint: never let a window be broken !Bugs discovered by non automated tests are fixed in next sprint !Philosophy: We strive not to produce software with errors !Policy: If it had been covered by a test it would have been fixed immediately !Practically: Old bugs tends to never get fixed (adapt to capacity) 17
18. Analyzing test faults
    18
19. Todo !Build old releases more often (regularly) !Like starting an abandoned car !Move out again (Rackspace?) !Lots of system admin with local cloud !Better handling of Known bugs !Link to ticket !Substitute Selenium (lots of intermittent errors) !Remove as much scripts as possible !Maven and Jenkins, not bash !Tie scripts to release !To complex to handle all possible setup in one place !Enhanced annotations in Jenkins !Comment in Jenkins and Jira, not in mail or wiki !Build images with Puppet or Chef !Declarative images 19
20. It’s a never ending work 20