Code on Windows 7 using Visual Studio 2010

http://blogs.msdn.com/saraford/archive/2009/03/16/how-i-learned-to-program-manage-an-agile-team-after-6-years-of-waterfall.aspx

Trong bài này Sara Ford chia xẻ những kinh nghiệm của bản thân khi chuyển sang quản trị dự án theo phương pháp Agile trong dự án CodePlex sau 6 năm làm việc với Water Fall. Vài điểm cần lưu tâm từ bài viết này:

• One week iterations
• Test driven development
• Continuous integration
• Pair programming
• Shared workspace
• Collective ownership of codebase among devs

1. Design and plan for the very next step, instead of designing and planning for the very next feature.

In traditional product groups, specifications can be as long as 60 pages. Every scenario must be known at design time and figured out, because you only get one shot of getting it right. The analogy here is firing a gun. You could spend a significant amount of time planning, calculating, aiming to achieve the perfect shot. Or using the agile approach, you could aim and fire, recalculate aim and fire, recalculate aim and fire. You could say that traditional product groups do this to some extent, but a few years is a long time to wait for a recalculated shot.

….

2. Break down work into smallest possible sets. Adding work is fun and rewarding; removing work is painful and risky.

Maybe it was light bulb moment #1 going off that enabled the “on” switch for light bulb #2.Towards the end of last summer, I was so exhausted from the book, trying to figure out agile, doing major speaking events, and of course not to mention promoting open source within Microsoft, I decided to “give up” for one particular release and just do the minimum amount of work possible to get the deployment out. I was just too exhausted to worry about enduring the potential wraith of my manager (see #4) for deploying such a small amount of work.

And of course, it turned out that was the ideal amount of feature work for the deployment. I discovered this simply based on the number of bugs that had to be fixed in the 3^rd week of the cycle, and how there was no feature work that needed to be carried over to the next deployment cycle. In other words, when I finally “failed” in the traditional program management sense, agile clicked for me. And people wonder why I’m a nervous wreck all the time (see #4).

And to explain the second half of this light bulb moment: If there were any feature work we couldn’t squeeze in, it had to be carried over, but yet it wasn’t “planned” this way. Then it was a question of do we finish a half-written feature, or do we pull it out, not fully understanding what other aspects of the feature sets it could affect in this state? We would have to make a best guess decision right before deployment.

Another analogy is like Legos. Break all the pieces down into 1x1 blocks. Then it is easy to plan, add, remove. But the larger the pieces, the more connection points, the more cost, the more complexity. I’m sure there’s some analogy to the connection points (the little bumps on the lego square) and writing the code, but I’m not a developer on an agile team, so I’ll leave that open to interpretation.

3. Design and plan 80% of the way as the very next step. Use feedback to solve the remaining 20% in the very next step after that.

Immediately after light bulb moment #2 clicked, I saw the very reason why agile rocks for customer quality. Using agile, you actually can recalibrate, aim, and fire in a time period that is reasonable for customers (compare 3 weeks to 3 years.)  I’m not talking about overall feature set comparison, but a comparison of the quality of the features being released. It was finally at this point in time I could allow myself (see #4) to take advantage of this “aim fire recalibrate repeat” concept by actually planning the recalibration time period. In other words, I could say “okay, we’re going to go with this, and based on feedback, we’ll tweak as needed in the next deployment.”