Close collaboration is essential for any complex endeavors involving people, and software development with acceptance TDD is no exception. In practice, we want to have an integrated project team instead of separate development, business analysis, and testing teams, let alone a distant QA department.
The fundamental idea is that the way to achieve the best possible level of productivity for the whole team is to nurture rapid feedback and effective, face-to-face communication around concrete, working software instead of passing around test plans, requirements specifications, and bug reports between customers, testers, business analysts, and developers. With acceptance TDD, we are able to collaborate effectively by bringing together the knowledge, skills, and abilities required for doing a good job.
Let’s see how this close collaboration helps us deliver the right product by improving our interactions and reducing the likelihood of misunderstood requirements and costly rework.
Seeing concrete, working software Very few customers have been completely satisfied with what the contractor delivers to them after several months of silence. By feeding the customer with completed functionality as a continuous stream, we’re making sure that, if there’s something wrong or missing, we’ll know about it right away.
This early feedback reduces our risks and costs. Furthermore, by not keeping an inventory of supposedly “completed” items that the customer hasn’t seen yet, we’re avoiding the usual illusion of progress that is built on assumptions and that is supported by document-driven methods and meaningless statements such as “development is 90% complete.”
Building trust and confidence
Another significant benefit of delivering working software early and often is that we’re building trust and confidence both between the team and the customer and within the team itself. By showing the customer (and ourselves) that we can deliver, we’re making life a lot easier for our whole team.
Customer in control
There’s one key difference in the role and power of the customer between incremental development and the traditional waterfall, big design, up-front style of development. With incremental development, the customer gets to choose which features they get first. Similarly, they also get to choose which features are dropped if the team is not able to implement all of them within the project’s allocated time or budget.
The customer’s decisions are, of course, influenced by the cost of the features, which the developers estimate including the cost of delaying, the cost of building things in a different order, and so forth.
The ability of the customer to decide what their money is spent on can really change the way they look at software projects. Finally, the customer is in control of what their money is spent on. Talk about motivating the customer!
Evolving a shared language By encouraging close collaboration between testers, developers, and customers, we are effectively facilitating a situation where the information needed is obtained as quickly as possible—in all directions. Furthermore, this continuous exposure within the team is likely to increase the efficiency of communication as people get to know each other better and begin to evolve a shared language. Software development is a people business, after all, and we shouldn’t neglect that fact.
For any software development or other project initiative your company may be considering, it is critical to have in place and practice a set of effective and proven guidelines to ensure project success and delivery of the expected results: taking into consideration the role and responsibilities of a well-qualified project manager, knowledge of important business and financial aspects, and a step-by-step process that all contribute to the solid foundation and implementation of an effective project plan.
ReplyDelete