Difference between revisions of "Mission Critical Agile"
Jump to navigation
Jump to search
({{p|prune any code}}) |
m (→Other pearls: typo) |
||
(7 intermediate revisions by the same user not shown) | |||
Line 1: | Line 1: | ||
Adopting agile practices for mission critical systems: | {{tag|quality}} | ||
Adopting agile practices for mission critical systems, creating a “insurance policy”: | |||
*{{p|sustainable pace}} | *{{p|sustainable pace}} | ||
*{{p|broccoli planning}}, using a {{p|season beat}} as well as a {{p|heart beat}}; use the {{p|season beat}} to deploy {{p|small releases}} (to mitigate risks and grow confidence and credibility); synchronize your releases and system integration tests to the {{p|season beat}}, not the other way around | *{{p|broccoli planning}}, using a {{p|season beat}} as well as a {{p|heart beat}}; use the {{p|season beat}} to deploy {{p|small releases}} (to mitigate risks and grow confidence and credibility); synchronize your releases and system integration tests to the {{p|season beat}}, not the other way around | ||
Line 11: | Line 12: | ||
*{{p|continuous integration}} | *{{p|continuous integration}} | ||
*{{p|continuous deployment}} | *{{p|continuous deployment}} | ||
*{{p|acceptance test-driven development}} | *{{p|acceptance test-driven development}} using Gherkin language to specify acceptance criteria that can be tested automatically. | ||
*{{p|vibrant persona}}s | *{{p|vibrant persona}}s | ||
*{{p|persona team}}s | *{{p|persona team}}s | ||
Line 18: | Line 19: | ||
*{{p|gilb p-language}} | *{{p|gilb p-language}} | ||
*{{p|behavior-driven development}} | *{{p|behavior-driven development}} | ||
*{{p|slash the code base}} and {{p|prune any code}}—smaller code bases are easier to grasp, contain less bugs; continuously {{p|refactor code}}. | *{{p|slash the code base}} and {{p|prune any code}}—smaller code bases are easier to grasp, contain less bugs; continuously {{p|refactor code}} using an ordered {{p|refactoring wish list}}. | ||
*{{p|stable teams}} | *{{p|stable teams}} | ||
*{{p|elegant design}}—simplicity, efficiency, consistency, completeness, coherence | *{{p|elegant design}}—simplicity, efficiency, consistency, completeness, coherence | ||
Line 32: | Line 33: | ||
*{{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}} | *{{p|product owner formally accepts results}} | ||
*{{p|foreign eyes audit quality}}—use an external party that reviews, audits, scrutinizes the product as a whole. | |||
*Aim for {{p|low defect density}}, defined as the number of SIT (System Integration and Test) found defects per KLOC. | |||
*Set a {{p|bug count ceiling}} and {{p|technical debt ceiling}} and make them come down. | |||
*Define {{p|criticality class governs rigour}} (see http://artisansoftwareconsulting.com/blogs/?tag=agile-development) | |||
==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}} | ||
*http://www.niwotridge.com/PDFs/ADC%20Final.pdf | |||
*http://arxiv.org/pdf/cs/0701010.pdf | |||
*http://artisansoftwareconsulting.com/blogs/?tag=agile-development | |||
*http://www.agilejournal.com/articles/columns/case-studies/313-case-study-war-stories-fighter-jets-and-agile-development-at-lockheed-martin | |||
*http://www.agilejournal.com/articles/columns/case-studies | |||
==Other pearls== | |||
*{{p|yesterday’s weather}} |
Latest revision as of 14:02, 12 July 2013
Adopting agile practices for mission critical systems, creating a “insurance policy”:
- 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 using Gherkin language to specify acceptance criteria that can be tested automatically.
- vibrant personas
- persona teams
- customer on site
- scenarios define the wish
- gilb p-language
- behavior-driven development
- slash the code base and prune any code—smaller code bases are easier to grasp, contain less bugs; continuously refactor code using an ordered refactoring wish list.
- 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
- foreign eyes audit quality—use an external party that reviews, audits, scrutinizes the product as a whole.
- Aim for low defect density, defined as the number of SIT (System Integration and Test) found defects per KLOC.
- Set a bug count ceiling and technical debt ceiling and make them come down.
- Define criticality class governs rigour (see http://artisansoftwareconsulting.com/blogs/?tag=agile-development)
Sources
- http://www.tem-sw.com/library/XP%20for%20Large%20System%20Mission%20Critical.pdf
- see sources at broccoli planning
- http://www.niwotridge.com/PDFs/ADC%20Final.pdf
- http://arxiv.org/pdf/cs/0701010.pdf
- http://artisansoftwareconsulting.com/blogs/?tag=agile-development
- http://www.agilejournal.com/articles/columns/case-studies/313-case-study-war-stories-fighter-jets-and-agile-development-at-lockheed-martin
- http://www.agilejournal.com/articles/columns/case-studies