Agile, etc.

Transcript

1. Agile, etc
2. a!/samphippen
5. This is not a Judgement
6. Everyone always screws up all of their software projects
7. All software projects are always late
8. No customer ever gets everything they want
9. No software is ever done
10. Your primary objective should be to still like everyone
11. Let’s have some questions !!/samphippen sam@funandplausible.com
12. Let’s have some questions !!/samphippen sam@funandplausible.com
13. Let’s have some questions !!/samphippen sam@funandplausible.com
15. The most important lesson
16. If you pay attention to nothing else
17. All computer problems are people problems
18. All computer problems are people problems
19. No software project ever failed for technical reasons
20. Not one
21. “They made us use the wrong database!”
22. Communication is of dire importance
23. Communicate with your clients
24. Communicating with clients
25. You are already commercially proficient as a developer
26. Make your clients believe it
27. Managing clients is its own, separate, complex, skill
28. In the client’s mind the scope is always changing
29. In the client’s mind the scope is infinite
30. You cannot deliver infinite software
31. You cannot deliver to wildly changing goals
32. Establish clear scopes with your client
33. Adjust scopes over time
34. You are allowed to say no to features
35. You are allowed to say no to platforms
36. Hands up time
37. Mobile apps?
38. Both android and iOS?
39. That expectation is unreasonable
40. Strike it now
41. Aim for small, working, and complete
42. Aim for one platform, technology, and framework
43. Explain that aim to your client
44. Be reasonable about what you can achieve
45. Explain what you can achieve reasonably
46. No client can fault you for that
47. Technicals
48. How to not fuck up your project
49. Do not adopt an “Agile” methodology
50. Fixed practises
51. Fixed practises
52. Agile is a toolbox
53. Use the tools that work for you, don’t use the ones that don’t
54. “Works for you” has multiple definitions
55. I find you can intuit when process is slowing you down
56. Watch how much you ship
57. Your process is allowed to change over time
58. Aggressively limit scope
59. Iterate towards client’s goals
60. Minimum viable product?
61. Sign up Login 1 feature
62. Build this to an absolutely rock solid standard
63. Give the client something they can show
64. It is reasonable to assume you will produce an MVP in this project
65. More is bonus points!
66. How to get there?
67. Work with clients to get high level tasks
68. You all have an intuition about how to go from zero to a client’s goals
69. Communicate with your team
70. Form a plan
71. Work out the big tasks
72. Break tasks down
73. Break tasks down to really small units
74. Break tasks down to really small units like really hilariously small
75. Gather the team
76. Turn everything into tasks that will take at most one person day
77. That everyone thinks won’t take more than a day
78. Then take a week to do them
79. Do two if you’re feeling adventurous
80. Show work at the end of two weeks
81. If you can’t break down a task it means two things
82. Client hasn’t explained it well enough
83. Your project isn’t in a state where it can be done yet
84. Focus on things that can immediately be done
85. Two week cycle
86. Meeting with client on monday
87. Read the Backlog
88. Pull items from backlog to be done this cycle
89. Work out if that’s too much work
90. Work out if that’s too much work (it is)
91. Assign work
92. Aim to have work done by end of week
93. Team meeting at end of week
94. Test Find Bugs Refactor
95. Finish features if they’re not done
96. Meeting on friday with client
97. Show work done
98. Reprioritise backlog
99. Repeat
100. You get enough of these cycles to ship something
101. Progress is measurable
102. Client can adjust
103. No “mega features”
104. “Client acceptance”
105. Don’t wait until the end of the project
106. Get it literally every two weeks.
107. Tools
108. Trello
109. Backlog Next up In Progress Done
110. GitHub
111. Do pull requests
112. Don’t merge master unless you’re sure stuff works
113. Two final suggestions
114. Use Java
115. Steer the fuck away from C++
116. Let’s have some questions a!/samphippen sam@funandplausible.com