News on Monday
more>>
SharePoint Tech Report
more>>


   

 
 
Download Current Issue
ISSUE 3/15/2010 PDF

Need Back Issues?
DOWNLOAD HERE

Receive the print Edition?


 
blogs tab
Google Code turns 5
Google Code Turns 5, and adds a Paxos Algorithm to make the system more stable and reliable.
03/17/2010 11:16 AM EST

Test your Visual Studio 2010 know-how
Microsoft is offering free beta certification exams for Visual Studio 2010.
03/17/2010 11:08 AM EST

Microsoft lifts the hood on IE9
Microsoft is previewing IE9.
03/16/2010 01:10 PM EST

 

Events calendar tab
3/22/2010 to 3/25/2010
Santa Clara, Calif.
The Eclipse Foundation

4/12/2010 to 4/14/2010
Las Vegas
Penton Media

4/12/2010 to 4/15/2010
Santa Clara, Calif.
O'Reilly Media

4/19/2010
New York City
Flagg Management

4/25/2010 to 4/28/2010
Overland Park, Kans.
IIUG


 
Most Read Latest News Blog Resources

Agile Thinking, Everywhere




January 1, 2008 — 
Agile practices have influenced how non-agile teams carry out software development tasks. Here’s a look at how agile thinking has influenced each step:

Write software in short stints, followed by customer feedback. This is the central concept of agile development. The team focuses on delivering a narrowly defined feature of the software, in a predefined time period, often two weeks. Virtually all development teams have been heavily influenced by this idea, said Brian Carter, a vice president for the consultancy Sapient. “Even clients that aren’t aware of agile are asking for some demonstration of progress on a short-term basis.” That’s a far cry from earlier days, when developers routinely got away with saying, “I’ll show the clients [what I’m working on] when I decide to show them,” said Greg Reiser, a vice president for the consultancy ThoughtWorks. Short iterations are intended to surface problems early in the project, allowing developers to receive and respond to customer feedback. “If you aren’t closely working with the client, you don’t know if you are doing the right thing,” said Wendy Friedlander, a software developer for the cable network Oxygen Media. Of course, no team makes an overnight leap from no communication for nine months, to two-week iterations, followed by detailed feedback. But there are clear signs developers everywhere have been influenced by the iterative approach, said Michael Vax, CEO for Luxoft Canada, a consultancy. “We see a lot of people move from nine-month release cycles to three months.”

Define application requirements incrementally. Agile development recognizes that not every requirement can be known at the project’s outset, said Bob Schatz, head of consultancy Agile Infusion. “It focuses on capturing the highest-priority features of an application first, instead of gathering all of them up front.” This is a significant change in thinking for developers, who have traditionally viewed changing or new requirements as a disruption to the process. Because the transition to the gather-requirements-as-you-go approach is difficult, teams typically take small steps first, said Tom Stiehm, managing architect for consultancy Command Information. They develop a big vision up front, and write a lot of requirements related to that vision. But they don’t flesh out the details of the requirements until they are about to fulfill them. “That isn’t agile development, but it is agile thinking.”

Test-driven development. Traditional testing approaches focus on finding defects after the fact, once code has been written. The agile practice known as test-driven development turns that on its head, mandating that developers design tests before they write the actual code. Non-agile teams aren’t likely to do that. But they have nonetheless been heavily influenced by the practice. It’s commonplace to conduct unit tests as code is being written, said Stiehm. One indicator that unit testing has gained widespread acceptance? “When we hire a Java programmer today, we expect experience in JUnit,” he said, referring to a popular open source tool for unit testing. “That wasn’t the case a few years ago.”

Continuous integration. Not everyone adopts this agile practice, in which a new build is launched each time a developer checks in code changes. But daily builds have become commonplace, even among teams that aren’t doing agile, said Ross Pettit, client principal for ThoughtWorks. “Builds are no longer deferred.” The daily build has become a mainstream practice not because it is agile, but because it’s common sense, added Stiehm. “It’s important to know on a daily basis whether your code is functional.”


Share this link: http://www.sdtimes.com/link/31485
 

Add comment


Name*
Email*  
Country     


  • Comment
  • Preview
Loading