1 / 23

### Balancing Agility and Discipline: Lessons from Lease Management and Command Center Projects ###

This chapter reviews the balance of agility and discipline in software development, featuring two case studies: a lease management project and the Command Center Processing and Display System Replacement (CCPDS-R). The lease management project highlights significant challenges such as increased development time, integration issues, and customer complaints due to a lack of understanding of user needs. Key lessons emphasize the importance of architectural planning and the risks of simple designs in large projects. Ultimately, hybrid approaches merging agile and traditional methodologies can yield successful results. ###

amethyst-norton
Télécharger la présentation

### Balancing Agility and Discipline: Lessons from Lease Management and Command Center Projects ###

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Balancing Agility and DisciplineChapter 4 Sharon Beall EECS 811 April 22, 2004

  2. Agenda • Lease Management Example • Command Center Processing and Display System Replacement (CCPDS-R) Example • Home Ground Charts • Summary

  3. Lease ManagementThe Project • Leasing industry • 500 KLOC • 30 developers • 20 participants • 1,000 story cards • 18 months with traditional approach • 36 months with XP

  4. Lease Management Eight “Bad Smells” 1. Time to develop story card increased in later iterations • Iteration length static • Too much tacit knowledge required • Stories subdivided to meet schedules

  5. Lease ManagementEight “Bad Smells” 2. Integrating functions problematic in later iterations • Individual tests okay • Failed integration with other functions • High-level architectural plan developed

  6. Lease ManagementEight “Bad Smells” 3. Unit and system testing issues • Tacit knowledge strain again • Complex specialized functions • Breaking tests, architecture • High-level architectural plan assisted

  7. Lease ManagementEight “Bad Smells” 4. Customer complaints • No complaints until later iterations • Customer never understood real user needs • Early coaching necessary

  8. Lease ManagementEight “Bad Smells” 5. Integration, Schedules, and Effort • Misrepresented accomplishments • Story cards taking extra effort than portrayed • Created task list for each story • Monitored by management

  9. Lease ManagementEight “Bad Smells” 6. Refactoring Never Done • Developers knew refactoring was needed • Busy doing assigned work • Detailed work plans and task lists included refactoring

  10. Lease ManagementEight “Bad Smells” 7. Simple design and YAGNI drawbacks • Developers continuously refactoring some modules • High costs since future changes known for those modules • Adopted a pattern for this module after some time (YAGNI – You Aren’t Going to Need It)

  11. Lease ManagementEight “Bad Smells” 8. Test drivers and re-use • Normally simple design and YAGNI • Due to size and number of objects, different tests with similar drivers for different object states • Adopted a pattern for test drivers as well

  12. Lease ManagementLessons Learned • Tacit knowledge is agile, however with large software projects, presents scaling problems • To diverge from an agile process requires talented people to recognize and respond • Simple design is risky on large projects with known change

  13. Lease ManagementExtending XP • High level architectural plans • Definitions of milestones and completion criteria • Usage of patterns and architectural solutions Authors note…scale agile processes as-needed and as-discovered!

  14. CCPDS-RThe Project • Re-engineer command center for missile warning system • 1 million lines of code • 75 programmers • 3 user sets • 48 months

  15. CCPDS-RAgile Manifesto Individuals and Interactions over Processes and Tools TRW versus DoD • DoD milestone standards redefined to reflect stakeholder’s interest. Use of automated tools to verify software to specs. • Contract award fees designated for personnel • System architecture organized for developers’ skill levels

  16. CCPDS-RAgile Manifesto Working Software over Comprehensive Documentation • DoD requires Preliminary Design Review (PDR) with docs and charts • TRW chose to put it off until software could be demonstrated • Documentation generated for those who really really needed it

  17. CCPDS-RAgile Manifesto Customer Collaboration over Contract Negotiation • Win-win idea used to negotiate contracts • Ada version of COCOMO used • Allowed for savings via reuse (if Agile, would have been costs due to YAGNI and rework)

  18. CCPDS-RAgile Manifesto Responding to Change over Following a Plan • Plans and specs were machine processable • Metrics tracked progress in identifying problems • Allowed easy tracking and early fixes • Easy adaptation of plans • Advance work in software reuse amongst 3 customer sets

  19. CCPDS-R Extending Plan-Driven Methods • A win-win customer driven view can be combined with a process-document driven view • Award fees generated for TRW developers

  20. Summary • Examples that hybrids can succeed • Easily tailoring the process not published • Taking parts of each method to complement a given project is not easy, but can be successful • …Guidelines in the next chapter to do this!

  21. Closing Questions? Comments?

More Related