Eu imagino um bom planejamento de projetos como dirigir à noite com as lanternas ligadas. Podem existir mapas que dirão como ir da Cidade A para a Cidade B, mas a distância que posso ver em detalhes através de meus faróis é limitada. Em projetos de médio ou grande porte, planejamento deve ser mapeado fim-a-fim cedo no projeto. Detalhamento e micro planejamento deve geralmente ser conduzido apenas algumas semanas por vez, e deve ser guiado na forma "just in time".
| Technique | Description | Feedback Period |
| Active Stakeholder Participation | Stakeholders (users, managers, support people, ...) are actively involved with the modeling effort, using inclusive techniques to model storm on a just in time (JIT) basis. | Hours. A stakeholder will describe their requirement(s), then the developer spend several hours, or perhaps day or two, implementing them to produce working software which they can then show to the stakeholder(s). |
| Agile Model Driven Development (AMDD) | AMDD is the agile version of Model Driven Development (MDD). With an AMDD approach, at the start of a project you do some high-level, initial requirements modeling and initial architecture modeling. During development you model storm on a just in time basis. | Hours. With model storming, you explore a requirement with your stakeholder(s) or a technical issue with other developers and then spend several hours or days implementing working software. |
| Big Design Up Front (BDUF) | With a BDUF approach, a comprehensive design document is developed early in the project lifecycle which is used to guide the implementation efforts. | Months. It is typically months, and sometimes years, before stakeholders are shown working software which implements the design. |
| Big Requirements Up Front (BRUF) | With a BRUF approach, a comprehensive requirements document is developed early in the project lifecycle which is used to guide the design and implementation efforts. | Months. It is typically months, if not years, before stakeholders are shown working software which implements their requirements. |
| Code Inspections | A developer's code is inspected by her peers to look for style issues, correctness, ... | Days to Weeks. Many teams will schedule reviews every Friday afternoon where one person's code is inspected, rotating throughout the team. It may be weeks, or even months, until someone looks at the code that you've written today. |
| Continuous Integration | The system is built/compiled/integrated on a regular basis, at least several times a day, and ideally whenever updated source code is checked into version control. Immediately after the system is built, which is often done in a separate "project integration sandbox" it is automatically tested. | Minutes. You make a change to your code, recompile, and see if it works. |
| Model With Others | The modeling version of pair programming, you work with at least one other person when you're modeling something. | Seconds. You're discussing the model as you're creating it, and people can instantly see a change to the model made by someone else. |
| Model/Documentation Reviews | A model, document, or other work product is reviewed by your peers. | Days to Weeks. A work product will be created, the review must be organized, materials distributed, ... The implication is that it can be weeks, or even months, before the item is reviewed. |
| Pair Programming | Two developers work together at a single workstation to implement code. | Seconds. You're working together to develop the code, the second coder is watching exactly what the person with the keyboard is doing and can act on it immediately. |
| Test Driven Design (TDD) | With TDD, you iteratively write a single test then you write sufficient production code to fullfill that test. | Minutes. By implementing in small steps like this, you quickly see whether your production code fulfills the new test. |
| Traditional Acceptance and System Testing | Acceptance testing attempts to address the issue "does the system do what the stakeholders have specified". System testing, including functional, load/stress, and integration testing, attempts to address the issue "does the system work". With traditional testing the majority of testing occurs during the testing phase late in the lifecycle. Testers will write test cases, based on the requirements, in parallel with implementation. | Months. By waiting until the system is "ready for testing", the testers won't see the system until months after the requirements are finalized. |
Termo muito importante no mundo Ágil... eu disse muito? Eu quis dizer MUITO!
We do Agile at Google in response to real need, to provide real results, not because someone thought it would be a cool thing to do.
Results From Scrum
The benefits of Scrum reported by teams come in various aspects of their experience. At Yahoo!, we have migrated nearly 90 projects to Scrum in the last 30 months, totaling almost 900 people, and the list of teams using it is quickly growing. These projects have ranged from consumer-facing, design-heavy websites like Yahoo! Photos, to the mission-critical back-end infrastructure of services like Yahoo! Mail, which serves hundreds of millions of customers; they range from entirely new products like Yahoo! Podcasts, which used Scrum from concept through launch (and won a Webby Award for best product in its category that year), to more incremental projects, which included work on new features as well as bug fixes and other maintenance; and we’ve used Scrum for distributed projects, where the team is on separate continents. Several times each year we survey everyone at Yahoo! that is using Scrum (including Product Owners, Team Members, ScrumMasters, and the functional managers of those individuals) and ask them to compare Scrum to the approach they were using reviously.