What are some of the lessons the agile community can learn from the Carnegie Mellon Software Engineering Institute (SEI)? (
http://www.sei.cmu.edu/about/about.html) What is some of the common ground?
- The SEI's big emphasis on early direct participation by a broad range of stakeholders.
- The SEI's architectural emphasis on using "quality attributes", expressed in specific testable scenarios, to drive early architectural decisions, has power. (Attributes include: performance, modifiability, security, reliability, etc.) The representation is that in 2-3 hours of making architectural decisions based on the top ~5 quality-attribute scenarios, the major architectural structure can be understood. Then by playing through more scenarios and adding on the functional requirements, the architecture can be gradually filled out. That 3-hour investment sounds very worthwhile even for small projects. (Attribute-driven development: http://www.sei.cmu.edu/plp/add_method.html) This is essentially a SpikeSolution.
- The SEI's perspective on documenting software architectures offers numerous gems. Examples:
- de-emphasis of specific tools and pointing out limitations of UML for architecture
- simple text-based representations of decomposition.
- This is essentially a SystemMetaphor.
- Product-line architecture. "A software product line (SPL) is a set of software-intensive systems that share a common, managed set of features satisfying the specific needs of a particular market segment or mission and that are developed from a common set of core assets in a prescribed way." Source: http://www.sei.cmu.edu/productlines/index.html SEI comments on reuse: "In a software product line approach, the reuse is planned, enabled, and enforced—the opposite of opportunistic. The asset base includes those artifacts in software development that are most costly to develop from scratch—namely, the requirements, domain models, software architecture, performance models, test cases, and components. All of the assets are designed to be reused and are optimized for use in more than a single system. The reuse with software product lines is comprehensive, planned, and profitable." Source: http://www.sei.cmu.edu/productlines/frame_report/pl_is_not.htm
- How can that be done in an agile way?
- Is it the logical extension of refactoring to eliminate duplication?
- What is an alternative agile approach(s) to developing software for a company that has many products that could share things?
- Maybe treat the entire set of similar projects as one large project that has several deliverable configurations. Add or remove configurations as you add or remove products. The main problem I see is that it wouldn't scale past about 10 developers total.
References:
CategoryAgileMethodology
Agile Lessons From The Sei
EditText of this page
(last edited June 11, 2005)