Difference between revisions of "Mission Critical Agile"
Jump to navigation
Jump to search
(Zeroth version.) |
(*{{p|product owner formally accepts results}}) |
||
| Line 31: | Line 31: | ||
*Drive the {{p|product backlog}} order by a {{p|shallow hierarchy of goals}} | *Drive the {{p|product backlog}} order by a {{p|shallow hierarchy of goals}} | ||
*{{p|trunk only}} revisions minimizes or even eliminates the effort to merge, synchronize and coordinate branches and eases configuration management | *{{p|trunk only}} revisions minimizes or even eliminates the effort to merge, synchronize and coordinate branches and eases configuration management | ||
*{{p|product owner formally accepts results}} | |||
==Sources== | ==Sources== | ||
*http://www.tem-sw.com/library/XP%20for%20Large%20System%20Mission%20Critical.pdf | *http://www.tem-sw.com/library/XP%20for%20Large%20System%20Mission%20Critical.pdf | ||
*see sources at {{p|broccoli planning}} | *see sources at {{p|broccoli planning}} | ||
Revision as of 13:34, 29 February 2012
Adopting agile practices for mission critical systems:
- sustainable pace
- broccoli planning, using a season beat as well as a heart beat; use the season beat to deploy small releases (to mitigate risks and grow confidence and credibility); synchronize your releases and system integration tests to the season beat, not the other way around
- use the week out of time between any two consecutive season beats to celebrate and reflect on the previous beat and plan the next
- order the product backlog:
- risk-driven order
- value-driven order
- theme-driven order: adopt a key focus or theme for every season beat
- broccoli governance, a.k.a. sociocracy—in fact, holacracy is the fruitful allegation of agile and sociocracy.
- test-driven development—evolve an ever growing test suite guarantees quality (also see Jini Community Pattern Language)
- continuous integration
- continuous deployment
- acceptance test-driven development
- vibrant personas
- persona teams
- customer on site
- scenarios define the wish
- gilb p-language
- behavior-driven development
- slash the code base—smaller code bases are easier to grasp, contain less bugs; continuously refactor code.
- stable teams
- elegant design—simplicity, efficiency, consistency, completeness, coherence
- identify high-risk areas
- multidisciplinary teams
- cook a team
- pair programming to
- eliminate code review—there's a ton of objective, scientific even, information on why and how pair programming boosts quality, speed and productivity
- spread knowledge and principles, patterns and practices
- evolutionary prototype everything
- Use sacred ceremonies like sprint planning meeting, weekly product backlog grooming meeting, sprint review meeting, daily scrum meeting
- Drive the product backlog order by a shallow hierarchy of goals
- trunk only revisions minimizes or even eliminates the effort to merge, synchronize and coordinate branches and eases configuration management
- product owner formally accepts results