I often fail to correctly estimate my deadlines during the programming, which leads to poorly organized workflow.
Therefore, today I have developed an algorithm of my development process I'm going to use.
It is influenced heavily by the Agile methodology, but since I’m not working in a team, its impossible for me to apply it. Nor do I have any time or desire to learn precisely about Agile, so I have just borrowed their philosophy.
If you have time, I would appreciate any feedback on possible drawbacks and improvements to it, since I don't want to screw up badly due to stupid planning mistakes
The main aims of the process:
Quick result delivery. Every week (or so) I must have something to show to the client.Learning-orientation. I should take into account that I’ll need to learn lots of things during the practice by itself.Efficiency and simplicity. Spend as few time and effort as possible (but not fewer!)
The process itself involves the development by iterations. One iteration is a week or so in length.
Before the project starts, I outline all the “strategic” aspects about it: its “global” design, possible directions we might need to scale at, possible changes that could be requested. I also learn everything needed to begin the project (say, the domain of the application).
Then, the actual iterations start. One iteration is as follows:
At the beginning of an iteration, a goal that needs to be done is established. The goal, upon achievement, should lead to a product that already works. Of course, its functionality is limited, but I’m still able to present it to the client.After the goal estimation, there’s the learning phase. I select the tools I’ll be using according to a certain criteria (they must be well documented, supported by the community etc) and learn the things about them that are necessary to start.
This phase is optional (I may already know everything I need) and its length is at most a half of the iteration.After the learning phase, there’s the doing phase. First, I plan the design of the piece of the functionality I want to develop, then I write the specifications for it (possibly in the form of tests in a BDD style). Then I develop the actual piece of software. Here, I take into account possible fails due to the usage of the new tools (that I've just learned). So if I'm using any new tool, I'll estimate the task to be 3x times as time-consuming. And If I'm not, I'll estimate it 2x as time-consuming.
During the iterations, optimization of the work is used heavily:
Everything that can be automated, must be automated.Especial attention to the testsAll more-or-less meaningful ideas should be written down - because this way they are more clearThe text from (3) should “work”: if it is a specification, it must be an executable test; if it is just an idea, you must show it to someone to evaluateNo multitaskingOther optimization ideas are constantly looked for and adopted on the way.
What do you think about such a process?
Thank you for your time