Agile Development - Unified Process

The Unified process is yet another method of Agile Development.  One of the key strengths of this process is that it encourages its users to tweak and change it so that it meets their needs.  Activities and artifacts in this process are considered optional and can be done or not as the team decides.  Even the order in which steps are done are up to the project team.   As a result there are a number of different variatons on this including the Agile Unified Process, the Rational Unified Process, the Enterprise Unified Process, and I could go on.  At its most simple and basic the Unified Process (UP) has a number of key practices

1. Develop in short timeboxed iterations.
   • This is a common theme in all Agile processes.  Deliver quality software in short, frequent cycles.  Gather feedback, iterate, and improve upon it.
2. Develop the high-risk/value elements early (for example get the core architecture in place).
   • This is something that isn't called out explicitly in other Agile processes, and I think it is an important distinction.  In other Agile processes such as XP, you only build what you need at that given time.  That means you have to constantly refactor your core architecture as you go along.  In the Unified Process its a bit different.  You try to get what you think are the core infrastructure pieces early on.  Those infrastructure pieces are the biggest risk item, and so get them working and tested/iterated upon as much early as possible.  One important note.  Do not interpret this as saying that the core infrastructure is done early.  Its not done, just like with XP it is expected to change and be refactored over time as new information and understanding is gathered with each iteration.  What it does mean is that you build a more complete infrastructure up front than with XP so that you have more of a building block for all the features you want in that particular release.
3. Be willing and able to acccomodate change.
   • Again, just because you do something early in the Unified Process does't mean you can't go back and change it later.  You will change stuff, alot, get used to the idea.
4. Understand the problem domain being addressed by the project.
   • This one is pretty obvious. If you don't understndthe problem domain can you really solve for it in software?  Have complete understanding from the customer's perspective, and you have a much better chance of success.
5. Deliver working code by converting that problem domain understanding into a quailty software product.
6. Implement configuration management over all project artifacts.
7. Trust your staff.  
   • Like most Agile methodologies micro-managers need not apply.

So how does this work in practice?  Well there are generally three four different phaess to this process.

1. Inception
   • This phase is where the team defines the Vision for the project.  Essenailly summarizing the key stakeholders, and what they need the software to do.
   • The Vision is broken down into a set of use cases that describe the intended functions and environment.  It is important to note that the focus of these use cases is "what" should happen, not "how" it should happen.
   • One very important thing to call out is that not all requirements have to be known at the end of this phase.  Actually the rule of thumb is to have only 10% of the significant requirements fully fleshed out. 
2. Elaboration
   • This defines an overall design for the system from a hardware and softwware perspective.  By doing this the team can identify the overall components required in the core infrastructure and also call out risks in the architecture so that can be addressed early in the process.
   • Coding is begine on those core peices to get the key peices in place.  This sets up the team to be able to focus on getting the use cases properly executed during later iteration cycles rather than getting the infrastructure in place.
   • In this phase it is expected that 80% of the major requirements will be defined and evolved in detail. They are evolved over multiple iteration cycles in this phase.  How are they evolved? With customer feedback ideally.
3. Construction
   • Over mutliple iteration cycles implement the key use cases, and gather feedback on them.
   • It is important to mention that use cases can and do change in this phase as feedback is gathered about what is/isn't working for customers.
   • Handle the change requests with each iteration and evolve the product.
   • The project team can actually supplant this part with pieces of other Agile Development processes.  For example the execution of the actual project iterations could be done using Scrum practices within this framework.
4. Transition
   • Verify that the system meets the vision defined for the project, that the use cases are implemented successfully
   • Deploy the product.