thoughts on an agile-waterfall mixed process
I don't often talk about the business behind software engineering but recently I have had to talk process a lot more with other stakeholders in projects and below is a summary of what I have started to formalize as a agile-waterfall combination process. Though I agree that a fully agile software devleopment process like scrum, XP etc is probably better and more efficient, it is a hard sell for some clients who are so used to the traditional waterfall process. It is also hard to tell some execs in a client services company to let go of their need to have client "sign-off" on everything. Anyways here is a first stab:
requirements gathering / exploration
requirements document
client priority analysis
functional specifications
effort analysis of line items in functional spec
prototype risky functionality
mood boards for design
content and functionality document (with summarized effort based on knowledge from effort analysis of functional spec and client priority analysis)
(at this point we should know what the client wants for the initial launch of the product based on effort and priority. Things that are too costly and low priority should be put off until post launch)
wireframes
user testing of wireframes (not required)
annotated wireframes with func spec / inform wireframes from func spec and vice versa
design round based on wireframes
user testing of design (not required)
scaffold functionality based on wireframes (this task might be broken into a dozen or more scrum sprints depending on the size of the project)
content entry
user testing of scaffolding (not required)
design round
further user testing of design (not required)
sign off of design
build out full functionality to work with design (again this task might be broken into a dozen or more scrum sprints depending on the size of the project)
content entry
QA
Bug fixes
product launch
post launch feature requirements review and exploration (begin process over again)
0 Comments:
Post a Comment
<< Home