[原创] 敏捷软件开发管理实践 (二) ——做最细致的项目跟踪

作者: cloudward
注: 本文属于原创, 任何使用必须经过本人同意方可.

做最细致的项目跟踪

项目计划告诉了我们要如何去完成项目，但是项目计划的执行并非总能够沿着预定的轨道前进。可以肯定地说，如果没有健全的反馈机制，计划的执行定然会偏离预定的轨道，而唯一能够确避免的措施就——追求项目计划执行中最细致的项目跟踪，在计划的执行稍有偏离的时候就纠正其方向，这在控制理论中，就是基于反馈的控制。

 

宏观上来说，重型项目管理方法往往倾向于花更多的时间来作一个细致的项目计划，以确保后期计划执行的可控。但是，细致的计划并不能替代细致的跟踪。

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。固定时间，有利于整个团队形成良好的时间观念，这一点非常重要。

       什么时候Review

       Review在什么时候开始呢？这里面也有学问。我的一个同事Yew曾经建议安排在每天早上上班后半小时，并给出了下面的原因：

1.         促使项目成员不迟到

2.         让项目成员在一天的开始即进入紧张的工作状态

3.         强调每个人当前的任务，帮助项目成员明确当天工作目标

4.         给项目成员预留了晚上作为按时完成任务的Buffer

       每日晨会

       一个非常有效的Review制度就是每日晨会。在每日晨会上，项目各成员可以汇报自己的项目进度，工作中所遇到的问题、需要协调的事项等，而项目经理可以检查工作进展，布

置新的工作任务和传达上面新的指示和动态。作为一个团队，让每个成员对项目达成一致的认识，尤其是风险认识是极其必要的。

       晨会的技巧

       我想不会有人怀疑晨会带来的好处，但是会有很多人怀疑这样做是否太浪费时间，得不偿失。这里就涉及到一个晨会的技巧。

首先，我们要认识到晨会的目标是什么？晨会的目标应该是了解昨天的状态和布置今天的任务。记住“昨天”和“今天”两个时间范围。既然我们每天都安排晨会，其目的就是要达到今日事今日毕，不要把任务拖到明天以后。在每日召开的晨会上，我一听到成员谈论非昨天和今天的事情，我就立即让他们打住，“请大家不要越界！”

晨会的时间要尽可能短，这样它的“得”就大于“失”。如何控制晨会的时间呢？这里有几个启发性的意见与大家分享：

1.         让每个人树立时间观念，晨会不迟到，讲话不拖沓，简明扼要。

2.         让每个人在进度汇报上采取一致的方法，比如汇报表格，纸条等。

3.         把晨会的例程固定化，并限定讨论的范围。

4.         严禁讨论具体的技术问题和管理问题

5.         如果可以，请大家都站立发言

6.         让承担独立性任务最强的人优先发言，发言完后即可离开

7.         围绕1，让每个人轮流做组织者，学会控制晨会的时间

让项目成员更有责任感

晨会中最容易出现的就是项目成员任务没完成，在晨会努力为自己寻找各种借口。“我的任务基本完成了，但是还有一个问题没解决”；“我本来可以完成，但是碰巧某某不在，没有他协助所以我没能解决它”；“昨天事情很多，没来得及完成这个任务”。各种借口不一而足。更加可怕的是，项目成员有时候会谎报军情，本来没有完成的任务，谎报自己完成了或者含含糊糊不给你明确的状态。如何解决这样的问题呢？我想这是摆在每个项目经理难题。这里作者也有一点经验与大家分享。

1.         约定汇报的任务只有“完成”，“未完成”两种状态。即使你的任务数量上完成了“99%”也属于“未完成”状态。

2.         如果任务没有完成，要给出合理的解释。请不要告诉我大堆的各种原委，你的解释要求非常简洁。只要在下面的分类中打个勾：

【】客观原因

              【】个人原因

                     【】身体原因

                     【】技术原因

                     【】主观原因

              而上面只有非主观原因是可以接受的。累计这些“延迟事件”，作为对个人的工作考核

3.         每个任务的完成在列表上要标记＂ＯＫ＂，告诉你的成员,你最不希望看到一个任务从“OK”回退到“不OK”。

假如任务延迟不可避免，项目经理要帮助成员明白对团队的影响，在对项目成员形成一定的心理压力的同时，可以指出其处理方法上的不当之处，启发他是否可以做得更好，从而帮助项目成员逐步走向成熟。 <script src="http://pagead2.googlesyndication.com/pagead/show_ads.js" type=text/javascript> </script>