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

第二部分 做最细致的项目跟踪 项目计划告诉了我们要如何去完成项目，但是项目计划的执行并非总能够沿着预定的轨 道前进。可以肯定地说，如果没有健全的反馈机制，计划的执行定然会偏离预定的轨道，而 唯一能够确避免的措施就——追求项目计划执行屮最细致的项目跟踪,在计划的执行稍有偏 离的时候就 纠正其方向，这在控制理论小，就是基于反馈的控制。 宏观上来说，重型项冃管理方法往往倾向于花更多的时间來作一个细致的项冃计划，以 确保后期计划执行的可控。但是，细致的计划并不能替代细致的跟踪。 1?1?细化任务 现代控制理论告诉我们，控制的楮确程度是建立在被控制量量化的粒度之上。量化得越 细，就能够控制得越精确。因为在很少偏移量的时候这种趋势就得以纠正。但是量化并非没 有代价，过细的量化会增加成木，所以这之间存在一个权衡。 敏捷的项目管理要能做到随机应变，应付各种可能出现的情况，也是建立在对任务的细 分，并对任务的状态采収高频度的探测并及时调整的基础上。那么任务究竟要细分到什么程 度呢？这并没有确定的度量。不同规模的项冃可能都存在不同，但是我的经验告诉你，如果 可以的话，让你的任务的工作量尽可能控制在一天以内。 1.2.控制任务的粒度 项目计划的失控往往都是由于项目任务划分不够清晰，粒度过人引起的，我想这是我和 很多软件从业者的深刻体会。 当然，一个常见的反驳意见是“不是我们不想细化任务，而是项冃刚开始，很多东西都 很模糊，无法把任务划分得很细”。其实这句话中存在两点误解，我想从止面來说明： 第一，任务划分与产品的解析度是无关的。 这里，我杜撰了一个词语“产品的解析度”，用来表达对产品的了解程度。的确，我们 对一个产品了解得越多、越细，就越可以把如何完成这个产品的工作任务划分得更加楮细。 但是反过來，即使一个产品初期对我们來说是模糊的，难道我们的任务就不可以划分得很细 吗？其实照样可以。产品从模糊到清晰的过程也是问题分解的过程，每个人问题都可以分解 为许多子问题，而对于每一个子问题，其实完全可以对应到相应的子任务。即使我们以“盲 人摸象”为比喻，要搞清楚人象是什么，也总可以分解为按照头部，身体，四肢，尾巴几 个部分分别摸來细分任务。 第二，任务划分包含解决问题的思路 所谓任务，都是为了解决某个具体问题，而如何解决这个问题，从逻辑上我们首先需耍 把问题分解。问题分解的过程就可以对应到任务划分的过程。比如：如何完成项目目标这个 大问题就可以分解为“如何完成需求定义？ ”，“如何完成系统设计？ ”，“如何实现？ ”，“如 何保证质量？ ”等子问题，而这些子问题又可以进一步细分。那么问题被分解清楚了，任务 也就清楚了。 说到任务的粒度，现实中常看到过于粗陋的做法，比如项冃任务分配表一般基于功能模块, 最多也就划分到了功能。但是如果单单把这个了功能的实现指派给开发人员，你期望能够在 任务指派的第二天了解到什么进度呢？ 任务的粒度要逐步细化，这是建立细致跟踪的必要条件。建议把任务的粒度控制在一天 以内。 13.谁来划分任务？ 任务的细分并不容易，因为这种细分反应了对求解问题的逐步逻辑分解。所以，划分任 务的人必须是对任务真正了解的人，强调这一点非常重要。 我们常见的错误就是认为项冃经理既然是一个项冃组的头，工作任务理应由他来进行分 配和监控。但是，实际上，我们看到了这种方式带来问题：“项bl经理并不了解项目T作的 细节！”，“如果项目经理并不了解工作的细节，那么项目任务乂如何能够细分呢？ ”。 问题来了，“那么你告诉我谁应该划分任务？ ”，我的答案是：设计师、开发人员等等所 冇做具体活的主角们。 没有人比设计师更清址这个系统貝体包括哪些功能模块，每个模块乂分成了哪些类和类 方法，每个方法的难易程度以及需要消耗的工作时间。没有人比开发人员更清舱还有多少方 法目前没有完全实现，还有多少bug等待自己去fix,以及完成这些任务所需要的时间。OK, 既然他们最清楚，就理应由他们划分工作任务。因为只有符合实际的任务被划分出來了，我 们的跟踪和控制才能施加在点子上。 问题乂來了，“要是他们故意简化任务呢？ ”。首先，要批评这种怀疑。团队的成员应该 相互信任而不是相互堤防，这样团队才能齐心协力走向成功。其次，我告诉你这也是有方法 做到的。我们的产品最终要以能够符合需求定义为完成准则，如果以盂求定义的清单去检查 这些任务的完成，自然就知道每个任务是否在为完成需求定义的产品真止做贡献。 案例： 在Milkyway项口屮，项目经理Cobo决定讣设计师和开发人员共同来完成各自的任务 列表清单。首先是设计师根据需求定义清单列岀了自己的设计任务清单，并把该清单给需求 人员审核，以便及时发现是否漏掉了某些工作。同样，开发人员在明确自己的工作范围并理 解设计后，也开出了一份任务列表清单，同