Patterns for Agile Development
Suhas Kamasetty, Aishwarya Khaire,
Yilan Li, Nitish Bhaskar, Alisha Hegde
Agile Development
❏ A set of principles
❏ Iterative
❏ Time-boxed
❏ Collaborative
Implementer Estimates Task
❏ Context
❏
You are a developer on agile team and you are estimating the individual tasks.
❏ Problem
❏ The team needs accurate estimates of the time needed to perform the task.
❏ Forces
❏ Straightforward tasks are estimated quickly and accurately.
❏ Estimates are not perfect.
❏ The story estimate done earlier has less certainty.
❏ Solution
❏ When you pick up a task card to implement it, re-estimate the task.
(Set Aside) Enough Time
❏ Context
❏ You are estimating a story or task.
❏ Problem
❏ Talking to the customer, testing and infrastructure work take time.
❏ Forces
❏ Many tasks have necessary prerequisites.
❏ Testing will take a significant fraction of time it takes to build the task.
❏ You may need to Spike to understand the requirements.
❏ Solution
❏ Include in your estimates of tasks the time needed to for all the work.
Spike
❏ Context
❏ You don’t understand how to estimate a task or you don’t know how to implement it.
❏ Problem
❏ Wild guessing can be dangerous.
❏ Forces
❏ You need to estimate Enough Time.
❏ You can learn something by building a simple thrown away design.
❏ Experimentation takes time and effort.
❏ Solution
❏ When you don’t know how to do something, build some throwaway code or create a
throwaway design to investigate the issue.
Promiscuous Programming
❏ Context
❏ You are about to begin a task or subtask and are looking for a partner for Pair Programming.
❏ Problem
❏ No one person should become a knowledge bottleneck with respect to any aspect of the project or its
artifacts.
❏ Forces
❏ Feel more comfortable with some team members than others
❏ You want to build trust and knowledge in the team.
❏ You want to improve your own skill and you want those with less to get up to speed.
❏ Solution
❏ Switch partners for every task at least.
❏ Spread the knowledge of the code and of the programmers throughout the team.
Documentation Is Just Another Task
❏ Context
❏ You will need documentation, both user level and system
level.
❏ You have not gathered all the requirements up front, but
you need to document requirements as well as decisions
made.
❏ Problem
❏ You must prepare all necessary documentation and you
must keep it in sync with the evolving project even as it
changes.
Documentation Is Just Another Task
❏ Forces
❏ The project requirements are changing constantly.
❏ If you leave documentation to the end, it won't get done, or will get done poorly.
❏ If documentation is not consistent with what you have built it is worse than worthless.
❏ Solution
❏ Treat documentation creation and updating as just another task. Estimate it and refactor
it as you would a programming task.
❏ When a project changes direction, the documentation, like the code, must change or be
discarded.
Question Implies Acceptance Test
❏ Context
❏ You are a customer and someone asks you a question about the project. You want your answer to be
faithfully captured by the development process.
❏ Problem
❏ If the answers to questions aren't captured reliably and accurately, the answer could get lost or
misinterpreted.
❏ Forces
❏ Answers to some questions invalidate answers to questions previously asked.
❏ If requirements become inconsistent you need the inconsistencies to show up dramatically and early.
❏
Solution
❏ Whenever you, the customer, answer a question on a story or task, immediately write an acceptance test
that will verify that the answer is codified in the resulting application.
Re-Estimate Periodically
❏ Context
❏ You are a developer, and have a bit of time in development phase
Re-Estimate Periodically
❏ Context
❏ You are a developer, and have a bit of time in development phase
❏ Problem
❏ Estimates become obsolete over time
Re-Estimate Periodically
❏ Context
❏ You are a developer, and have a bit
of time in development phase
❏ Problem
❏ Estimates become obsolete over time
❏ Forces
❏ What you thought to be easy may now be hard to integrate into the code base
❏ Hard task may now be easy as you have support for it already in code
❏ You may know more than you did when you first estimated the story. It may have a
different meaning now than it did earlier
Re-Estimate Periodically
❏ Why do we need estimates to be accurate?
❏ Basis for long-term projection for project management
❏ Failing to have accurate estimates will complicate the Sprint Planning
Re-Estimate Periodically
❏ Why do we need estimates to be accurate?
❏ Basis for long-term projection for project management
❏ Failing to have accurate estimates will complicate the Sprint Planning
❏ Solution
❏ In every iteration, take some time to re-estimate a few of the stories that the customer
believes to be of high value
Re-Estimate Periodically
❏ Why do we need estimates to be accurate?
❏ Basis for long-term projection for project management
❏ Failing to have accurate estimates will complicate the Sprint Planning
❏ Solution
❏ In every iteration, take some time to re-estimate a few of the stories that the customer
believes to be of high value
❏ Other Strategies
❏ Spike - Build a prototype
❏ Make a consciously high estimate to cover uncertainty
❏ Split the stories
Stand Up Meeting
❏ Context
❏ You are an agile team. It is 8am on any day of the development phase
Stand Up Meeting
❏ Context
❏ You are an agile team. It is 8am on any day of the development phase
❏ Problem
❏ A person receiving information may not know the consequences that it implies for others
Stand Up Meeting
❏ Context
❏ You are an agile team. It is 8am on any day of the development phase
❏ Problem
❏ A person receiving information may not know the consequences that it implies for others
❏ Forces
❏ Software development works best when everyone knows what is going on
❏ You may need to know where you are and where you are headed in the short term
❏ Changes in business may make somethings especially important or unimportant in short
term
❏ Long meetings waste everyone’s time
Stand Up Meeting
❏ Solution - Hold a 15 minute stand-up meeting every day
❏ If you don’t stand up, the meeting will last too long
❏ The customer is present as well as the rest of the team
Stand Up Meeting
❏ Solution - Hold a 15 minute stand-up meeting every day
❏ If you don’t stand up, the meeting will last too long
❏ The customer is present as well as the rest of the team
❏ Consequences
❏ Short meetings can bring everyone up to speed and let everyone know the current level
of risk
❏ SCRUM rule - say what you worked on yesterday, say what you will work on today, say
what obstacles you see to your success
❏ If it becomes just an empty ritual, then consider an on-demand stand-up as needed
Test First
❏ Context
❏ You are a developer in the development phase of a project. (Programming phase)
Test First
❏ Context
❏ You are a developer in the development phase of a project. (Programming phase)
❏ Problem
❏ Tests written after a task is coded, often tests what was done, not what is wanted
Test First
❏ Context
❏ You are a developer in the development phase of a project. (Programming phase)
❏ Problem
❏ Tests written after a task is coded, often tests what was done, not what is wanted
❏ Three ways to fail when you write tests after the code
❏ Time constraints will push you away from writing the tests
❏ You will be tempted to get too creative when programming, thinking that some extension
could be easily added. So why not?
❏ You will spend time in the coding process doing design without capturing your decisions
in tests
Test First
❏ Context
❏ You are a developer in the development phase of a project. (Programming phase)
❏ Problem
❏ Tests written after a task is coded, often tests what was done, not what is wanted
❏ Three ways to fail when you write tests after the code
❏ Time constraints will push you away from writing the tests
❏ You will be tempted to get too creative when programming, thinking that some extension could be easily
added. So why not?
❏ You will spend time in the coding process doing design without capturing your decisions in tests
❏ Solution
❏ Write your tests for some code before you write the code
Executable Tests
❏ Context
❏ You are a member of an agile team. You must develop effective unit and acceptance tests
❏ Problem:
❏ Tests must be run often. Manual testing is expensive and tedious
❏ Forces:
❏
❏
❏
❏
Both the developers and the customers depend on tests
At every change or addition to the code base, the tests need to be re-run
Manual testing is tedious
You need to be able to test at different levels of granularity
Executable Tests
❏ Solution:
❏
❏
❏
❏
Capture test cases in a way in which they can be directly executed
Run tests at every code commit point
Require tools and frameworks for executable tests
Start to get your test framework in place prior to your first iteration
❏ Related Patterns:
❏
❏
Effective Coach can encourage the team so that tests are written
Social Tracker can track and plot the number of tests
Continuous Integration
❏ Context:
❏
You are a developer on an agile team. You have just finished the development
of a story or task and all the unit tests passed.
❏ Problem:
❏
Not integrating the task to the build
❏
Failure to integrate parts at the end
Integration takes time
Small bits are easier to integrate
❏ Forces:
❏
❏
Continuous Integration
❏ Solution:
❏
❏
❏
❏
❏
Integrate every task into the build when all its unit tests pass
Since tasks are small, integration is more likely to be successful
An integration machine on which all integration tasks are carried out
Require two repositories for code
Warn tracker incase of delays
Continuous Integration
❏ The integration process has four parts:
1.
2.
3.
4.
Run all the tests
Integrate the entire code base back into the local version
Run all the unit tests for the system
Commit code
Social Tracker
❏ Context:
❏ You are the tracker on an agile team
❏ Problem:
❏ The tracker needs knowledge of the state of the project, but the knowledge is
in individual heads
❏ Forces:
❏
❏
❏
If the tracker doesn’t talk to everyone frequently
The tracker has other development tasks as well
Integrates the information held by the developers
Social Tracker
❏ Solution:
❏
❏
❏
❏
The tracker spends five minutes or so with everyone
Reports the progress at the Stand Up Meeting
Good practice to rotate the tracker with every iteration
The tracker can be the one to interact with the customer
Project Diary (Record of Velocity)
❏ Context
❏ You are a developer on an agile team building code to implement stories and tasks.
❏ Problem
❏ Individual velocity figures must be known and accurate.
❏ Forces
❏ The only way to estimate well is to do it and to record a history of your estimates and the
resulting actual times.
❏ Agile development can’t function if the estimates are inconsistent
❏ A person can learn a lot about how they estimate: optimistic, pessimistic or accurate
Project Diary (Record of Velocity)
❏ Solution
❏ Developer keeps a bound book for the project in which estimates and resulting actual
times are recorded for each task.
❏ Consequences
❏ Record book will help you become a better estimator
❏ You won’t improve your estimates unless you record them so that you can look back over
Customer Checks Off Tasks
❏ Context
❏ You are customer on an agile development team
❏ Developers have come to you with a “completed task” for your approval
❏ Problem
❏ Tasks must be checked off only when done
❏ Forces
❏ If the developer checks of the task when she thinks she is done, there is room for disagreement
❏ Integration problems
❏ Developers may drift toward assuming what you want
❏ A task isn’t done until the customer is satisfied
❏ Done doesn’t mean coded.
Customer Checks Off Tasks
❏ Solution
❏ When the customer is satisfied, the customer checks off the task as done.
❏ Consequences
❏ If the customer disagrees when the task is done
❏ Customer might write new stories to correct it
❏ Customer can also reject the task
❏ If tasks are not accepted make sure to seek the root cause in your Retrospective
Customer Obtains Consensus
❏ Context
❏ You are the customer on an agile development team
❏ Your project has lots of stakeholders and you have to be the main guide of the project
team
❏ Problem
❏ In many projects the customer is a complex beast
Customer Obtains Consensus
❏ Forces
❏ The customer must speak as one for all of these individuals and groups
❏ Customer must be empowered by the organization to make all of the business decisions
that relate to the project
❏ Progress will stall if the developers can’t get questions answered quickly
❏ Solution
❏ You must continuously obtain consensus, or at least consent, among all of these
stakeholder groups on priorities and business value
Customer Obtains Consensus
❏ Consequences
❏ There is only one mind setting the direction else it will result in incoherent code.
❏ The customer with many stakeholders needs good lines of communication to keep the
momentum
❏ Since iterations are short, the questions are to be answered quickly and accurately
❏ Do something as long as it makes progress than being idle when people argue
Conclusion
❏ Supports early and regular releases
❏ Regular inspection of working product as it develops
❏ Visibility through active user involvement
❏ Identify any issues early