|
Agile SCM: It’s All Related In this article, the authors the use of basic patterns that can help build a software configuration management process that works well with your agile development environment. They discuss how codeline policy, private work spaces, smoke tests, private system builds, integration building, unit testing, and regression testing all work together to enable you to maintain an active development line.
|
|
|
Approaching the Implementation of CM When landing an airplane, the approach is considered quite important. If the approach vector is off even by 1%, the plane may careen off the other end of the runway. Also, if the approach is incorrect, effort such as fuel and time is unnecessarily expended and wasted, especially if circling must occur.
|
|
|
Write a Blockbuster Using User Scenarios Big projects require many little user stories. But if these scenarios don't add up to one good story, then you're probably missing out on the big picture. In this week's column, Jeff Patton describes how his team weaves many small tales into a single strong report by identifying key characters and themes.
|
|
|
Feature-Driven Development: An Agile Alternative to Extreme Programming Feature-driven development (FDD) has the more traditional progression of a systems-engineering life cycle mode as compared to agile methods. It uses distinct phases in its iterations while still being highly iterative and collaborative. FDD does conduct up-front planning, design and documentation and relies very heavily upon domain modeling.
|
|
|
Using Mocks to Verify Interactions In the March 2006 issue of Better Software magazine, Dan North began a discussion of the evolution of behavior-driven development from test-driven development. Here, North continues the conversation with closer look at "mocks," utility classes that, for testing purposes, pretend to be some component or service with which your object will interact.
|
|
|
Agile Processes: Making Metrics Simple IT organizations and, in particular, application development departments, are increasingly under pressure to provide performance and compliance metrics to justify annual spend. Unfortunately, many metrics campaigns collapse under their own weight.
|
|
|
An Agile Perspective on Branching and Merging This article focuses on branching and merging. We present some background for branching and merging, and consider some of the implications for agile development in particular. We also hope to reduce some of the suspicion that many agile developers have of branching. The article assumes some overall branching knowledge and yet revisits some particular details that often seem to confuse people. This is a fertile area which we will continue to expand on in future articles.
|
|
|
Automation or Not, It's All About the Data While anyone who has automated her testing knows you can't create repeatable automated tests from unstable data, it did not dawn on this week's columnist—self-proclaimed automation lobbyist Linda Hayes—that this issue cripples manual testing as well. Read on to share her epiphany.
|
|
|
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.
|
|
|
Preventing Late Tasks from Creating Late Projects We like to think that being late on one task isn't so bad because early and late completions will average out over the course of an entire project. If you flip a coin 1,000 times, it will land on heads about 500 times and on tails about 500 times. If your project has 1,000 tasks, about 500 will finish early and about 500 will finish late, right? Wrong--and many project plans are sunk by this common misperception.
|
|