For many programmers it comes as a surprise that deployment of a software system can be hard, and a job often well worth defining a project for. Rarely, you can release and sit back. Getting a system going is one of the hardest parts in terms of controlling. Issues like continuity of work, training of people, pre-testing hardware compliance, documentation, time tables, temporary re-wiring, plans for the subsequent maintenance phase - and many more issues have to be taken into account.
What is different in Agile environments, is that problems with the introduction of the system can often be preempted by changing the software itself. Foreseeing deployment issues can even have its impact on the basic specs of the product. For example, knowing that the users must be able to use the system continuously and together with the old solutions may result in totally different designs than simple, new, fresh applications in new areas.
Planning the deployment looks surprisingly like design activity. You have to keep a thorough eye on the sequence of things, and be aware of things that can happen concurrently, and others that cannot. This makes it a candidate for tools that we already know in our normal Agile work.
We currently have a couple of projects that have a heavy deployment 'load'. Nageswara sent me an e-mail yeasterday, with his deployment plan for our new bug database access tool. It was rather short, just a couple of bullets. That couldn't be right. So I suggested that he would probably be helped a lot by simply putting the plan orderly into a wiki. This makes things more reviewable:
- Forces thinking about many aspects
- Enables concrete discussion with everyone involved
- Can act as a simple script
Geen opmerkingen:
Een reactie posten