Software product success.
Yesterday we wrote about focusing our documentation on what our users are trying to accomplish. With a structured requirements approach, or with an interaction-design driven approach, we’ve already solved half the problem – determining what to document.
Why do we write documentation? Because someone told us to write it? Because our competitors have it? Or because we want our software to be easier to use? It should be the third one, but often, writing documentation is an afterthought, and it is deprioritized, and we just get it done, instead of thinking about the goals for doing it in the first place and doing it right.
Why run a test more than once? If it passed the first time, we don’t need to run it again – or do we? James Bach provides ten good reasons to run the same test more than once.
Burndown is a technique used in Scrum projects for tracking the progress within or across sprints. It is an exciting way to track how a team is progressing against a deadline – and we can apply it to any form of project-status. In this article, we will apply it to […]
Stephen Turbek, at Boxes and Arrows, tells us how to get better results from our wireframes. Wireframe prototyping can provide feedback early in the design cycle, reducing costs and improving the quality of the final software. By putting a little flesh on the bone, we can get even better results.
James Kovacs shares a great insight on software testing and the software testing process. His epiphany about test driven development makes it obvious to all of us why this technique is so powerful.
Mishkin Berteig at Agile Advice writes an excellent essay on the seven core practices of being agile. Understanding these elements is the first step in getting past the hype and fud of the agility dilemna. Promoters of particular agile practices, as well as detractors use hyperbole and extreme examples to make their points. While very effective techniques for arguing, inspiring and motivating, hype and fud detract from learning, teaching and understanding.
This is my requirements document. There are many like it, but this one is mine. My requirements document is my life. [Kubrick, with some editing]. Michael provides a comparison of requirements documentation formats seen in the wild. A good companion to our earlier piece, Michael provides some “what to expect” guidance about how different companies use the different documentation formats. Check it out.
Agile processes stress communication and colocation. Splitting a team into on and offshore resources inhibits the first and prevents the second. Teams struggle to resolve this apparent conflict of interest. Applying best practices (for any team) to address these challenges makes it possible. Martin Fowler provides us with great guidance based on years of experience with his company.