敏捷软件开发管理实践(二)—做最细致的项目跟踪.docx

第二部分做最细致的项目跟踪项目计划告诉了我们要如何去完成项目， 但是项目计划的执行并非总能够沿着预定的轨道前进可以肯定地说， 如果没有健全的反馈机制，计划的执行定然会偏离预定的轨道，而唯一能够确避免的措施就——追求项目计划执行中最细致的项目跟踪，在计划的执行稍有偏离的时候就纠正其方向，这在控制理论中，就是基于反馈的控制宏观上来说， 重型项目管理方法往往倾向于花更多的时间来作一个细致的项目计划， 以确保后期计划执行的可控但是，细致的计划并不能替代细致的跟踪1.1. 细化任务现代控制理论告诉我们，控制的精确程度是建立在被控制量量化的粒度之上量化得越细，就能够控制得越精确 因为在很少偏移量的时候这种趋势就得以纠正 但是量化并非没有代价，过细的量化会增加成本，所以这之间存在一个权衡敏捷的项目管理要能做到随机应变，应付各种可能出现的情况，也是建立在对任务的细分，并对任务的状态采取高频度的探测并及时调整的基础上那么任务究竟要细分到什么程度呢？这并没有确定的度量 不同规模的项目可能都存在不同， 但是我的经验告诉你， 如果可以的话，让你的任务的工作量尽可能控制在一天以内1.2. 控制任务的粒度项目计划的失控往往都是由于项目任务划分不够清晰， 粒度过大引起的， 我想这是我和很多软件从业者的深刻体会。

当然， 一个常见的反驳意见是“不是我们不想细化任务， 而是项目刚开始， 很多东西都很模糊，无法把任务划分得很细” 其实这句话中存在两点误解，我想从正面来说明：第一，任务划分与产品的解析度是无关的 个产品了解得越多、 越细， 就越可以把如何完成这个产品的工作任务划分得更加精细反过来， 即使一个产品初期对我们来说是模糊的， 难道我们的任务就不可以划分得很细吗？但是其实照样可以 产品从模糊到清晰的过程也是问题分解的过程， 每个大问题都可以分解为许多子问题， 而对于每一个子问题，其实完全可以对应到相应的子任务 即使我们以 “盲人摸象”为比喻，要搞清楚大象是什么，也总可以分解为按照头部，身体，四肢，尾巴几个部分分别摸来细分任务第二，任务划分包含解决问题的思路所谓任务， 都是为了解决某个具体问题， 而如何解决这个问题， 从逻辑上我们首先需要把问题分解 问题分解的过程就可以对应到任务划分的过程 比如：如何完成项目目标这个大问题就可以分解为 “如何完成需求定义？” ，“如何完成系统设计？” ，“如何实现？” ，“如何保证质量？” 等子问题，而这些子问题又可以进一步细分那么问题被分解清楚了， 任务也就清楚了。

说到任务的粒度，现实中常看到过于粗陋的做法，比如项目任务分配表一般基于功能模块，最多也就划分到子功能 但是如果单单把这个子功能的实现指派给开发人员，你期望能够在任务指派的第二天了解到什么进度呢？任务的粒度要逐步细化， 这是建立细致跟踪的必要条件建议把任务的粒度控制在一天以内1.3. 谁来划分任务 ？任务的细分并不容易， 因为这种细分反应了对求解问题的逐步逻辑分解所以，划分任务的人必须是对任务真正了解的人，强调这一点非常重要我们常见的错误就是认为项目经理既然是一个项目组的头，工作任务理应由他来进行分配和监控但是，实际上，我们看到了这种方式带来问题： “项目经理并不了解项目工作的细节！”，“如果项目经理并不了解工作的细节，那么项目任务又如何能够细分呢？”问题来了，“那么你告诉我谁应该划分任务？” ，我的答案是：设计师、开发人员等等所有做具体活的主角们没有人比设计师更清楚这个系统具体包括哪些功能模块，每个模块又分成了哪些类和类方法，每个方法的难易程度以及需要消耗的工作时间没有人比开发人员更清楚还有多少方法目前没有完全实现，还有多少bug 等待自己去fix ，以及完成这些任务所需要的时间。

OK ，既然他们最清楚， 就理应由他们划分工作任务因为只有符合实际的任务被划分出来了，我们的跟踪和控制才能施加在点子上问题又来了， “要是他们故意简化任务呢？”首先， 要批评这种怀疑团队的成员应该相互信任而不是相互堤防， 这样团队才能齐心协力走向成功其次，我告诉你这也是有方法做到的我们的产品最终要以能够符合需求定义为完成准则，如果以需求定义的清单去检查这些任务的完成，自然就知道每个任务是否在为完成需求定义的产品真正做贡献案例：在 Milkyway 项目中，项目经理 Cobo 决定让设计师和开发人员共同来完成各自的任务列表清单首先是设计师根据需求定义清单列出了自己的设计任务清单，并把该清单给需求人员审核， 以便及时发现是否漏掉了某些工作同样，开发人员在明确自己的工作范围并理解设计后， 也开出了一份任务列表清单， 同样该任务列表也必须通过设计师过目，以便及时发现实现能否覆盖设计 经过上述确认后， Cobo感觉任务列表还是非常明细、丰富而且真实的，即使存在微小的误差，也很容易调整过来1.4. 决定任务的优先级在讨论这个问题前，我给一个实际的案例：案例：测试部昨天给 Jack 提交了 20 个 bug ， Jack 初初看了一下，这些 bug 可以分为三类：第一类是中断性错误，即测试人员在测试中被各种原因所中断，比如抛出异常、无响应，无故退出等等，导致无法继续测试下去。

第二类是接口错误，由于无法正确获得用户的信息，很多模块都无法正常显示表单创建人第三类是程序内部的验证逻辑错误，比如保存时那些非必录项被报告必须录入除了修复 bug ，Jack 今天还打算向负责控件开发的 Daniel 写封电子邮件以明确一个自己的一个新需求因为 Jack 发现自己的用户管理界面左边的那颗用户树可能需要一个通过键盘可以快速定位的功能当然，上周项目例会上项目经理对单元测试进行走查提出的几个代码问题也需要尽快修改，项目经理已经安排了明天进行复查平常 Jack 还是工作蛮高效的，可是现在事情一多， Jack 就不知道自己该优先处理那些任务了其实项目中的任务总会多于你的精力和资源那么怎样完成任务才能把你带向成功呢？的答案就是总是把你手上的任务细分，并排定任务的优先级什么决定任务的优先级 ？在你的手上，可能有很多任务，究竟什么任务是应该优先处理的呢？这是一个普遍的问题这个问题没有标准答案， 但是存在一些判断的原则， 只要你掌握这些原则， 并且真实地用到你的项目中去， 你就会成为一个高效能人人士传统项目管理中经常应用“重要且紧急，重要但不紧急，不重要但紧急，不重要也不紧急” “四象限原则”来指导个人对事情的处理优先判断准则，但是这比较空洞，具体到软件项目任务，可以参照如下一些判断准则：原则 1 ：如果这个任务完成起来非常轻松，所消耗的资源和时间都很少，那么它的优先级要比那些复杂难办的任务要高。

这个原则其实体现了一种“心理战术” ，任务不管大小，完成了总会有或多或少的成就感这就跟考试答题一样，先易后难往往可以在心理上帮助自己逐步取得胜利的信心原则 2 ：如果这个任务的完成可以使一批任务告一段落，从而取得阶段性的成果，那么它的优先级要比其他的高无论是你自己还是你的领导， 都渴望听到成功的消息 优先完成一个任务如果可以把一批任务的状态改为“ OK ”，这将能鼓舞士气对于软件项目，士气无疑是许多事情成功的必要条件原则 3 ：如果这个任务是否能够完成，将直接或者间接影响团队中其他人的任务完成，那么这个任务的优先级要高软件项目的成功必定是整个团队共同努力的成功 优先完成被依赖项， 可以让整个团队并行工作，从而在整体上取得更好的进度原则 4 ：如果你的上司更在意你这个任务的完成，那么这个任务的优先级要高帮助项目成功也要帮助自己成功 而帮助自己成功了， 你的信心、 能力也将必然有助于项目的成功1.5. 对每个任务进行预期和反查任务在分配的同时， 或者稍后一段时间， 应该给出这个任务完成时间的预期对于项目成员来说， 尽管一开始， 要准确预期任务的完成时间非常困难，但是从实践中我们看到，只要整个团队的每个成员都坚持这样做，日久形成了习惯， 那么整个项目的任务看起来将比不这样做明朗许多。

软件开发的最大特点就是非常依赖于成员的工作状态和成员之间的沟通和协调对任务保持预期的习惯， 有利于使整个项目的工作量和工作进度在整个团队保持透明，这是充分调动每个人的积极性，保证整个团队力往一处使的关键谁给任务做预期？我一直相信， 最了解任务的往往是亲历亲为的设计人员和开发人员，那么任务完成的预期也理应由他们自己给出 我坚信在团队内竖立诚信跟做买卖一样重要，尽管 “大胆去相信你的下属吧”，让他们自己决定自己的任务什么时候完成决定好后，你就只管根据他计划的时间来跟踪即可其实你没有理由相信你的下属会故意拖延任务的完成时间 因为聪明的下属往往总想超乎你的预期去完成任务， 以取你的欣赏 只有傻瓜才会故意把自己的任务完成时间做不符合逻辑的拖延让项目成员自己给出任务预期， 体现了领导者的充分信任 这种信任其实会成为一种无形的压力领导都让我自己预期任务什么时候完成了，如果我到时候没有完成，如何解释得过去？”每日 Review通过任务预期， 管理者和下属之间其实达成了某种时间契约 作为下属， 唯一的想法就是按时或者提前完成自己预期的任务对于管理者，也要重视这个契约，需要积极、按时、细致地去 review 任务的完成状况。

敏捷的项目管理由于把任务的粒度细分到天，那么每天都理应对预计完成的任务进行Review Review 的好处是可以以天为单元控制项目进度的误差， 同时让整个团队保持知己知彼的良好沟通状态是不是需要时才做 review 呢？我的建议是最好确定一固定时间来对项目状态进行 Review 固定时间，有利于整个团队形成良好的时间观念，这一点非常重要什么时候 ReviewReview 在什么时候开始呢？这里面也有学问 我的一个同事 Yew 曾经建。