Posts Tagged ‘Best Practices’

« Older Entries
Newer Entries »

Agile Software Development Processes: Defining User Stories and Cross Functional Teams

August 20th, 2010 by damonpoole
Share|

Over the past ten years, a number of Agile software development process “guidelines,” or best practices, have formed and are now becoming widely adopted.  Terms used to describe these best practices are sometimes new to developers, so I defined the practices that I believe provide the most value to a wide variety of development teams in order to create a highly functional, unified software development process.  I have by no means compiled a full list, but over the next few posts I will introduce you to some ideas that you may find worthy of further investigation.

Agile Software Development Process: User Stories

Consider the following requirement and sub-requirements.

  • 3 Simplified Purchasing
  • 3.1 Customer Identification
    • 3.1.1 A web “cookie” shall be used to uniquely identify visitors
    • 3.1.2 Each customer shall be associated with a cookie
    • 3.1.3 Cookies shall be stored in an RDBMS
  • 3.2 Sale presentation
    • 3.2.1 Each item for sale shall have a button marked “buy” next to the item
    • 3.2.2 Selecting the “buy” action shall trigger an order placement action
  • 3.3 Fulfillment
    • 3.3.1 By default, all orders shall use the on-file default shipping information
    • 3.3.2 If available, all orders will use the customer’s default payment method
    • 3.3.3 It shall be possible for the customer  to cancel any order for up to 4 hours after they place that order.

This set of requirements is for something called “simplified purchasing.”  Take a moment or two to consider how you would sum it up in a single plain-English sentence.

The requirements called “simplified purchasing” describe the user’s desire for “one-click purchasing.” In terms of a user story this would be phrased as “As a user I want one-click purchasing.” User stories are a description of what is needed from the user’s perspective. User stories help to separate business value from implementation and focus all parties on the desired outcome.

User stories are different than requirements. When using requirements, it is likely that the developer implementing the requirement will be presented with an implementation task or a design document and be constrained to implementing as specified or as designed. A user story removes invisible constraints by focusing on the outcome desired by the user. The developer doing the work will see the user story, will be able to better understand what the user needs, and will be able to participate in or even own the specification and design of that story. User stories provide engineers more freedom to utilize their creativity and ability to innovate without the risk of implementing something that the user doesn’t want.

A user story does not necessarily replace requirements documents or other documents. A common scenario is that the user story is the unifying high-level description for the work that needs to be done to make sure that everybody involved has a common understanding of the work, from customer to developer to tester to doc writer and back to the customer.

Agile Software Development Process: Cross Functional Teams

A cross functional team is a small group of people (7 + or – 2) that works together towards a common purpose, where time is primarily spent as part of the team, and, as a team, has all of the skills needed in order to be self-sufficient. These skill sets may include server side programmer, web designer, tester, technical writer, project manager, etc. The intended benefit is that you spend less time waiting for other groups and bringing part-time participants up to speed, you lose less time due to communication delays, and individuals spend less time multi-tasking between multiple projects.

Next best practices I will explore? Collocation and Unit Testing.

No comments »

Posted in AccuRev, Agile, Best Practices, cross-functional teams, Educational Webinars, Tips and Tricks, user stories

Tags:

Continuous Integration: What’s Not to Love?

July 29th, 2010 by clucca
Share|

It seems like everyone loves continuous integration.  I’ll come out and say it- I love continuous integration! When we talk about the most widely adopted Agile practices, this one comes up the most.  Its positive benefits as a feedback mechanism provide a quantum leap forward in how development organizations think about their code.  I find it very difficult to see any downside in doing continuous integration, seriously what’s not to love?

Modern day continuous integration servers have 3 functions: Detect if a new build is needed, execute build, and notify people of the results. This is a great way of facilitating feedback to developers and allowing them to adapt and resolve problems.

But there’s something lurking in the shadows that nobody is talking about, maybe because people aren’t even aware that it’s a problem. Maybe it’s because we don’t want to ruin our love affair with CI and we’re all in denial.

What happens when those builds are done? What about the rest of “it”?

When I say “it” what I really mean is:

Most development environments include such things as complex application servers, automatic testing, release processes, compliance, audits, databases, 3rd party libraries, build dependencies, code analysis, unit tests… and another 1,000 other things I don’t have enough space to list here. How can you deal with this? Getting feedback to my dev team is a great targeted way to let people know code is broken, but isn’t this feedback useless if you can’t get the product out the door?

If I take an example build lifecycle of an application which is:

1.)    Build Application

2.)    Test

3.)    Deploy to environments (DB) (APP SERVER) <- by hand

4.)    Test

5.)    Redeploy (DB) (APP SERVER) (PROD) <-by hand

This may seem like easy in this example, but if we took all of these steps in the real world, this could represent hundreds of servers.  And this process will have to be repeated for every version of the product.

The crux of this issue is that if any of these steps are not performed 100% correctly, it translates to real dollar$ lost for the organization. These operations have to perform like clockwork.

Taking Continuous Integration to the Next Level

This is why I believe bringing continuous integration to the next level starts with the concept that the build produced from the CI server is just the beginning. Setting up a simple CI server and producing a build is easy, but managing it through the rest of its life is the real trick.

In a real example of this, we could take

1.)    Build

2.)    Run automated tests

  • If test succeeds: Deploy to to environments (DB) (APP SERVER)
  • If test fails: Notify dev team

3.)    Manual Testing in QA environment

4.)    Approval process

5.)    Redeploy (DB) (APP SERVER) (PROD)

Using AgileCycle RM

In this scenario I’m taking a version of the results from a CI build, run automated tests on them, monitor the test output and wait for success or failure. If there is success then deploy all components of the application, this includes a database components and a java war component. The build will then sit in QA for manual testing until its marked approved by the QA team, managers and operations team for deployment to production.

The idea here is if we automate these processes and decisions based on build, automated tests and approval process, you can produce code quickly and at a more rapid pace. If you can produce a clockwork-like automation around your build/test/deploy related processes, your team can spend time on what’s most important: Getting code out the door.

No comments »

Posted in AccuRev, Agile, AgileCycle, Best Practices, continuous integration, Tips and Tricks

Tags:

Change Packages for Agile Workflow

June 24th, 2010 by damonpoole
Share|

User Story Based Engineering

In other blog posts I’ve talked about using Multi-stage Continuous Integration to scale Continuous Integration for use in multi-team environments and using streams or branches to model your workflow directly in your SCM tool. While both of these approaches work well and provide a lot of value, they can also present a new challenge: how to associate enhancement requests and defects, which can be lumped together using the term “work items,” with the changes that implement them?

If you are doing mainline development, life is pretty simple. On check-in enter the enhancement request ID or defect ID in the comments. Once that association is made, it is fairly straightforward to figure out which enhancements and defects have been checked in. On the other hand, the more people you have checking in to the same branch, the less likely it is to be stable, even if you are doing Continuous Integration. So, how can we maximize the benefits of using streams to represent process and integration stages and still have the ability to match work items to the work done to implement them?

Representing Process and Integration Stages with Change Packages

(Let me first point out that while I’m using the generic term “work item” here, in an Agile team one would most likely use the term “User Story.” Both apply equally well in this context, but I’ll stick with work item for now.)

There is an SCM concept that maps to a work item which can be tracked from place to place, and that is a “change package.” It is called a change package because it represents something which, once defined, can be applied to multiple places and tracked regardless of how many different places it has been propagated.

Change packages can be promoted individually or in groups from stream to stream. That way, as work is promoted from stream to stream you have a record of the content of each stream from a high level perspective instead of a files perspective. A list of files is not very meaningful or useful. On the other hand, change packages allow you to ask questions like “which user stories are in the stream that represents all user stories that are ‘done’,” without having to resort to mainline development.

No comments »

Posted in AccuRev, Agile, Best Practices, change packages, continuous integration, user stories

Tags: