Ever heard this sort of thing?
Consultant: What is that you want us to do for you?
Client: Well, what sorts of thing can you do?
Consultant: (after enumerating an impressive list of stuff, none of which sounds like it would be anything anyone would want ) It depends on what you want to do?
Client:...
Everybody else (sighing): We could be here some time.
So instead, we find creating two documents is sufficient for the success of a project: 1. A future press release 1. A development document or demo first
Should be authored with a customer wholly in mind and should be no more than three pages, they can take time to write - ideally by no more than three people. A future press release is an imaginative piece of writing, enabling you to explore the necessary conditions for the success of the proposed work. You write the press release as if the project or product were already a success. Discuss how the customer experience improved, why the customer cared? and subsequently discuss other reasons why it mattered to wider stakeholders. Set an ambitious and clear goal with measurable results which may include financial, operating, market share etc Outline the principles used that led to success; this is the trickiest, part of the process. Discuss the issues addressed, particular decisions and the design principles that led to the positive results. So even if you fail - you succeed, in going no further with a project that couldn't succeed.
Is a collaborative document and managed best within a wiki, and isn't the same as traditional document first development but like they describe here GitHub, so I've added a few additions.
The philosophy behind Documentation-Driven Development is simple: from the perspective of a user, undocumented features don't exist, and incorrect documentation is the same as a broken feature. Document the feature first. Figure out how you're going to describe the feature to users; This is where a demo can come into its own; it's just the most efficient way to get the user to see what they are going to get, with the demo done and approved - the write-up and screenshotting are straightforward. Whenever possible, documentation should be reviewed by users before any development begins. Once documentations completed development should commence, and test-driven development is preferred. Unit tests run as described by the documentation. If the functionality ever comes out of alignment with the documentation, tests should fail. When a feature requires modification, it should be modified documentation-first. When documentation is modified, so should be the tests. Documentation and software should both be versioned, and versions should match, so someone working with old versions of the software should be able to find the proper documentation. So, the preferred order of operations for new features: 1. Do demo and record 1. Get feedback on documentation. 1. Test-driven development (where tests align with documentation) 1. Deliver feature 1. Publish documentation 1. Increment versions
Our Interests and values