Agile Software Development for Software Developers

My Thundertalk: Agile Software Development for Software Developers

It explains the principles and technical foundations necessary to do agile software development.

Transcript

1. Agile Software Development
2. Lots of developers don’t like the term agile.
7. • How long should a daily scrum take? • How can I fit more work in my two weeks cycle? • What does is take go become a certified SCRUM master? What this talk is not about
8. • How to build good software. What this talk is about
9. History of development processes…
10. The Waterfall
11. The Waterfall No idea, if all of this makes sense and if we are doing well. Deadline
12. The Waterfall Test-and-fix interval • Seems To take forever • Guaranteed to break time planning • Nobody is happy at this time
14. The Agile Manifesto
16. Kent Beck • Co-founded XP • “Smalltalk Best Practice Patterns” • “Test-Driven Development by Example” • Started the xUnit trend
17. Martin Fowler • “Refactoring: Improving the Design of Existing Code” • “Patterns of Enterprise Application Architecture“ • Popularized the Dependency Injection pattern
18. Bob Martin aka Uncle Bob • “Clean Code” • “The Clean Coder”
19. Dave Thomas • “Programming Ruby” aka The Pick Axe • “The Pragmatic Programmer” • Coined the term “DRY” • runs The Pragmatic Bookshelf
20. Note: Please compare the books listed here with your weekly “Which books should I read to become a better programmer” Twitter/Reddit/Hacker News thread. ;) These are very good programmers!
21. So… what is this about?
22. Let’s say you want to build a new software product
23. The features
24. There is always a limitation. Time, Money, People, …
25. What features do you want?
26. What features do you want? ALL OF THEM!
27. You start building…
28. But your estimations are bad, because estimations are always bad and you run out of time… DONE DONE DONE DONE
29. So you are running out time (or whatever your limitation is) DONE DONE DONE DONE MAYBE DONE DONE? Next version? #FIXME Forgotten
31. You are here
32. You still haven’t tested it! BUG BUG BUG BUG BUG BUG BUG BUG BUG BUG BUG
33. You can’t have it all. Manage this reality!
34. Agile
35. Agile is about fast iterations
36. Focusing on frequent delivery of visible value
37. Software only delivers value when we ship it and put it to use! If we wait until everything is finished, it takes a long time until we get any value
38. height = value, width = cost
39. Which path makes more sense?
40. Do the high-value & cheap ones first!
41. Do plan, but be ready for change.
42. Why: Because change!
43. Focusing on frequent delivery of visible value What does it take? Got it!
44. This is not All-or-nothing
45. Releases! Feature by Feature
46. • Let’s plan for multiple releases from the very beginning. Multiple releases are easier to manage and deliver value sooner. • We can respond to the changing needs and inputs of business/management
47. “This still sounds a lot like a management process. I am a developer, is this really my concern?”
48. Your role
49. Focusing on frequent delivery of visible value
50. You are always ready to ship!
51. ØFrequent Delivery ØRelease Feature by Feature ØReady to ship at all times
52. • If it takes two days to create a build… • If it takes three days of manual QA to create a build... • If it takes one special person to create the build… • If it takes this one five year old computer that no one dares to update, because this one version of the dependency does not compile on a new OS to create the build….
53. You are always ready to ship!
54. Defects
55. Defects add unknown delay.
56. Everything you build must rest on a solid foundation!
58. •We cannot work effectively in a world of defects •To be able iterate, the software needs to be nearly bug-free all the time •We need to check everything, all the time
59. You must have control over your software.
60. You must have confidence in your software.
61. ØFrequent Delivery ØRelease Feature by Feature ØReady to ship at all times ØEnsure software works as expected
62. The ultimate code quality measurement once you satisfied your current requirement: How easy are future changes?
63. Refactoring Code refactoring is the process of restructuring existing computer code without changing its external behavior. – Wikipedia Refactoring happens within minutes, not within months. Again, in order to refactor efficiently, you need to be able to check everything all the time.
64. ØFrequent Delivery ØRelease Feature by Feature ØReady to ship at all times ØEnsure software works as expected ØEnsure future changes are easy
65. •New features •Architecture •Infrastructure •Hotfixes •Performance optimizations •…
66. Either changing stuff is easy, this means it is good code. Or changing stuff is hard, this means you have a problem.
67. It takes longer to find and fix defects than to prevent them.
68. Hurrying will slow you down • Worse: The timing! It will slow you down when you least need it, close to the end of the project. • Dirty code slows you down. If code is clean, the next features go in smoothly. If it gets dirty, everything takes just a bit longer.
69. Defects create defects Folgefehler: Your math teacher lied to you! If your code is faulty or has side-effects, new code building upon this code will be even more faulty with more side-effects. Fixing, maintaining or extending these layers of faulty code will take even more time!
70. Staying healthy is critical!
71. Focusing on frequent delivery of visible value
72. The ability to quickly iterate on your code is a Technical capability
73. If your tech is not agile, you can not be agile! Automated Builds Always be able to ship! Automated Testing Everything must work all the time! Refactoring Design must improve continually, to make future changes easy!
74. Let’s talk about responsibility
76. Responsibility Would you let your [product owner, scrum master, whatever] decide on: • Code Editor • Programming Language • Design Patterns Probably not!
77. So why let them decide on requirements of technical quality? The need for refactoring? The test coverage? Can this really part of their role? Do the really know? Can they really decide?
78. So why let them decide on requirements of technical quality? The need for refactoring? The test coverage? Can this really part of their role? Do the really know? Can they really decide? No! Only you. You are the coder. You are the expert.
79. Responsibility and authority are aligned • The team itself must decide how much work it can accomplish in the next cycle. • The team itself is responsible for the quality of the solution.
81. It’s hard
82. It’s hard Producing good software is very very complicated.
83. It’s hard Producing good software is very very complicated. It takes a lot of effort and care and passion.
84. It’s hard Producing good software is very very complicated. It takes a lot of effort and care and passion. It takes experts like you to make sure that all of this is worthwhile.
85. Thanks!
86. Acknowledgements
87. 40% off with promo code turkeysale2019 ~ 9 USD for the ebook
88. Shitposting powered by • https://twitter.com/agile_memes • https://twitter.com/markdalgleish