Pragmatic Process

Transcript

1. Pragmatic Process REALISTIC SOFTWARE DEVELOPMENT METHODS RICHARD GOFORTH ARCHITECT, CEI RCGOFORTH@GMAIL.COM JUNE 11, 2016
2. What is this Process Thing? I DON’T NEED NO STINKING PROCESS
3. Every piece of software was written with a process • Drink and Hack • Process Binder • Everyone Else • Every process has a place
4. Why does the Ultra-Formal Process Exist? • Process is Integral to the quality and speed that produces software • Consistency • Specialized low failure rate software
5. Where does my process fit? • Someone is deciding that for your project • By accident or on purpose • The way that it has always been done • I read a good book • I heard this talk, and I told all my coworkers that all our future projects should operate like this
6. The Balancing Act Developer Customer Bugs Predictability Cost Satisfaction Interesting Time Process
7. Line of Business Needs • Something that makes or saves money • I don't get paid otherwise • ROI • Cost Estimation • Something we haven’t thought of yet
8. Developer Needs • Interesting Problems (We can’t fix that one) • Fun • Direction • Nothing standing in my way
9. Impractical Process 40 hour Tasks 3 Hours a day in Meetings You will have to wait 3 months for that feature Perfect Estimates 2 Week Waterfall
10. Process as any other Program IF WE WRIGHT THE RIGHT CODE THAT WRITES THE CODE, ALL’S RIGHT
11. Inputs and Outputs Team Project Time Code Satisfaction Business Value
12. Changing the Program • This is the program that we operate in • We have to get the buy in from the team to alter the program • Everyone is part of the code • We can alter and re-factor • We have to be flexible with the process • To find improvements, try out changes • Bugs in our program • Cost time, money, developer satisfaction • These are all just ideas for your process – nothing is “the only way”
13. Measuring the Output Customer Satisfaction • Slow Cycle • Might be too late Developer Satisfaction • Faster Cycle • Morale Bugs Completed Features • Real Numbers • Heavily Weighted
14. The Rise of Agile and Scrum IF YOU CAN’T BEAT ‘EM, PRETEND TO BE THEM AND HOPE THAT THEY DON’T NOTICE THAT YOU ARE A LIAR
15. Agile Versus • What is Agile up against? • Waterfall? • Not often • Just get it done? • Minimal process • Itself? • Good Agile vs Bad Agile
16. Flexible and Realistic • Crux of the concept “Agile” • “No Blockers” • The fully committed sprint • Time left of the table • Story Swapping • High pressure when work was harder than expected • Low pressure when it was easy
17. Daily Meeting WHY WASTE MY TIME WHEN I CAN WASTE EVERYONE’S TIME CONCURRENTLY? THAT’S EFFICIENCY.
18. Fastest way to waste time (and money) 6 people x 90 $/hr x 1/3 hr x 5 days x 50 weeks $45,000 / year
19. I’m OK, the bull is dead • Stolen from a 2004 article by Gopal Kapur (find it by Google search) • Reporting • The right information at the right level of detail Punch Line Current Status Next Steps (Explanation)
20. Keep it short • What is the minimum that everyone else needs to know? • Your time is my time • Leave your ego at the gate • You are not that special • Get help from a smaller group afterward
21. Retrospective HINDSIGHT IS, HISTORY REPEATS… STICK YOUR OWN CLEVER QUOTE IN HERE
22. Changing the process for the better • An open forum for ideas • Worth some time and effort • No seriously, put some time into your ideas before this meeting • Don’t change too fast • Too many variables in the equation • Reasonable and Actionable Results
23. Teams THERE IS NO I IN TEAM, BUT THERE IS A ME… AND TEA… AND MEAT, AND I COULD REALLY GO FOR SNACK RIGHT NOW
24. Exponential (ok, not quite) Communication 2 - 1 3 - 3 4 - 6 5 - 10 6 - 15 7 - 21 8 - 28
25. Team boundaries are part of your process • Group and re-group based on the current work • Prevent the gritty details from being everyone’s problem • Don’t isolate or over-specialize either • Team hierarchy • Not necessarily seniority • Keep the maximum number of people ‘focused’ • Junior dev and the customer
26. Buy In Update your hours/tasks Invest in the process Unify your process across the team
27. The right people in the meeting (this might be tough) • Make it ok to excuse yourself in the middle of a meeting • A culture change • Add as necessary rather than remove • Watch out for the person that just wants to be 'in' on everything (is it you?) • This isn't helpful for them or the project • You have to get over feeling "left out"
28. Estimation THE FEATURE HAS BEEN 90% COMPLETE SINCE I STARTED, JUST CALL ME “PROGRESS BAR”
29. Good Enough
30. Good Enough •Waste of Time To Deep •Doesn’t find all the work To Shallow •Practice and Experience Just Right
31. The Planning Meeting IF THE PANAMA CANAL HAD A PLANNING MEETING THEY WOULD BE STARTING THE WORK TOMORROW
32. Pre-plan • Break down stories into tasks before the meeting • Look for a lot of type spent writing or typing and try to move it out of the meeting • Use this time to analyze the break-downs and look at the approaches that are being taken • Try to do spikes or code-searches beforehand
33. Building a Sprint • 6 hour dev time (or less) in an 8 hour day • Meetings • Help • Fun • Things that don’t count well on a task list • Prevent burn out • What tasks can I really get done today/this week/this sprint
34. Planning to Fail • Bugs happen • Part of the plan • Don’t Ignore bugs until there are sprint of all bugs • No one likes it, and the quality suffers • Fix all the bugs first doesn’t hold up all that well either • Prioritize • But remember the ‘soft’ value of fixing a lot of easy bugs
35. Now This is a Story JUST SIT RIGHT THERE (AND HOPE THIS WASN’T ALL AN ELABORATE BEL-AIR)
36. Features (not bugs) • An accomplishment I can point to
37. Stories Well Defined Testable Not Details Within a Sprint
38. Break it down A Few Small Scenarios • More means we don’t know when we finished Don’t be Afraid of Change • Stories become features, one story becomes several Accurate Estimates • Better estimates feed into a better understanding of what we can deliver
39. Story Points • Minimum useful work • A 3 field form • A simple informational screen • Something everyone can relate to • Multiples of 2 or Fibonacci • Bakes in the inherent inaccuracy in larger estimates • Consistent Estimation is what gives management/LOB insight into team velocity
40. Tasks YOU CAN TASK IF YOU WANT TO, YOU CAN LEAVE YOUR FRIENDS BEHIND, CAUSE YOUR FRIENDS DON’T TASK…
41. When and Who • Probably not everyone • Mentoring starts with task creation • Teach a man to task and he will be warm for the rest of his life • Peer review starts with task review
42. Estimation again • Estimate tasks in real hours (or not) • They are small enough pieces to think of in hours • See if the story points made sense on the story after the implementation details are considered
43. Spikes and Timeboxes are Tasks • Discovery is a large part of coding • Decide on an implementation afterward • Don’t be afraid to add/edit/remove tasks in a story while it is in progress • Timebox research tasks
44. This is wasting my time! Tasking is coding Think about how it is going to go Easier to re-write and move around than code A to-do list I can come back to after distraction
45. The Pragmatist’s Process CONCLUSIVE EVIDENCE OF SOMETHING
46. The Rules • Always Improve • Measure what you want to improve • Remember the value of squishy things like morale and satisfaction • Don’t waste time • Unless it is fun • Avoid nit-picks that don’t add value • Question the way you have always done it