Thanks!

We are thankfull to the following persons for helping and designing our SQABD community logo with their valuable professional touch:

• Ahsan Parvez Liton, Evoknow
• Tarique Mahmud Tomal, Uniqa

Bridging Agile and Traditional Dev. Methods

Bridging Agile and Traditional Development Methods: A Project Management Perspective
Paul E. McMahon, PEM Systems

Today, companies are reporting success in meeting rapidly changing customer needs through agile development methods. Many of these same companies are finding they must collaborate with organizations employing more traditional development processes, especially on large Department of Defense projects. While it has been argued that agile methods are compatible with traditional disciplined processes, actual project experience indicates conflicts can arise. This article identifies specific project management conflicts that companies face based on actual project experience, along with strategies employed to resolve these conflicts and reduce related risks. Rationale, insights, and related published references are provided along with lessons learned and recommendations. If you work for a company that is using or considering using agile development, or your company is collaborating with a company using an agile method, this article will help you understand the risks, issues, and strategies that can help your project and organization succeed.

---

This article was motivated by a case study where a small company using a well-known agile method - eXtreme Programming (XP) - requested help addressing specific conflicts that arose on the project where they were a subcontractor to a larger organization employing a traditional development method. The purpose of this article is not to compare agile and traditional methods, but to raise awareness of potential project management conflicts that can arise when a company employing an agile method collaborates with a company employing a traditional development methodology. It also identifies practical steps that can be taken to reduce related risks.

It is worth noting that the case study presented is not unique. Published references documenting similar conflicts are provided. Also notable is that the motivation for examining this project extends beyond the case study itself. Today there exist increasing opportunities for small companies to gain new work through software outsourcing from traditional development organizations.

Where Are We Going?

In this article, I first identify key case study facts along with relevant information and common misperceptions related to traditional and agile methods. Next, I identify four conflicts observed along with five recommendations and one lesson learned. The company named SubComp refers to the subcontractor employing an agile methodology. The company named PrimeComp refers to the prime contractor employing a traditional development methodology.

(see more from Source : Cross Talk)

The Agile System Development Lifecycle (SDLC)

The Agile System Development Lifecycle (SDLC)
by Scott W. Ambler

I'm often asked by clients to facilitate workshops overviewing the ideas presented in the Agile Manifesto and agile techniques such as Test-Driven Design (TDD) , database refactoring , and agile change management . One issue that many people seem to struggle with is how all of these ideas fit together, and invariably I found myself sketching a picture which overviews a generic lifecycle for agile software development projects. This lifecycle is captured in Figure 1, which is comprised of four phases: Iteration 0, Development, Release/End Game, and Production. Although many agile developers may balk at the idea of phases, perhaps Gary Evan's analogy of development seasons may be a bit more palatable, the fact is that it's been recognized that processes such as Extreme Programming (XP) and Agile Unified Process (AUP) do in fact have phases (for diagrams, see XP lifecycle and AUP lifecycle respectively). Furthermore, the Agile MSF calls its phases/seasons "tracks".


See more from Source : Agile SDLC

"Source Control HOWTO" - by Eric Sink

Source Control HOWTO

by Eric Sink

I have started writing a series of articles explaining how to do source control and the best practices thereof. See below for links to the individual chapters in this series. The Introduction explains my motivations and goals for writing this series.

Please note: This is a work in progress. I plan to be adding new chapters over time, and I may also be revising the existing chapters as I go along.

Printer-friendly version: Sorry folks, but I currently do not have this material available in a form which is more suitable for paper. Someday I probably will, and when that happens, a link will appear here.

Chapter 0: Introduction

Our universities don't teach people how to do source control. Our employers don't teach people how to do source control. SCM tool vendors don't teach people how to do source control. We need some materials that explain how source control is done. My goal for this series of articles is to create a comprehensive guide to help meet this need.

Chapter 1: Basics

Our discussion of source control must begin by defining the basic terms and describing the basic operations.

Chapter 2: Checkins

In this chapter, I will explore the various situations wherein a repository is modified, starting with the simplest case of a single developer making a change to a single file.

(read more)

_______________________________________
Thanks to Eric Sink for his valuable article