The Myst of Agile – the ideal is beautiful, the reality is ugly

整理有道云笔记，发现一篇大概写于2015年左右的关于敏捷的思考，贴上来以纪念那些专注于研发的岁月。

1. About Iterations

• Iterative and Incremental Development – IID. What are we doing? – Iterative? Incremental or IID? Suppose we are doing IID in most cases, don’t be confused by the term of “iteration”.
• IID – All Iterations should have a verifiable deliverable. That’s why we need to involve test team in iteration planning meeting to help on the backlogs identification.
• Tracking Agile project commitments is based on scope. Trying to keep same iteration length as much as possible. Move the underestimated part to latter iteration even buffer iteration. The pace of iterations is the beauty of Agile like the turns of seasons, ticks of clock, or rhythm of running. But life is not always simple. Team still needs the balance between schedule and scope.

2. About Milestones

• Milestones are something serving for waterfall model. How can you imagine you can accurately foresee a very specific release date in one year later while so many things will be changed during that one year? But we still keep that date as our M11 Commitment! So people play with data and date (increase internal buffer to make the commitment safe for example). 
• Release date should be forecasted based on scope and quality along with iterations ongoing. A rough date could be expected (which quarter or which month) in the beginning of the project. More accurate date will be forecasted in later phases. Then people can focus on the real work and real quality, not scaring of the deadline that defined one year ago.
• M5 is absolutely derived from waterfall model. That assumes the box test will only start after all development done. In Agile, test involves in every iteration to make sure the delivery of every iteration is healthy. A short cycle of full regression is still needed after all iterations, but that should be very short as most of tests are already passed in previous iterations. This is how Agile improves quality and shorten cycle time. Why can’t we do like this?

3. About Architecture

• System architecture should be locked down before iterations or at least in very early iterations.
• So, for the project of new platform creation, the 1st iteration might not be able to have a verifiable deliverable because the platform that support the whole architecture need to be built first and that is probably not verifiable without feature associated. But this doesn’t stop the goal that agile team should set to define the backlogs verifiable as many as possible and as early as possible in iterations.
• For the project of new platform creation, my suggested lifecycle model is Prototyping, not agile Iterations. Once we have defined the architecture and high level technical solution, then it’s ready for IID planned for subsequent features development.

4. About Test

• Agile can never live without test. Test is naturally part of Agile. 
• Automation is the spirit of the test in Agile because only automation test can meet the quick turnover of the daily build. 
• TDD is an embedded format of testing to build functions/features inside coding. Regression is a quality guard after functions/features ready. Both of them theoretically are in the same one iteration. Actually you could insert your own test anywhere inside the work flow once the automation test framework with test case pool is in place.
• TDD contradicts with normal coding habit. To overcome the habit is expensive, though the benefit is obvious but hard to measure. TDD is also highly relying on automation framework that should be easily maintained with more codes added. That’s why TDD is difficult to implement.
• Try to combine the auto test in the work flow of Continuous Integration. I’d rather interpret it is not a full concept of CI if there’s no auto test attached.

5. About Refactoring

• Refactoring is the process of changing a software system in such a way that it does not alter the external behavior of the code yet improves its internal structure. Refactoring opportunities can be found from architecture down to the code level.
• A risk evaluation should be done to determine if refactoring is necessary.
• The emphasis should be on refactoring the newly implemented code and not legacy code.
• Refactoring needs automated test to support. Otherwise you cannot do refactoring frequently because you cannot afford the test effort after refactoring.
• Refactoring should be a formal planned action in each iteration, not a one-time shot in the beginning of a project and then totally forgotten afterwards.

6. About Paired Programming

• Paired Programming, requires a social change as well as a technical change, so we expect more resistance to this practice than others. 
• Formal Technical Review can be integrated in paired programming if team has confidence to skip or consolidate the FTR(s). The precondition is that the two engineers in the pairing both have enough domain knowledge on what they are doing. The pairing with mentoring purpose cannot guarantee the quality of peer review integrated in the paired programming.
• For Agile projects doing Paired Programming and not formal reviews, ICE may be significantly lower because faults may not be logged. But on the other hand, faults logging is not really important in Agile because Agile weights the working software (…think about 4-UP charts). 

7. About Tools

• Agile never compels a specific tool to manage and track the project progress. As a manager you know project progress through talking and walking in the team.
• Version One is not mandatory to manage the Agile project. It does provide more functions like “feature group”, but if you only need a tool to track backlog progress, Excel spreadsheet is the simplest and fastest one.