|
Escape from Documentation Common practice says that software projects need documentation. But there's still something of a gap between the preaching and the practice. In small companies especially, managers may claim there isn't time to document, or that "Our project is different." Maybe some of these managers know something the rest of us don't know. Are there factors that might make a project exempt from documentation? I've thought of a few possibilities.
|
|
|
The Innovative Tester Historically, the development team considers themselves the creators of the system and the QA community is considered as a necessary evil, more so when there is an independent testing group. Since test engineers sometimes work in a hostile atmosphere, they need to equip themselves with more knowledge in both functional and testing skills. This article discusses the importance of developing those skills.
|
|
|
Assuming the Worst about Requirements Requirements are under suspicion. Read between the lines of software and project management journalism and you'll hear nearly everyone lamenting the sad state of requirements. Managers plan only eight percent of project time for requirements. Developers worry about Zen-like requirements that lack sufficient detail to produce serviceable code. Testers think they have to backfill requirements. So, what were the analysts doing?
|
|
|
Taking the Mystery out of Requirements Ambiguity, false assumptions, theories, and red herrings. These basic elements of a good mystery story are also encountered in software requirements gathering. And just as the detective has his bag of tricks for solving the mystery, you can learn a few things about uncovering elusive requirements in this column from Becky Winant.
|
|
|
You Can't Fight Change We can probably agree that, for the most part, change is good. But it is also disruptive, and can even create chaos. In this column, Becky Winant explains a familiar model of the change process, and offers some ways to acknowledge and cope with change in the workplace.
|
|
|
Modeling Practice and Requirements Models are useful in different settings in different ways. Models can test facts, ideas and understanding, simulate operation, and aid coordination between systems and people. In this column, Becky Winant lists six model patterns she has seen in practice in software development organizations, talking about where each is appropriate, and the strengths and weaknesses of each.
|
|
|
Requirements Workshop Quick Debrief (template) This template is used for guiding a debrief (retrospective) of a requirements workshop. The facilitator can replicate this template on a poster or wall and guide the discussion to "fill up" each slot in the template.
|
|