|
Whipped Cream on Top of the Sundae Service and a good variety of features are key in developing relationships with the customer. We always want to satisfy our customers. But if we sometimes exceed their expectations, overly satisfied customers will more than likely spread the news about our service or product--we've added whipped cream, and maybe even a cherry, on top of their ice cream. In this week's column, Mike Cohn explains how he measures customer satisfaction using Kano analysis, which categorizes the features customers look for into baseline, linear, and exciter features. Doing so will help us identify which features will delight our end users, and help us surpass the level of simple satisfaction.
|
|
|
Free Time is Not Free Unpaid overtime has negative personal and business consequences. Although regarded as free time by many organizations, there is a true business cost to not estimating or counting overtime hours, whether paid or not. Ed Weller presents the argument that those who do not count free time in their planning and tracking will make poor decisions and often invest in the wrong projects.
|
|
|
Ping-Pong Programming: Enhance Your TDD and Pair Programming Practices Team player Dave Hoover wants to share a software development practice he enjoys. It emerged from the practices of extreme programming as a competitive yet simultaneously collaborative practice. Dave has found that this practice promotes the flow of knowledge between software developers better than any other practice he has experienced. As you might have guessed from the title of this week's column, this practice is called ping-pong programming, or P3 for short.
|
|
|
Cook until Done There's no shortage of advice on how you should model, design, test, build, and deploy your software project. Every author, trainer, and pundit will swear up and down that "they know the secret." They know how to build great software—they've done it before and all you have to do is follow their lead. Buy their software, read their books, buy their tools, attend their seminars, and do it just like they do it and you'll be a success, right? But somehow it doesn't seem to be that easy. In this column, the first in a series of articles that will explore the different avenues of software development, Andy Hunt and Dave Thomas, the Pragmatic Programmers, begin the journey by revealing that learning software development isn't as easy as the pros make it out to seem. Find out why these books and seminars work for them, but not always for the rest of us.
|
|
|
The Goldilocks Parable: How Much Process Is Just Right Getting process improvement "just right" is difficult. Go too far in the definition of processes, and it really does get too hot, with the heat coming from the people trying to use the processes. On the other hand process definitions that are too short to contain anything of value will leave users in the cold, and then there will be no improvement in the organization. Ed Weller states that a useful process improvement activity develops a set of process artifacts that meets the needs of the user. This helps the organization capture "tribal lore" and cast it into a set of process definitions that eliminates waste and improves time-to-market.
|
|
|
Suffering for Success One of the most valuable services a QA group provides is preventing failure. Ironically if the group succeeds at this, QA might find themselves unpopular or out of a job. Linda Hayes reveals how typical methods of measuring success can actually cause failure. Especially if success is achieved at the loser's expense.
|
|
|
Test-Driven Development Isn't Testing There's a common misconception that test-driven development is a testing technique when in fact it's a design technique. In this column, Jeff Patton explains this and how you might use your unit tests to explicitly guide and describe the design of your software.
|
|
|
Not Your Father's Test Automation If you think that test automation is mostly about executing tests, then you're missing out on a big opportunity. Or rather, you're missing a lot of small opportunities adding up to a big one. Consider this: stop thinking about test automation as merely executing automated tests, stop thinking about test automation as something you need expensive tools for, and start discovering automation you can implement in a couple of days and usually with extremely inexpensive tools or tools you already have available. In this week's column, Danny Faught and James Bach suggest taking a more Agile approach to test automation.
|
|
|
Learning Speed from Quality Programming As software professionals we spend far too much time fixated on speed and asking questions about how long a task is likely to take. In this week's column, Mike Cohn says we need to focus more on quality than speed. When something is done well, it's only a matter of time until it is done quickly.
|
|
|
Being Resourceful When Your Hands Are Tied You work hard to find tools that can help you. You learn how to use and configure them. Then you find yourself working in an environment where you can't even use them. Have you encountered this frustrating situation? Danny and Alan have encountered this frustration many times before, and in this week's column, they're here to say you don't have to abandon all hope. If you're creative, you can still find tools to use–even in the most inhospitable environments.
|
|