Software development rhythms harmonizing agile practices for synergy
An accessible, innovative perspective on using the flexibility of agile practices to increase software quality and profitability When agile approaches in your organization don't work as expected or you feel caught in the choice between agility and discipline, it is time to stop and think about...
Saved in:
| Main Authors: | , |
|---|---|
| Format: | eBook |
| Language: | English |
| Published: |
Newark
Wiley
2008
John Wiley & Sons, Incorporated Wiley-Blackwell |
| Edition: | 1st ed. |
| Subjects: | |
| ISBN: | 0470073861, 0470192666, 9780470073865, 9780470192665, 0470192674, 9780470192672 |
| Online Access: | Get full text |
| Tags: |
Add Tag
No Tags, Be the first to tag this record!
|
Table of Contents:
- 4.1.4 Turn Everyone into a Programmer -- 4.1.5 Pattern Language -- 4.1.6 Software Team Capability -- 4.1.7 Rough-Cut Design -- 4.1.8 Training Is Not a Solution -- 4.2 Nothing Faster than Plagiarism -- 4.2.1 Immorality -- 4.2.2 Unprecedented Code -- 4.2.3 People Network -- 4.2.4 Rhythm for Plagiarism -- 4.2.5 Plagiarism at Work -- 4.3 Business and Rhythm for Plagiarism -- 4.3.1 15-Minute Business Presentation -- 4.3.2 Marketing Research -- 4.3.3 Chatting Robot -- 4.3.4 Old Song, New Singer -- References -- 5 PAIR PROGRAMMING -- 5.1 Art and Science -- 5.1.1 The Right Partner -- 5.1.2 Noisy Programming -- 5.1.3 Just Training -- 5.1.4 Pay to Watch -- 5.2 Two Worlds -- 5.2.1 Moneyless World -- 5.2.2 Money-Led World -- 5.2.3 Economics -- 5.2.4 Mythical Quality-Time -- 5.2.5 Elapsed Time Accelerated -- 5.2.6 Critical Path Method -- 5.2.7 Why Two, Not Three: The Antigroup Phenomenon -- 5.2.8 Software Requirements Are Puzzles -- 5.3 Programming Task Demands -- 5.3.1 2 and 4 Is 6 -- 5.3.2 2 and 4 Is 4 -- 5.3.3 2 and 4 Is 3 -- 5.3.4 2 and 4 2 -- 5.3.5 2 and 4 is Unknown -- 5.4 Pair Programming Is More than Programming -- 5.4.1 Design by Code -- 5.4.2 Pair Design -- 5.4.3 Rhythmic Pair Programming -- 5.5 Pair Programming Team Coached -- References -- 6 REPEAT PROGRAMMING -- 6.1 Controversies in Pair Programming -- 6.1.1 Is Programming a Unique Work? -- 6.1.2 Are Three Minds Better than Two? -- 6.1.3 Unreplicable Experiments -- 6.2 Repeat Programming -- 6.2.1 Variances -- 6.2.2 Principles -- 6.2.3 Triple Programming Unproductive -- 6.3 Rhythm: Pair-Solo-Pair-Solo -- 6.3.1 Persistence -- 6.3.2 Connection -- 6.3.3 Motivation -- 6.4 An Exception that Proves Brooks´ Law -- 6.4.1 Low Morale -- 6.4.2 Communication Costs -- 6.4.3 Rhythm for Late Projects -- References -- 7 AGILE TEAMING -- 7.1 Project Teams -- 7.1.1 Self-Organizing Teams -- 7.1.2 Teams in a Team
- 9.4.5 Software Configuration -- 9.4.6 People Discipline -- References -- EPILOGUE: MEDLEY -- INDEX
- 7.1.3 Project Team Composition -- 7.1.4 Team Lifecycle versus Learning Curve -- 7.2 Productivity -- 7.2.1 The Illusion of Productivity -- 7.2.2 Collective Code Ownership -- 7.2.3 Accountability, Responsibility, and Transparency -- 7.3 Problems and Problem Owners -- 7.3.1 Rhythm: Trouble-Restructuring -- 7.3.2 Teaming Principles -- 7.4 Failing Projects Rescued -- 7.4.1 Project Traffic Light Reporting -- 7.4.2 A Business Case -- 7.4.3 Steering Committee Meeting -- 7.4.4 Agile Teaming in Action -- 7.5 Beware of Iago -- References -- 8 INCREMENTAL DESIGN -- 8.1 Modeling and Planning -- 8.1.1 Agile Planning -- 8.1.2 Design by Functional Modules -- 8.1.3 Simple Design -- 8.1.4 Total Cost Concept -- 8.2 Rework or Reuse -- 8.2.1 Unpreventable Rework -- 8.2.2 Improvisation -- 8.2.3 Up-Front Design -- 8.3 Just-in-Time Software Development -- 8.3.1 The CMM Rhythm -- 8.3.2 A Factory Tour -- 8.3.3 Walking Worker -- 8.3.4 Just-in-Time Software Development -- 8.3.5 Incremental Design -- 8.4 Requirements Complexity -- 8.4.1 Forgotten Requirements -- 8.4.2 Conflicting Requirements -- 8.4.3 Rapidly Changing Requirements -- 8.4.4 Requirements and Design -- 8.5 Refactoring -- 8.5.1 Refactoring Activities -- 8.5.2 Refactoring by Challenging -- 8.5.3 Refactoring for Design Patterns -- 8.5.4 Making Deliberate Mistakes -- References -- 9 TEST-DRIVEN DEVELOPMENT -- 9.1 Reverse Waterfall -- 9.1.1 Design-Code-Test -- 9.1.2 Test-Code-Design -- 9.2 Test-First Programming -- 9.2.1 Testing and Verification -- 9.2.2 Breakpoint Testing -- 9.2.3 Supporting Practices -- 9.3 Rhythm: Test-Code-Refactor -- 9.3.1 Simple Example -- 9.3.2 Automation -- 9.3.3 Revolution in Consciousness! -- 9.3.4 Test Case for Collaboration -- 9.4 Rapid Software Process Improvement -- 9.4.1 Training Program -- 9.4.2 Project Planning -- 9.4.3 Project Tracking -- 9.4.4 Software Quality
- Intro -- SOFTWARE DEVELOPMENT RHYTHMS -- CONTENTS -- PREFACE -- Special Acknowledgment -- Part I: Essentials -- 1 NO PROGRAMMER DIES -- 1.1 Developing Software versus Building a Tunnel -- 1.1.1 The Good Old Days? -- 1.1.2 The More Things Change, the More They Stay the Same? -- 1.1.3 Behind Software Products -- 1.1.4 Deal or No Deal -- 1.2 Do-Re-Mi Do-Re-Mi -- 1.2.1 Iterative Models -- 1.2.2 Code and Fix -- 1.2.3 Chaos -- 1.2.4 Methodology that Matters -- 1.3 Software Development Rhythms -- 1.3.1 Stave Chart by Example -- 1.3.2 Game Theory -- 1.3.3 In-Out Diagram -- 1.3.4 Master-Coach Diagram -- 1.3.5 No Mathematics -- 1.3.6 Where to Explore Rhythms -- References -- 2 UNDERSTANDING PROGRAMMERS -- 2.1 Personality and Intelligence -- 2.1.1 Virtuosi -- 2.1.2 Meeting Your Team -- 2.1.3 Recruiting Programmers -- 2.2 Outsourced Programmers -- 2.2.1 Programmers in Their Environments -- 2.2.2 Programmers, Cultures, and Teams -- 2.3 Experienced Management -- 2.3.1 Being Casual about Causal Relationships -- 2.3.2 Not Learning from Experience -- 2.3.3 Doing Things Right Right Now -- References -- 3 START WITH OPEN SOURCE -- 3.1 Process and Practice -- 3.1.1 The Four Ps of Projects -- 3.1.2 Agile Values -- 3.1.3 Zero-Point Collaboration -- 3.2 Open-Source Software (OSS) Development -- 3.2.1 Software Cloning -- 3.2.2 Software Quality -- 3.2.3 Starting Processes -- 3.2.4 Open-Source Development Community -- 3.2.5 Ugrammers -- 3.2.6 Participant Roles -- 3.2.7 Rapid Release -- 3.2.8 Blackbox Programming -- 3.2.9 OSS Practices -- 3.3 OSS-Like Development -- 3.3.1 Agile Practices -- 3.3.2 Communication Proximity -- 3.3.3 Loose and Tight Couples -- 3.3.4 Collocated Software Development -- 3.4 Conclusion -- References -- Part II: Rhythms -- 4 PLAGIARISM PROGRAMMING -- 4.1 Plagiarism -- 4.1.1 Existing Code -- 4.1.2 Social Network Analysis -- 4.1.3 Being Plagiarized