How To Run A Refactoring Project
January 23rd, 2008
(From my chat history with Michael Robinson.)
(11:16:46 PM) xcqmichael: In your situation, it's important to understand that there are two ways of looking at software, the coder way and the business way.
(11:17:22 PM) xcqmichael: The coder says software is successful if all the tests pass, the code is well structured, and easy to understand and maintain.
(11:18:01 PM) xcqmichael: The businessman says software is successful if it delivers more value to the business than the business spent to create it.
(11:19:22 PM) xcqmichael: You separate them in terms of pain points.
(11:25:00 PM) xcqmichael: point 1:
(11:25:53 PM) xcqmichael: Refactoring stories (or other technical debt stories) are like any other kind of story; they should follow INVEST criteria, they should have an estimated effort, and they should have a prioritized business value.
(11:26:18 PM) xcqmichael: Because, in the end, it all comes down to cost to code vs. value to business.
(11:26:28 PM) xcqmichael: point 2:
(11:27:12 PM) xcqmichael: Refactoring, by definition, means making changes to the structure or organization of a code base without changing its functional behavior.
(11:28:06 PM) xcqmichael: When you have a code base that is fragile and has no test coverage, it is very costly to refactor because it is very costly to confirm you have not changed functional behavior.
(11:28:12 PM) xcqmichael: point 3:
(11:28:51 PM) xcqmichael: When the cost of a technical debt story is very high, then the business value must be even higher.
(11:29:44 PM) xcqmichael: Consequently, the worse the code looks to you from a coder point of view, the more you should leave it alone from a business point of view.
(11:29:51 PM) xcqmichael: point 4:
(11:30:27 PM) xcqmichael: Therefore, when someone says, "there's whole bunch of code needs to be refactored", probably, none of it should be.
(11:31:49 PM) xcqmichael: Well, it all comes down to prioritization.
(11:32:00 PM) xcqmichael: And a clear sense of the cost/value tradeoffs.
AMM不是什么
January 16th, 2008
以前我不认为一个被称为“敏捷成熟度模型”（Agile Maturity Model，AMM）有可能是什么好东西。原因是显而易见的：第一，我担心它把一组实践奉为圭臬，而敏捷的核心正是在于根据团队和项目的实际情况构造自己的方法；第二，我担心它成为一种认证，从而像它的前辈一样被骗子利用。
直到我给客户做了一次AMM评估。
第一，AMM不是认证，它是帮助我们集中注意力、了解真实情况的工具。
第二，AMM不是考试，分数是指示性的而不是决定性的，它的价值是指出改进的方向和切实的目标。
第三，进行AMM评估的目标是帮助团队更加高效地开发更高质量的软件，而不是拿到高分。
不遵循这三点原则的AMM评估，就可能滑入骗子横行的境地。敏捷的本质决定了AMM评估只能并且只应该被用于三个目的：（1）了解“我们在哪儿”；（2）计划“我们要去哪儿”；（3）讨论“如何去”。因此，任何与真实情况不符的、夸大的、粉饰太平的评估，都是毫无价值的自欺欺人。
参见另一个ThoughtWorker，Ross Pettit的文章，An "Agile Maturity Model?"
致那个人
January 9th, 2008
发明敏捷工具
January 6th, 2008
- 问题是什么？
- 头脑风暴：可能的候选方案有哪些？
- 这些候选方案之间的差异是什么？（分出至少三个维度）
- 选择其中最重要的两个维度，划出四个象限。
- 标注：每个象限里的候选方案适合哪种场景？
- 我们的问题在哪个象限？（选择推荐方案）
- 从三个角度细化推荐方案
- 要达到什么目标
- 采用什么手段来达到目标
- 如何验证目标是否达到
- 用适当的格式把细化的推荐方案记录下来
