Jann P. Thomas 在 Scrum 联盟的网站上最近发了一篇很有趣的文章，名为阴阳与项目管理。她应用阴阳学说对敏捷宣言进行了阐述。
阴阳学说的基本内容包括阴阳对立、阴阳互根、阴阳消长、阴阳转化四个方面。Thomas 认为，敏捷宣言中的原则也体现着对立、互根、消长、转化。
正如阴阳必须并存，敏捷实践者所提倡的价值（可以工作的软件、协作、变化、交互）也都无法脱离对立的阳面（文档、合同、计划、过程）而存在。
Thomas 详细解释道：
敏捷并不是反过程（anti-process）。举个例子来看，人们常常会碰到没法按照迭代伊始的计划做事，要在迭代中间对产品做出改动的情况。为了保证 透明、高效，项目经理就要创建一个过程，用于引入未经计划的新任务。这个过程必须记录下来哪些任务要从迭代中挪走，好给新任务腾出空间；然后包括客户在内 的整个团队就不但可以知道发生了哪些变化，还能清楚这些变化所带来的成本。敏捷项目经理需要做到自省。好的敏捷项目经理应当审视组织中现有或是正在构建的过程，继而提出质疑。这个过程适用于敏捷环境吗？这个过程对团队的交付能起到助益么？另外，透过敏捷回顾，整个团队也有机会评估他们自己对过程所做出的改进——保留有用的，扔掉没用的。
……
敏捷团队和敏捷项目经理并不排斥文档……在要用到需求的时候才把需求整理好（准时化生产——Just In Time），其结果通常都是一些架构图、用例、功能说明。只有那些对开发有用的文档才会被制作出来，加以维护（够用就好——Just Enough）
……
所有的软件项目都有合同，不管是显式还是隐式的……大多数项目经理都很熟悉限制三角形（constraint triangle）的三条边：范围、时间、质量。如果时间（完成日期）固定，质量也有高要求，那就只剩下范围可以妥协。跟客户或者产品负责人进行范围的谈判也是敏捷项目管理的一个关键环节。
可能在一些人的眼中，Thomas 的这篇文章只不过是老生常谈，早已变成敏捷实践者的常识、共识，只是冠上了“阴阳”之类的帽子增加了神秘感而已。比如多年前，在《平衡敏捷与规范》一书中，作者便提到过：
值得注意的是，宣言中的价值观都是相对的陈述，而非绝对。也就是说，它们代表的是两种选择方法的权重，不是非此即彼的二元选择。
而 Thomas 对“响应变化胜过遵循计划”这一条的解释也显得有些片面，强调“变化”的文字多，而讲“计划”的文字少，只这样提了一句：
敏捷原则是对立的：做事情必须要有计划，但计划会发生变化。
倒不如来看看 Martin Fowler 和 Kent Beck 在《规划极限编程》中说的：
需要做计划的原因有如下几条：
- 我们需要确保始终在做最重要的工作。
- 我们需要和其他人通力合作。
- 当意外事件发生时，我们需要了解前两项的因果关系。
读者朋友，你对 Thomas 的文章是何看法？是帮助你加深了对敏捷原则的认识，还是觉得更像是扯“阴阳”的淡，扯文化的淡？欢迎留下你的观点。
评论