One of the most difficult problems in software development is knowing how to elicit and discuss requirements. It’s difficult because the people who are supposed to know the requirements don’t always have a clear idea of what they want. And, even people with tremendous communication and other soft skills don’t always have good ways […]
I had a lovely dinner with Brian Marick and our spouses Saturday night. (Now that he’s blogrolled me, I can’t tease him about that. Thanks, Brian!) Two things made me reconsider the way I manage people while managing a project: things we discussed at dinner, and Brian’s recent posting about the explicit role of the
As you can probably tell, I think people are the most important equation in successful product development. Good people can trump inadequate management and/or an inappropriate process. Dorset House has announced the pre-publication price for my book (available in September). I wrote a little more about this on my Hiring Technical People blog.
I’m a fan of nightly builds with automated smoke tests, run overnight. In the morning when everyone returns to work, anyone who’s broken the build fixes it. In most cases, the developers see what they did and they fix it. The agile folks take this even further and say to build the system whenever
I think of development and test as partners. The developers create product and defects. The testers detect product and defects. They both need to understand what the product is supposed to be and how it’s supposed to work (the requirements). The more the developers explain the architecture and design, the better the testers can
Via Steve Norrie’s weblog, I found Kovitz’s “Hidden Skills that Support Phased and Agile Requirements Engineering”. In phased development, projects promise large feature sets to a customer for future delivery. In agile projects, the requirements are refined over numerous little conversations with the customer, day in, day out. Kovitz claims the skills required for agile
Bloglet subscribers saw two posts from me Friday. They saw the post I published *and* the post I saved as a draft. Surprised me. Since I know about this feature, I’ll work around it, and compose future drafts somewhere else. This isn’t a big-deal problem for me. But it was a surprise, and a
Earlier this week, I was at SPC teaching about project requirements and project management. If you haven’t thought about lifecycles, consider the differences between these kinds of lifecycles: Linear: Waterfall and waterfall with feedback Iterative: Spiral, where the whole product is up for grabs each time Incremental: Where you add to the product in pieces
Fred Brooks, in his classic, “The Mythical Man-Month,” talks about a chief programmer team (chief programmer, and programmers of lesser hierarchy until you get to the peon). The chief programmer team works when one person can keep all the details about the product in their head. If you use several hierarchical teams of chief
How much time should your project spend on development vs. time on quality? I’ve received a bunch of email over the past year asking me how much time a project should allocate to development and how much to quality. To me, that’s a funny question, because I think of quality as integrated with development. So,