This chapter is from the book
This chapter is from the book
This chapter is from the book
Build the Development Team
An often-overlooked advantage to building a prototype is that it lets you test and build the development team in a mini-project. As you build the prototype, you can identify the fastest developers, those who need the most supervision, and those who are natural leaders. Before you begin the final development effort, you can redefine peoples' responsibilities to best fit their abilities.
Tale from the Trenches
In one project I worked on, a developer built a truly elegant design for one of the application's subsystems. It may have been worthy of an article in some development magazine, but it was too complicated for the programmer assigned to implement it. To make matters worse, that programmer thought he would get into trouble if he asked for help. In progress meetings, he always said he was doing fine even though he was falling hopelessly behind schedule.
We did not build a prototype for that project. If we had, we probably would have noticed the problem in that subsystem right away. We could have simplified the design or reassigned a more experienced developer to cover that part of the project. As it was, that part of the application dragged on and became the time-limiting task for the whole project.
One common approach to staffing during a prototype is to begin with a small number of senior developers who work closely with the customer to define the application. They design the application architecture and define the project's major tasks. These will become the project's main subsystems.
At that point, each developer is assigned to one major task. More senior developers may be added if the initial design team was too small to assign a developer to each major task. These developers will later become the team leaders for their subsystems. The developers each work on the design for their own subsystems, with the project leader coordinating the project to minimize the relationships between the subsystems and to ensure that all the pieces fit together.
When the design is complete, the developers build prototypes of their subsystems and assemble them into the application prototype. Now is the time to reassign any developers who cannot handle their subsystems. Some subsystems may turn out to be more complex than expected. You may need to reassign them to more experienced developers or break them into smaller pieces.
The prototype lets you match developers with tasks that take full advantage of their abilities. It also lets the developers grow professionally. Over time, basic programmers can become team leaders. Team leaders learn to handle more complex subsystems and can become application architects and project leaders. The prototype lets the developers prove their skills in a situation where mistakes are correctable.
After the prototype is finished, the team studies the prototype and makes any needed adjustments. Using the information described in this chapter, the team may refine the design, pick replacements for tools that didn't work, adjust the development schedule, reduce the application's functionality, and so on.
By now the team leaders should be intimately familiar with the system as a whole and their subsystems in particular. They have built prototypes of their pieces of the system, and they should have a good idea of how development should proceed. At this point, the project staffs up for final development. Less experienced developers are assigned to the subsystem teams. With the guidance of the team leaders, they work efficiently and harmoniously to build perfect subsystems that assemble into a perfect application—at least, in theory. There is still plenty of room for mistakes, tools that don't work, change requests from the customer, staffing and budget cuts, changes to deadlines, and other surprises. At least you've set yourself up for the best development experience that you can, given the information you had at the time.