Archives for posts with tag: waterfall

Is your software development a linear conveyor belt of bottlenecks?

This post describes my experience mixing Agile + User Experience design while building out the mobile site for thoora.com.  While this process worked for us, it won’t work for everyone/every project, however it allowed us to minimize blocked tickets and maximize the time of our small development team.  Breaking the work into manageable stories, and parallelizing the work early and often is a great technique to maximize output and manage the traditionally serial and inherently blocking jobs and responsibilities when mixing UX and Agile methodologies.

Read the rest of this entry »

Advertisements

Why are things always so obvious after disaster happens, I think they call that hindsight

One of the final talks I attended at CUSEC 2010 in Montreal, was probably the most important, and unfortunately – (seemingly) the most underrated. Daniel Berry from University of Waterloo Software Engineering gave a talk entitled “Ambiguous Natural Language in Requirements Engineering”. Unfortunately he was speaking to an audience in the Agile area who have been exposed to culture stating that Waterfall Software Process is dead. More inaccurately, that requirements gathering is a dead science. This talk was not only enlightening, but also made me rethink many topics I haven’t thought about since University.

In summary for those who don’t want the verbose version: The process of transforming the ‘idea’ (as a requirement) and turning it into ‘code’ is a problem that extends well beyond just the ‘code’ part. Many software errors (%5-%10) are a result of ambiguous requirements – Requirements that neither party in the process even knew were ambiguous. This talk was a branch of Software Engineering shining at its best – and Berry offered solutions!

First to address those developers still pretending this problem doesn’t apply to them: Not all software projects involve 1-2 developers. Not all projects allow you (the developer) to talk directly to a client. Some projects will have you writing code based on requirements written by someone else in your company. This problem exists whether you want to believe it or not.

Read the rest of this entry »