|
Construction is the actual development phase in MADM. Development happens in weekly iterations that are clubbed in releases. Additional user stories are written, everything is prototyped and test cases are written before the actual coding starts. Pair programming is followed to improve the quality of code and regular reviews keep the communication and feedback levels high.
Additional User Stories
The main user stories are written in the Inception phase. Before beginning on each release, any pending user stories are written up. The customer assigns business value to each user story and the developers assigns time frame for each. User stories can be added to the project at any time but should be accompanied by acceptance tests.
Prototype
Prototyping involves making an actual HTML mock up of the project. Prototype is like a live site but no actual programming or no database interaction. The prototype captures the flow, design, validations and all features of the user story. Hence it gives clear idea of how the user story will function when the programming is carried out to the customer.
Wireframes can serve as the basis of creating the prototype. We can keep adding prototypes to the wireframe as we move forward. This way the site will reach closer to the final stage with each iteration / release. This gives much more visibility of the project to the entire team and the customer.
Release Plan
Releases are two or three week long development cycles. Each release plans to complete significant portion of work in the project. Each week in the release cycle is an iteration. At the beginning of each release cycle, the customer and developers make a release plan. The release plan decides what stories will be implemented in each iteration. This selection is done via the "planning game"!
The customer assigns business value to each story. Stories without which the project can not be considered functional would get higher values. Stories which describe "nice to have" features will have low business values. Along with the customer, the developers will assign an implementation difficulty level / time frame to each story. Stories can be rated in absolute man hour terms. Some stories can also be technically very challenging or impossible.
The stories are now assigned to iterations based on the following principles:
- A fully working but sketchy system should be developed early
- Higher business value stories should be done earlier
- Worst Things First - technically difficult things should be done earlier
The duration of the iterations and releases will be fixed. If some stories are not fitting in this duration, the participants will work towards pushing the story in the next release and adding some other story that can fit, or breaking a particular story in appropriate parts.
Iterations
Iterations are at the heart of project execution in the MADM process. Each iteration is one week long. Developers implement the user stories selected during the release plan in this time. Each user story is divided into smaller engineering tasks. Each iteration also follows a set of guidelines for the execution. These steps are explained in the next few points.
Stand up meeting
Stand up meetings are daily team meetings to share the updates. Everyday at the beginning of the day, the team discusses the tasks completed on the previous day, any problems faced, any changes required in the plan etc. The nature of the meeting - a quick stand up meeting - assures that no time is wasted and work is done faster!
Unit Tests
MADM follows a test driven development style. Before beginning the implementation of a user story / task - unit tests are developed. This process ensures that the developers know what provisions to make in the code before they start coding. When you create your tests before the code, you will find it much easier and faster to create your code.
Requirements are nailed down firmly by tests. Unit Tests also provide immediate feedback while programming. It is often not clear when a developer has finished all the necessary functionality. Scope creep can occur as extensions and error conditions are considered. By creating Unit Tests first, we avoid such situations. We can easily identify the completion of the tasks - it is complete when all the unit tests run.
Writing test cases for each condition may not be feasible, but Unit Tests cover as much functionality as possible, at least the important parts.
Pair Programming
Pair Programming is an agile / extreme programming principle that advocates putting two people together on a programming task. The pair works on the same computer - one person typing out the code and the other guiding. Both the programmers discuss the implementation of the problem and contribute ideas. This improves the quality of code. The number of defects are reduced and silly errors are avoided. Research shows that when pair programming is followed, the overall increase in time spent is about 10%, but the pair enjoys the task much more and the quality is 19% better.
MADM allows solo programming for routine development tasks, yet every code must pass through two sets of eyes.
Refactoring
Refactoring is continuous improvement of code. The coding process puts a strict restriction on implementing only the functionality that is needed for the moment. Not to overdo things just because it may be required in future! This also means that as the new things are added to code, it may need some cleanup. This cleanup is not done at the end of the project, but as a continuous process - Refactoring. The pair working on the problem keep cleaning the code, refactoring functionality to make it simpler and easier to understand and converting common functionality into modules. Continuous refactoring keeps the code simple. Strict testing norms also ensure that refactoring does not break the existing code.
Continuous Integration
Integration is another frequent process in MADM. Multiple people working on separate parts of the project integrate their code into the mainstream codebase everyday or even more frequently. This allows discovery of integration problems earlier and does not lead to integration hell! This also means that the project keeps improving daily, it keeps getting closer to the desired release product. Continuous Integration also allows review of the progress, quality and risks in the project on a frequent basis.
Iteration review
At the end of each iteration, the team reviews the progress of the iteration. The review also calculates project velocity - the speed at which the project is progressing. Project velocity amount serves as a guide in the future release plans. Risks are reviewed at this stage and solution approaches are discussed.
Quality Assurance
Quality Assurance is an important part of the software project management. QA is an ongoing process in the MADM because the process follows test driven development. The development team itself carries out a lot of quality control. The QA team performs load, regression and security test on each release. The customer carries out Acceptance Tests to certify the completion of stories. Magnet has a strong Quality Assurance team and all projects have to pass through QA before the release.
Payment
Payments for the project are tied to releases in MADM. A milestone payment is due at the end of each release. Magnet provides multiple and easy ways of making the payment, including a credit card based online payment system from our website.
|
