A look back at the best from this week in the past.
Describing the software development process
Software development involves determining what to develop, documenting this decision, determining how to develop it, and actually developing it.
- How do we separate these very different processes so that we can talk about them?
- How do we staff a team to accomplish them?
We present a framework for describing this process in terms of layers of activity. Many people use pyramid analogies, which show the magnitude of effort in each layer (lines of code versus lines of requirements, for example). Many other people use inverted pyramids to reflect the importance (or impact) of work done at different layers (a sentence defining a strategy has more impact than a line of code). Some people show PERT diagrams of waterfalls or pretty circular arrows charts showing iterative life-cycles, or any of many good analogies.
Joy posted a really good article last week at Seilevel’s requirements defined blog, Measuring product manager performance on internal system products. Her post is a followup to an extensive and heated debate that happened last fall on the Austin PMM forum. It’s a great forum to subscribe to – a lot of experienced people with strong opinions and steamer trunks full of anecdotal data – and they don’t all agree. You get to see the coin from all three sides* with this group – it’s awesome.
Effective listening skills yield great requirements
The better you are at listening, the more people will want to tell you.
If you’ve ever watched The Actor’s Studio, you’ve heard over and over that the most important skill in acting is reflective listening. A marriage counselor will tell you that step one in solving your problems is to listen. Consulting 101 will reiterate the importance of active listening. Presentation trainers stress good listening skills. Dale Carnegie – listening yet again. Sonar technician. There’s a pattern.