Agile Development

Paired Programming

2006-10-17T19:48:00.000+10:00

Introduction

Pair programming requires two software engineers to participate in a combined development effort at one workstation. Each member performs the action the other is not currently doing: While one types in unit tests the other thinks about the class that will satisfy the test, for example. The person who is doing the typing is known as the driver while the person who is guiding is known as the navigator. It is often suggested for the two partners to switch roles at least every half-hour or after a unit test is made.

Benefits

Pair programming is touted to yield the following benefits:

Increased discipline. Pairing partners are more likely to "do the right thing" and are less likely to take long breaks.
Better code. Pairing partners are less likely to go down rat holes and tend to come up with higher quality designs.
Resilient flow. Pairing leads to a different kind of flow than programming alone, but it does lead to flow. Pairing flow happens more quickly: one programmer asks the other, "What were we working on?" Pairing flow is also more resilient to interruptions: one programmer deals with the interruption while the other keeps working.
Improved morale. Pair programming can be more enjoyable for some engineers than programming alone.

Collective code ownership. When everyone on a project is pair programming, and pairs rotate frequently, everybody gains a working knowledge of the entire code base.
Mentoring. Everyone, even junior programmers, possess knowledge that others don't. Pair programming is a painless way of spreading that knowledge.
Team cohesion. People get to know each other more quickly when pair programming. Pair programming may encourage team gelling.
Fewer interruptions. People are more reluctant to interrupt a pair than they are to interrupt someone working alone.
One fewer workstation required. Since two people use one workstation, one fewer workstation is required, and therefore the extra workstation can be used for other purposes.

Criticisms

Experienced developers may find it tedious to tutor a less experienced developer in a paired environment.
Many engineers prefer to work alone, and may find the paired environment cumbersome.
Productivity gains or losses are hard to compare between paired and non-paired environments, as metrics of programmer productivity are controversial at best.
Differences in coding style may result in conflict.
In the case where the team has slightly different work schedules, which is common in an environment that values work-life balance, the pair is only available during the overlap of their schedules. Therefore, not only does it require more man-hours to complete a task, a typical day has less pair-hours available, which further increases the overall task completion time.

Agile Model Driven Development (AMDD)

2006-10-09T16:57:00.000+10:00

Overview

AMDD is the agile version of Model Driven Development (MDD). The MDD approach to software development is where extensive models are created before any coding happens. The difference with AMDD is instead of creating extensive models before coding, you instead create agile models which are just barely good enough.

Initial Modelling

The initial modelling effort is typically performed during the first week of a project. This task may vary from a few hours to a couple of weeks depending on the size of your project
For the first release of a system you need to take several days to identify some high-level requirements as well as the scope of the release. The goal is to get a good feel of what the project is all about.

For your initial requirements model you will need some form of:

Usage model
As the name implies usage models enable you to explore how users will work with your system. This may be a collection of essential use cases on a Rational Unified Process (RUP) project, a collection of features for a Feature Driven Development (FDD) project, or a collection of user stories for an Extreme Programming (XP) project.

Initial domain model
A domain model identifies fundamental business entity types and the relationships between then. Domain models may be depicted as a collection of Class Responsibility Collaborator (CRC) cards, a slim UML class diagram, or even a slim data model. This domain model will contain just enough information: the main domain entities, their major attributes, and the relationships between these entities. Your model doesn’t need to be complete. It just needs to cover enough information to make you comfortable with the primary domain concepts.

User interface model
For user interface intensive projects you should consider developing some screen sketches or even a user interface prototype.

The goal of the initial architecture modelling effort is to try to identify an architecture that has a good chance of working. On the architecture side of things it is recommend to create:

Free-form diagrams
I’ve found that 99% of the time we simply need to create some free-form diagrams on a whiteboard to explore how we think we’ll build the system. It’s important to remember that you will still need to prove that the architecture works through code.

Change cases
An optional, and very interesting technique, at this point is to identify change cases which are potential architecture-level requirements which your system may need to support. Change cases allow you to test the long-term viability of your architecture without requiring you to overbuild your system because you can think through the impact of likely changes to ensure yourself that your system will still work.

Model Storming

The vast majority of modelling sessions involve a few people, usually just two or three, who discuss an issue while sketching on paper or a whiteboard. These sessions are typically impromptu events, one project team member will ask another to model with them, typically lasting for five to ten minutes (it’s rare to model storm for more than thirty minutes). The people get together, gather around a shared modelling tool and explore the issue until they're satisfied that they understand it.

Model storming is just in time (JIT) modelling: you identify an issue which you need to resolve, you quickly grab a few team mates who can help you, the group explores the issue, and then everyone continues on as before.

You will model storm to analyse requirements. For example, a user may tell you that the system you’re building must display a chart representing the bonus schedule for sales people. Together you create a sketch of what the screen will look like, drawing several examples until you come to a common understanding of what needs to be built. Sketches such as this are inclusive models because you’re using simple tools and modelling techniques, this enabling the Agile Modelling (AM) practice of Active Stakeholder Participation.

Implementation

Implementation is where your team will spend the majority of its time. During development it is quite common to model storm for several minutes and then code, following common coding practices such as Test-Driven Development (TDD) or refactoring (which is a part of TDD), for several hours and even several days at a time. Why does this work? Because your model storming efforts enable you to think through larger, cross-entity issues whereas with TDD you think through very focused issues typically pertinent to a single entity at a time. With refactoring you evolve your design via small steps to ensure that your work remains of high quality.

How is AMDD Different?

From a design point of view the AMDD approach is very different than traditional development approaches where you create a design model first then code from it. With AMDD you do a little bit of modelling and then a lot of coding, iterating back when you need to. Your design efforts are now spread out between your modelling and coding activities, with the majority of design being done as part of your implementation efforts.

Why Does This Work?

AMDD works for several reasons:

You can still meet your "project planning needs"
By identifying the high-level requirements early, and by identifying a potential architecture early, you have enough information to produce an initial cost estimate and schedule.

You manage technical risk
Your initial architecture modelling efforts enable you to identify the major areas of technical risk early in the project without taking on the risk of over modelling your system.

You minimize wastage
A JIT approach to modelling enables you to focus on just the aspects of the system that you're actually going to build.

You ask better questions
The longer you wait to model storm a requirement, the more knowledge you'll have regarding the domain and therefore you'll be able to ask more intelligent questions.

Stakeholders give better answers
Similarly, your stakeholders will have a better understanding of the system that you're building because you'll have delivered working software on a regular basis and thereby provided them with concrete feedback.

Approaches to AMDD

There are three basic approaches to applying AMDD on a project:

Manual
Simple tools, such as whiteboards and paper, and inclusive models are used for modelling.

Design Tool
Inclusive models are used to explore requirements with stakeholders, and to analyse those requirements. Developers then use sophisticated modelling tool for detailed design, (re)generating source code from the models.

Agile MDA
Very sophisticated, MDA-based modelling tools used to create extensive models from which working software is generated.

Agile Unified Process

2006-10-04T09:03:00.000+10:00

The Agile Unified Process (AUP) is a simplified version of the Rational Unified Process (RUP). It describes a simple, easy to understand approach to developing business application software using agile techniques and concepts yet still remaining true to the RUP. The AUP applies agile techniques include test driven design (TDD), Agile Modeling, agile change management, and Database Refactoring to improve your productivity.

Phases

Inception
The goal is to identify the initial scope of the project, a potential architecture for your system, and to obtain initial project funding and stakeholder acceptance.
Elaboration
The goal is to prove the architecture of the system.
Construction
The goal is to build working software on a regular, incremental basis which meets the highest-priority needs of your project stakeholders.
Transition
The goal is to validate and deploy your system into your production environment.

Disciplines

Model

The goal of this discipline is to understand the business of the organization, the problem domain being addressed by the project, and to identify a viable solution to address the problem domain.

Implementation

The goal of this discipline is to transform your model(s) into executable code and to perform a basic level of testing, in particular unit testing.

Test

The goal of this discipline is to perform an objective evaluation to ensure quality. This includes finding defects, validating that the system works as designed, and verifying that the requirements are met.

Deployment

The goal of this discipline is to plan for the delivery of the system and to execute the plan to make the system available to end users.

Configuration Management

The goal of this discipline is to manage access to your project artifacts. This includes not only tracking artifact versions over time but also controlling and managing changes to them.

Project Management

The goal of this discipline is to direct the activities that takes place on the project. This includes managing risks, directing people (assigning tasks, tracking progress, etc.), and coordinating with people and systems outside the scope of the project to be sure that it is delivered on time and within budget.

Environment

The goal of this discipline is to support the rest of the effort by ensuring that the proper process, guidance (standards and guidelines), and tools (hardware, software, etc.) are available for the team as needed.

Philosophies

Your staff knows what they're doing

People aren't going to read detailed process documentation, but they will want some high-level guidance and/or training from time to time. The AUP product provides links to many of the details, if you're interested, but doesn't force them upon you.

Simplicity

Everything is described concisely using a handful of pages, not thousands of them.

Agility

The Agile UP conforms to the values and principles of the agile software development and the Agile Alliance.

Focus on high-value activities

The focus is on the activities which actually count, not every possible thing that could happen to you on a project.

Tool independence

You can use any toolset that you want with the Agile UP. The recommendation is that you use the tools which are best suited for the job, which are often simple tools or even open source tools.

Releases

The Agile Unified Process distinguishes between two types of iterations. A Development Release Iteration results in a deployment to the Quality Assurance and/or Demo area. A Production Release Iteration results in a deployment to the Production area.

References:
Web:

http://en.wikipedia.org/wiki/Agile_Unified_Process

Crystal Clear

2006-09-20T12:12:00.000+10:00

Intro
Crystal Clear is a member of the Crystal methodologies and is an example of a lightweight methodology. The Crystal family of methodologies focus on efficiency and habitablity as components of project safety. Crystal Clear methodologies are for development of systems that are not life-critical. Crystal Clear focuses on people, not processes or artifacts.

Team Description

There is only one team, generally consisting of up to 6-8 members, seated together in close proximity i.e. the same or adjoining offices.

Roles (requiring separate people)

Sponsor
Senior designer-programmer
Designer-programmer
User (part-time at least)

One of those team members may become project coordinator, one will become the business expert and either one or more may become requirements gatherers.

Policy Standards

Software is delivered incrementally and regularly (every 2 - 3 months).
Progress is tracked by milestones consisting of software deliveries or major decisions.
At least some automated regression testing of application function.
User has direct involvement.
2 user viewings per incremental release.
Downstream activities start as soon as upstream is 'stable enough to review'.
'Product and methodology tuning workshops' are held at the start and middle of each iteration.

Products Produced

Release sequence
Schedule of user viewings and deliveries
Annotated use cases or feature descriptions
Design sketches and notes needed
Screen drafts
A common object model
Running Code
Migration Code
Test Cases
User Manual

Team Internal Matters
Set and maintained by the team.

Templates for the work produced
Standards for coding and user interface
Standards and details of regression testing

Crystal Clear does require documentation to be produced. Just what documentation consists of is not spelled out by Crystal.

References:
Text:

Agile Software Development, Alistair Cockburn; Addison-Wesley, 2002

Feature Driven Development (FDD)

2006-09-13T11:19:00.000+10:00

Overview

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.

Activities

FDD describes five basic activities that are performed within the software development process. In the figure on the right the meta-process model for these activities is displayed. During the first three sequential activities an overall model shape is established. The final two activities are iterative for each feature.

Develop Overall Model

The project starts with a high-level walk through of the scope of the system and its context is performed. Next, detailed domain walkthroughs are held for each modeling area. In support of each domain, walkthrough models are then composed by small groups which are presented for peer review and discussion. One of the proposed models or a merge of them is selected which becomes the model for that particular domain area. Domain area models are merged into an overall model, the overall model shape being adjusted along the way.

Build Feature List

The knowledge that is gathered during the initial modeling is used to identify a list of features. This is done by functionally decomposing the domain into subject areas. Subject areas each contain business activities, the steps within each business activity form the categorized feature list. Features in this respect are small pieces of client-valued functions expressed in the form , for example: 'Calculate the total of a sale' or 'Validate the password of a user'. Features should not take more than two weeks to complete, else they should be broken down into smaller pieces.

Plan By Feature

Now that the feature list is complete, the next step is to produce the development plan. Class ownership is done by ordering and assigning features (or feature sets) as classes to chief programmers.

Design By Feature

A design package is produced for each feature. A chief programmer selects a small group of features that are to be developed within two weeks. Together with the corresponding class owners, the chief programmer works out detailed sequence of diagrams for each feature and refines the overall model. Next, the class and method prologues are written and finally a design inspection is held.

Build By Feature

After a successful design inspection a per feature activity to produce a completed client-valued function (feature) is being produced. The class owners develop the actual code for their classes. After a unit test and a successful code inspection, the completed feature is promoted to the main build.

Milestone

Since features are small, completing a feature is a relatively small task. For accurate state reporting and keeping track of the software development project it is however important to mark the progress made on each feature. FDD therefore defines six milestones per feature that are to be completed sequentially. The first three milestones are completed during the Design By Feature activity, the last three are completed during the Build By Feature activity. To help with tracking progress, a percentage complete is assigned to each milestone. A feature that is still being coded is 44% complete (Domain Walkthrough 1%, Design 40% and Design Inspection 3% = 44%).

Lean Software Development (LSD)

2006-09-06T11:55:00.000+10:00

What is LSD?

LSD is the application of Lean principles to the craft of software development. So what is Lean? According to the National Institute of Standards and Technology Manufacturing Extensions Partnership’s Lean Network, Lean is:

“A systematic approach to identifying and eliminating waste through continuous improvement, flowing the product at the pull of the customer in pursuit of perfection.”

“Lean Software Development reduces defects and cycle times while delivering a steady stream of incremental business value.”

Lean Software Development is more strategically focused than other Agile methodology. The goals are to develop software in one-third the time, with one-third the budget, and with one-third the defect rate. Lean Software Development is not a management or development methodology per se, but it offers principles that are applicable in any environment to improve software development.

The LSD Principles

Eliminate waste. In software development, waste is anything that does not improve the quality of code, reduces the amount of time and effort it takes to produce code, or does not deliver business value to the customer. In other words, any activity that does not “pay for itself” in reduced effort elsewhere in the system.

Amplify learning. For programmers to develop a system that delivers business value, they will have to learn about many things. Some are technical, such as the advantages and disadvantages to various approaches to do remote communications in .NET (i.e., remoting, COM+, web services, etc.). Others are requirements related, such as understanding what the business user really needs versus what the developer thinks the user needs.

Decide as late as possible. The idea here is to wait until what the authors term “the last responsible moment” to make a decision. This is the moment at which, if the team does not make a decision, the decision will be made for them (doing nothing is a choice). The benefits of this are avoiding or delaying the costs of change, which obviously cannot be incurred if you have not limited your options yet.

Deliver as fast as possible. This is the foundation of iterative development. Requirements change as a percentage of the original requirements increases non-linearly as the amount of time increases. Typical 9-12 month projects generate roughly a 25 percent change in requirements. However, the amount of requirements change over a month averages only 1-2 percent. And it is much easier to get users to accept waiting until next month rather than next year.

Empower the team. The quality of a software team (the people factor) is the most important element in successfully delivering software. In order to get people to take responsibility, get motivated, and gel as a team, they need to be responsible for the outcome and authorized to make it happen.

Build integrity in. The authors make the distinction between perceived integrity and conceptual integrity. Perceived integrity is the customer’s experience with your software. Conceptual integrity is how well the architecture and system components flow together to bring about the perceived integrity. Obviously testing, unit and integration, is a major part of integrity.

See the whole. Systems thinking has been around for a while, but the typical response to solving problems is to break them down into their constituent parts and optimize each individual piece. This is suboptimization, which leads to the “tragedy of the commons.”

References:
Web:

http://www.poppendieck.com/

http://sphereofinfluence.com/soiblogs/tscheer/archive/2005/09/19/159.aspx

http://codebetter.com/blogs/darrell.norton/articles/50341.aspx

SCRUM

2006-08-29T10:33:00.000+10:00

Scrum is a lightweight agile method for software development. Scrum is named after the scrum in rugby, which is a way to restart the game after an accidental infringement.

Pitched as: "Management and control process that cuts through complexity"
Invented by: Jeff Sutherland, Ken Schwaber, Mike Beedle. Senior managers wanting to get product out faster.
Where invented: USA
Year first used: 1994
First used on: Advanced Development Methods - process automation software. 8 developers. VMARK - OO software development environments.
Now used on: All over the place with different groups/people.

Scrum assumes that the software development process is complicated and unpredictable and treats it as a controlled black box instead of a theoretical, fully-defined process. This is main differences between Scrum and Waterfall methodologies, which view the software development process as a fully defined process. Most problems encountered when using these older, formal types of methodologies like waterfall are:

Requirements are not fully understood at the beginning of the process.
Requirements change during the process.
The process becomes unpredictable when new tools and technologies are used.

Another characteristic of Scrum is that the software development process isn’t treated as a linear process, unlike the Waterfall, Spiral and Iterative methodologies. In a lot of cases this linear process consists of the following four activities: Analysis, Design, Implementation and Testing. Scrum, however, doesn't prescribe a sequence in which the activities must be implemented. A project can start with any activity, and can change between activities at any time. This increases the project's flexibility and productivity. Other characteristics of Scrum are:

Flexible schedule
Flexible deliverables
Small teams
Frequent review
Object oriented
Collaboration between and within teams

References:
Web:

http://agilethinking.net/blog/what-is-scrum/

http://en.wikipedia.org/wiki/SCRUM#Simplified_Scrum

http://www.balagan.org.uk/work/agile_comparison.htm

http://en.wikipedia.org/wiki/Scrum_%28development%29

Agile Risk Management

2006-08-22T11:39:00.000+10:00

Agile Software development can help reduce Risk in a software development project by reducing the risk level of 5 of the top 10 project risks:

Feature creep
Gold plating
Short changed quality
Overly optimistic estimates
Friction between developers and customers

Agile methods attempt to minimize risk by developing software in short timeboxes, called iterations, which generally extend from one to four weeks. Each iteration is like a mini software project of its own, and includes all of the tasks necessary to release the mini-increment of new functionality: planning, requirements analysis, design, coding, testing, and documentation. While an iteration may not add enough functionality to warrant releasing the product, an agile software project intends to be capable of releasing new software at the end of every iteration. At the end of each iteration, the team re-evaluates project priorities.

Agile methods also emphasize working software as the primary measure of progress. Combined with the preference for face-to-face communication.
Agile methods emphasize realtime communication, preferably face-to-face, over written documents. This requires constant communication (feed-back) between the customer and the software development team, particularly after each iteration of deliverables.

References:
Text:

Agile Software Development, Alistair Cockburn; Addison-Wesley, 2002

Web:

http://www.balagan.org.uk/work/agile_comparison.htm

http://en.wikipedia.org/wiki/Agile_development

Extreme Programming (XP) Summary

2006-08-14T15:57:00.000+10:00

What is XP?

XP is a software engineering methodology, the most prominent of several agile software development methodologies. XP prescribes a set of day-to-day practices for developers and managers said to enable the development process to be more responsive to the customers needs. XP tends to trade predictability more for adaptability. Proponents believe XP's flexibility is more realistic than traditional methodologies.

XP Values

Simplicity - It is better to implement the simplest solution.
Communication - Increases cooperation, group productiveness, and decreases mistakes.
Feedback - Keeps the project on track. Feedback should be almost continuous.
Courage - Required to be able to throw code away when it is appropriate, or to refactor late in the design to increase system performance.

XP Principals

Pair programming - Ensures quality code. One programmer is thinking whether the approach will work, about testing, or ways to simplify the code while the other programmer writes the code. The roles of the two programmers may change often, and programmer pairs may change often.
Simple design - Keep the design as simple as possible for the moment and don't add features that are not needed for current functionality. The reasoning behind this is that if a feature is not valuable now, it is not worth the investment until it is valuable.
Small releases - There is a short time between versions.
Refactoring - The code is restructured as necessary to improve structure and performance. Refactoring is done before additional capabilities are added, not while they are being added to be sure the system is not broken during refactoring.
Testing - Tests are written first and must run for design to continue. Testing is done often. Customers may determine tests required to determine what features work.
Integration - Code is continuously integrated together.
Correct working hours - Generally limited to 40 hours per week with no overtime for more than one week at a time. This is to keep programmers alert so they do not make mistakes.
Customer availability - The customer is on site to answer questions or at least is readily accessible.
Standards of coding - There are group rules for code so all members can understand the code readily.
Group ownership of code - All members of the group can change any code at any time.

When to use XP?

XP is more suited to projects where the full requirements are simply not known up front, are vague, and are very likely to change. In these situations it can be better to get something out to the user quickly, to get feedback early and often.

References:

Text:

Agile Software Development, Alistair Cockburn; Addison-Wesley, 2002

Web:

http://en.wikipedia.org/wiki/Extreme_Programming

http://www.byte-vision.com/MovingToXPArticle.aspx

Intro to Agile Development

2006-08-10T17:01:00.000+10:00

Agile, agile.. why am I doing this again?? umm... that's right to find out what all the hype is about.. is it really as good as what I have heard? What scenarios is it best suited to and what isn't it so hot for? What practises work better than others? Is it one size fits all? Or is the right tool for the right job more the focus here? I hope to find the answers to these and many more of questions in the coming weeks.

After my first few lectures on agile methodoligies I understand that we are throwing away a lot of traditional documentation (YAY). Well not throwing it away, more like trading it for great communication (bonding) with team mates and a more dynamic and less structured documentation process. Very interested to see how well this style works. Will post my concluding thoughts about one of my later posts.

We have formed teams this week. I think I'm in a good team. Got some great, very hard working team mates which I look forward to working with this semester.. some I have known previously and some new ones. Go Team 'Rocket'.. who thought of that name again?!?!

Thought I'd let you all know that this is like my first blog ever. Probably very obvious!