Difference between revisions of "Mission Critical Agile"

From Pearl Language
Jump to navigation Jump to search
(*{{p|product owner formally accepts results}})
 
(8 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}}—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”:


Sources

Other pearls