• Login
• Become a member
• RSS
• Part of the TechTarget network

LAS VEGAS -- One aspect of creating quality software is delivering a product that meets users' needs and expectations. To do that, you must use an agile development methodology.

That's the

point both Venkat Subramaniam, founder of Agile Developer Inc., and Neal Ford, application architect at ThoughtWorks, stressed during their presentations at TheServerSide Java Symposium here last week. The reason for that, they said, is that those methodologies allow continuous communication with users during the entire development life cycle.

"Communication is emphasized in agile development," Subramaniam said. "Feedback is extremely important, so you need to put into practices that enhance communication."

How a user story differs from a use case "A user story has many fewer details than a use case. It is a one- to two-sentence interaction -- that's it. You don't need a lot of detail because it's going to change." -- Neal Ford, ThoughtWorks.

Both Subramaniam and Ford said software makers must get away from waterfall development. With waterfall development, a significant amount of time is spent gathering user requirements and creating a requirements document. Developers then have to make many decisions a day based on that document; they're not able to talk with the users who often change what they want as development continues.

"It's a pointless exercise to try to gather all these detailed requirements because they're going to change," Ford said.

People who gather user requirements should instead gather high-level user stories to create a release plan. For every story, provide the business value that developers can focus on when developing rather than doing blind construction, Ford said.

Once developers have the user stories, they can begin coding. They do not need to wait weeks for the requirements phase to be completed. "With agile development, you spend much less time on requirements, and developers spend more time coding. Developers are coding all the time," Ford said.

This gives developers smaller tasks to do in shorter amounts of time, enabling them to show users their work and get feedback. Then the developers can go back and refine their work, repeating the process several times until the users are satisfied.

"The highest priority is to satisfy the customer through early and continuous delivery of valuable software," Subramaniam said.

Interaction is key among developers and between developers and their users or customers, he added. "The longer the gap between requirements gathering and getting users' feedback, the farther off you'll be from your target," Subramaniam said.

The point is to create the simplest possible thing now that meets the requirement and move on, noted Ford. That allows developers to add features later should the customer decide to do so.

Agile development methodologies Scrum: Scrum employs real-time decision-making processes based on actual events and information. Extreme Programming (XP): XP is a pragmatic approach to program development that emphasizes business results first and takes an incremental, get-something-started approach to building the product, using continual testing and revision. Evolutionary development (EVO): EVO focuses on early delivery of high value to stakeholders, and on obtaining and utilizing feedback from stakeholders. Rational Unified Process (RUP): According to Rational, RUP is like an online mentor that provides guidelines, templates, and examples for all aspects and stages of program development. Crystal: Crystal methods seek to find the simplest and most compact team structure and process for an organization, thus making the development process more speedy and efficient. Lean development: The measurable goal of lean development is to build software with one-third the human effort, one-third the development hours and one-third the investment as compared to what SEI CMM Level 3 organization would achieve. Adaptive software development (ASD): ASD embodies the principle that continuous adaptation of the process to the work at hand is the normal state of affairs. Dynamic Systems Development Model (DSDM): DSDM favors the philosophy that nothing is built perfectly the first time and looks to software development as an exploratory endeavor. Feature-Drive Development (FDD): FDD is a model-driven short-iteration process that consists of five basic activities. For accurate state reporting and keeping track of the software development project, milestones that mark the progress made on each feature are defined.

The software may take a little longer to develop when using an agile methodology, but it will be more accurate. "It's not important to deliver on time but to deliver something that works," Subramaniam added.

Estimating product delivery
While Ford agreed that it's critical to deliver software that meets users' needs, he acknowledged that it's important to be able to predict when a project will be completed. But developers, business analysts and project managers need to work together on this.

"It's a bad idea to ask developers how long it's going to take to do something because it always varies. Every project has different characteristics," Ford said. "What you can ask is how complicated is this."

To determine the length of a project, the project manager gives the user stories to the developers to decide such things as the programming language that will be used, the architecture and the framework. After that, they sit with the business analyst and go over the story cards and rate their complexity on a scale of one to eight.

The business analyst then determines the load factor using the complexity determined by the developers. This allows them to get a good first estimate that can be honed as they start to get good data.

By using metrics, you can better determine the completion date, Ford said. Find useful metrics for your own situation, such as completion statistics, code coverage and tests, and validate your metrics continuously.

Project metrics should be interesting facts about the project, not Gantt charts and not speculation, Ford added. And the number one enabler of real project metrics is binary completion criteria for all tasks.

In addition to helping you estimate the project completion date, metrics can give you general statistics about the code and tell you how the team is performing. What they can't tell you, however, is the quality of your code; whether your development methodology is good for the project, team or company; how good your developers are; or if your project will succeed.

To determine the quality of your code, you need to test it. "The best metric you could have is a completed test," Ford said.

When using an agile methodology, developers need to acknowledge that even if they're smart, they can make mistakes. And they need to be willing to go back and fix those mistakes.

"Courage is also important," Subramaniam said. "You have to have the courage to say your code is bad and fix it."

Join the conversationComment

All Rights Reserved,Copyright 2006 - 2013, TechTarget