Tweet
Tweet

Slide 1

Slide 1 text

Agile Software Development

Slide 2

Slide 2 text

Lots of developers don’t like the term agile.

Slide 3

Slide 3 text

No content

Slide 4

Slide 4 text

No content

Slide 5

Slide 5 text

No content

Slide 6

Slide 6 text

No content

Slide 7

Slide 7 text

• 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

Slide 8

Slide 8 text

• How to build good software. What this talk is about

Slide 9

Slide 9 text

History of development processes…

Slide 10

Slide 10 text

The Waterfall

Slide 11

Slide 11 text

The Waterfall No idea, if all of this makes sense and if we are doing well. Deadline

Slide 12

Slide 12 text

The Waterfall Test-and-fix interval • Seems To take forever • Guaranteed to break time planning • Nobody is happy at this time

Slide 13

Slide 13 text

No content

Slide 14

Slide 14 text

The Agile Manifesto

Slide 15

Slide 15 text

No content

Slide 16

Slide 16 text

Kent Beck • Co-founded XP • “Smalltalk Best Practice Patterns” • “Test-Driven Development by Example” • Started the xUnit trend

Slide 17

Slide 17 text

Martin Fowler • “Refactoring: Improving the Design of Existing Code” • “Patterns of Enterprise Application Architecture“ • Popularized the Dependency Injection pattern

Slide 18

Slide 18 text

Bob Martin aka Uncle Bob • “Clean Code” • “The Clean Coder”

Slide 19

Slide 19 text

Dave Thomas • “Programming Ruby” aka The Pick Axe • “The Pragmatic Programmer” • Coined the term “DRY” • runs The Pragmatic Bookshelf

Slide 20

Slide 20 text

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!

Slide 21

Slide 21 text

So… what is this about?

Slide 22

Slide 22 text

Let’s say you want to build a new software product

Slide 23

Slide 23 text

The features

Slide 24

Slide 24 text

There is always a limitation. Time, Money, People, …

Slide 25

Slide 25 text

What features do you want?

Slide 26

Slide 26 text

What features do you want? ALL OF THEM!

Slide 27

Slide 27 text

You start building…

Slide 28

Slide 28 text

But your estimations are bad, because estimations are always bad and you run out of time… DONE DONE DONE DONE

Slide 29

Slide 29 text

So you are running out time (or whatever your limitation is) DONE DONE DONE DONE MAYBE DONE DONE? Next version? #FIXME Forgotten

Slide 30

Slide 30 text

No content

Slide 31

Slide 31 text

You are here

Slide 32

Slide 32 text

You still haven’t tested it! BUG BUG BUG BUG BUG BUG BUG BUG BUG BUG BUG

Slide 33

Slide 33 text

You can’t have it all. Manage this reality!

Slide 34

Slide 34 text

Agile

Slide 35

Slide 35 text

Agile is about fast iterations

Slide 36

Slide 36 text

Focusing on frequent delivery of visible value

Slide 37

Slide 37 text

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

Slide 38

Slide 38 text

height = value, width = cost

Slide 39

Slide 39 text

Which path makes more sense?

Slide 40

Slide 40 text

Do the high-value & cheap ones first!

Slide 41

Slide 41 text

Do plan, but be ready for change.

Slide 42

Slide 42 text

Why: Because change!

Slide 43

Slide 43 text

Focusing on frequent delivery of visible value What does it take? Got it!

Slide 44

Slide 44 text

This is not All-or-nothing

Slide 45

Slide 45 text

Releases! Feature by Feature

Slide 46

Slide 46 text

• 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

Slide 47

Slide 47 text

“This still sounds a lot like a management process. I am a developer, is this really my concern?”

Slide 48

Slide 48 text

Your role

Slide 49

Slide 49 text

Focusing on frequent delivery of visible value

Slide 50

Slide 50 text

You are always ready to ship!

Slide 51

Slide 51 text

ØFrequent Delivery ØRelease Feature by Feature ØReady to ship at all times

Slide 52

Slide 52 text

• 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….

Slide 53

Slide 53 text

You are always ready to ship!

Slide 54

Slide 54 text

Defects

Slide 55

Slide 55 text

Defects add unknown delay.

Slide 56

Slide 56 text

Everything you build must rest on a solid foundation!

Slide 57

Slide 57 text

No content

Slide 58

Slide 58 text

•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

Slide 59

Slide 59 text

You must have control over your software.

Slide 60

Slide 60 text

You must have confidence in your software.

Slide 61

Slide 61 text

ØFrequent Delivery ØRelease Feature by Feature ØReady to ship at all times ØEnsure software works as expected

Slide 62

Slide 62 text

The ultimate code quality measurement once you satisfied your current requirement: How easy are future changes?

Slide 63

Slide 63 text

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.

Slide 64

Slide 64 text

ØFrequent Delivery ØRelease Feature by Feature ØReady to ship at all times ØEnsure software works as expected ØEnsure future changes are easy

Slide 65

Slide 65 text

•New features •Architecture •Infrastructure •Hotfixes •Performance optimizations •…

Slide 66

Slide 66 text

Either changing stuff is easy, this means it is good code. Or changing stuff is hard, this means you have a problem.

Slide 67

Slide 67 text

It takes longer to find and fix defects than to prevent them.

Slide 68

Slide 68 text

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.

Slide 69

Slide 69 text

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!

Slide 70

Slide 70 text

Staying healthy is critical!

Slide 71

Slide 71 text

Focusing on frequent delivery of visible value

Slide 72

Slide 72 text

The ability to quickly iterate on your code is a Technical capability

Slide 73

Slide 73 text

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!

Slide 74

Slide 74 text

Let’s talk about responsibility

Slide 75

Slide 75 text

No content

Slide 76

Slide 76 text

Responsibility Would you let your [product owner, scrum master, whatever] decide on: • Code Editor • Programming Language • Design Patterns Probably not!

Slide 77

Slide 77 text

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?

Slide 78

Slide 78 text

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.

Slide 79

Slide 79 text

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.

Slide 80

Slide 80 text

No content

Slide 81

Slide 81 text

It’s hard

Slide 82

Slide 82 text

It’s hard Producing good software is very very complicated.

Slide 83

Slide 83 text

It’s hard Producing good software is very very complicated. It takes a lot of effort and care and passion.

Slide 84

Slide 84 text

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.

Slide 85

Slide 85 text

Thanks!

Slide 86

Slide 86 text

Acknowledgements

Slide 87

Slide 87 text

40% off with promo code turkeysale2019 ~ 9 USD for the ebook

Slide 88

Slide 88 text

Shitposting powered by • https://twitter.com/agile_memes • https://twitter.com/markdalgleish