Break the monster to pieces-Iterative planning & deliverable-
Sometimes you’re involve in a project which is everything but easy to implement.
U r not surprised when you’ve heard that the project move from hand to hand between department managers in the place u work.
Now u got a critical mission - to be the technical authority of the project from its beginning to its end. U need to set the technical design in a way it will work as required. The problem is that after u get the functional & non-functional requirements u realize this is not going to be a piece of cake.
At first glance u ask your self - why me. U look around and any other programmer that work on a different project look happy while smoothly typing code with a relax smile & confidence.
Now what r u going to do?
You learned to think positive,
To see difficulties as challenges,
To see difficulties as opportunities, to stay in control no matter what and to use slogans when u feel stress, like I just did.
Anyway-u decided to go for it and to give what u can to make it a success. You convince yourself to believe in it – and this is a good start. But believing its not enough – u will need more then that.
U soon discover that as the times goes and during the inception & elaboration phase u get a better understand of the requirements.
U also set a clear list of project risks and another list of how to mitigate the risks.
U identifies the risks you want to mitigate during the elaboration phase. You do it by giving each risk a score for its importance for the end users and customers and for the next project iterations.
As soon as u confront and mitigate these risks your life and the life of the development team that will join the efforts in construction phase will be better.
Working in iteration is highly important.
Each iteration compound from: plan, design, code, unit test but only within the scope of the iteration. It sure makes the work on a very complex problem a little bit easier – to understand and to take real actions.
It can contribute to your confident that things are feasible from real experience and not just mounting of design documents in earlier steps (u still need the documents to plan the iterations). You get in a short time, positive incentive after another iteration completed as expected and planned. You stay in focus – and don’t try to work on modules that should be done in construction phase. This is true for your managers as well. They can see review each of the completed iteration and get the right decision accordingly. They can be sure the project is going on the right track and if it does not they can take immediate actions before getting into more investments.
Customers and the end users will enjoy this approach as well. They can start using iteration releases earlier and gives their feedbacks.
I already mentioned it but this worth repeating - Iteration can also simplified the TDD
Thus, Iterations can be attached to one or more unit test.
This is only a glimpse of iteration approach that can assist u when dealing with project that on the beginning u r not sure why u disserve it. Projects that are seems complex and have too many required modules that u r not certain about their feasibility. I know it help me.
This approach is of course, recommended to any other project as well.
The original resource for this approach is a book I’m reading right now, which I guess familiar to part of u and that called:
The Unified Software Development Process by Ivar Jacobson, Grady Booch, James Rumbaugh.
The book is fantastic and I soon find it helpful, even though I did not reach to its end yet. In any case the post came to expose u to part of the important ideas u can find in the book in more details.