Agile Software Development

I wrote about Acceptance Testing earlier and why it is a very important tool for agile development. In this post, I will talk about how we can make acceptance testing really agile. Actually, it's nothing more special than making Acceptance Testing a part of your Continuous Integration (CI) (an XP Primary Practice). Continuous Integration is the practice of merging, building, and testing code on a continuous basis (almost instantaneous basis).

Courage and Respect are 2 of the 5 XP Values; and Energized Work (aka Sustainable Pace) is one of the Primary Practices. I want to share a work ethic that would seem to be opposite of these values and practices; I will then demonstrate how it is actually just another way to implement XP practices and how this work style has these value built in.

This is part 4 of a series of articles on Distributed Agile Development. In this article I will talk about the problems that are faced when writing user stories in a distributed development scenario, and how the INVEST approach can falter.

I published an article introducing the 3 C's and the INVEST approach when it comes to write user stories. One of the most important lessons of that article is that there is a need to negotiate/communicate with the end user while developing the user story.

Advertisement:

What is a User Story?

A user story describes desired functionality from the customer(user) perspective. A good user story describes the desired functionality, who wants it, and how and why the functionality will be used. The basic components of a User Story are sometimes dubbed as the three C's:

What is acceptance testing?

Acceptance testing is a black-box testing performed on a software prior to its delivery. It involves running a suite of tests on a completed system (ref: Wikipedia). These test suites are made up of multiple tests or test cases. Each test case consists of a sequence of steps to perform which emulate the use case that is being tested; it also contains input data (if required) as well as the expected output. The result of a test case is either a pass or a fail.

This is part 3 of a series of posts about using agile methodologies in distributed development scenarios.

One of our readers (Deven) posted a comment emphasizing the importance of a well organized collaboration system when doing distributed agile development. In his list of essentials, he mentions the need for a "Central Globally Available Source Control System". He is correct and so in this post I will talk about the various tools and techniques that can be used to manage a central source control repository.

This is part 2 of an indefinite series of posts centered on using agile techniques in distributed development scenarios. (See also Part 1 on Reinterpreting th Manifesto)

At work, most of our projects have daily Scrums. For some of our projects this simple activity becomes much more laborious because part of the team is in a different time zone. In this post I will write about some key guidelines that we follow to make sure that Scrums remain productive and interesting. Without further ado, here we go:

I work for a software company which has their development center in India. A large portion of the work that we take on has to do with product co-development. These clients are typically ISVs who have active product development teams. They usually partner with us to augment their team sizes to take advantage of the extended daily development cycle. So, for a client who is in the US, for example, our team here takes over from the US team when they come into the office and then hand over to the US team when they leave; this allows almost round-the-clock development.

In such a scenario, where two separate teams are working in close coordination with each other, the right kind interpersonal relationship within team members can really boost productivity and efficiency. So, how do you get a proper relationship going?

This is Part 1 of an indefinite series of posts centered on the topic of distributed development and using agile methodologies in distributed teams.

Problem
One of the principles of the Agile Manifesto is: “The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.” The manifesto was put together in 2001; a long time ago by software industry standard. At that time, offshore development (the primary scenario for distributed development) was beginning to gather momentum, but most such development occurred using the traditional heavy-weight development methodologies.

Microsoft Solutions Framework is a set of processes, principles, models, and best practices geared at helping developers develop software successfully. MSF is an adaptable set of guidance and best practices aimed at increasing the chances of success during the Software Development Life Cycle.