"把工作分解成小的任务，精确地将要点分配到这些任务中，追踪完成时间，查漏补缺，避免损害团队成员之间信任的行为，这些有可能建造一个精确的项目估计的文化。"
有效的项目估计是软件工程师们在工作中遇到的最严峻的挑战之一。不管团队大小，干脆利索地定义、估计和分配团队工作是很重要的事情。当团队变得越来越大，养成良好的计划和估计工作习惯就更加重要。缺乏规划和估计工作会降低一个项目的信心，破坏团队成员和业务之间的关系，从而使得开发对每个人来说都更难。在本文中，我提供了可以使估计工作更简单的技能，给出怎样在这些估计工作中建立团队成员之间的信任的方法。
我们从定义一个工作单元开始。敏捷团队使用像叙事诗和用户故事这样的词语，而传统的团队可能使用任务或性能这样的字眼，而所有的软件团队成员使用缺陷这个词！我要将工作定义为一个变化，一个需要一个或更多人来做出努力的当前状态中的变化。已定义的工作大概也包括清晰的成功度量，所以团队成员知道什么时候工作算完成了。
从产品路线图开始
每个团队都需要建造一个路线图。对开发团队来说，了解代码库将怎样随着时间的推移而演化至关重要。路线图很可能会有四到六个大的启动项。每个启动项内部会有几个大的性能组成。每个性能又可能有多个组件。而为工作交付，每个组件需要一组任务和一组用户故事。
将每个组件分成8到16个的系列任务很重要。最有效的估计过程需要整个团队参与。作为团队计划，有关个体工作流如何融合到一起的疑问将会跳出来。这是一件好事。这些问题驱使有更多关于项目的根本性的谈话和最小化惊讶之事的发生。如果一个团队新进到一起估计工作中，至少要从产品所有者，Scrum专家和开发团队人员（包括开发和测试工程师）开始。
你大概会想："我不可能对我整个路线路做那么详细的估计！"说得对。你不应该那么做。只对功能管线上最初的几个项做详细的估计。一旦团队成员了解了发布最初的几个项所需要的努力，就会对预测备份日志里工作范围有更深的帮助。这突出了一个重要的原则：估计工作的准确性随着工作范围的增大而降低。
......
估计工作是自我证明的
在软件团队中，关于估计工作的恐惧有很多在"长腿"。我们都经历过像这样宣言的项目，"这个功能点将在三个月内完成"，真正的含义是"全身投入到开发这个功能中，不管多少成本就要在三个月内完成"。这给失败和错过最后期限创造了潜在可能。当将推迟日程表上的日程有舒适可循，它就限制了商业随着项目不断演化做出正确决定的能力。
"把工作分解成小的任务，精确地将要点分配到这些任务中，追踪完成时间，查漏补缺，避免损害团队成员之间信任的行为，这些有可能建造一个精确的项目估计的文化。"
敏捷组织机构的重要特征是其导航和在改变中推进的能力。估计工作会转变。重要的是，关注待办事项上的开发团队和业务团队。产品拥有者负责最大化开发团队人员的价值。开发团队的估计帮助产品拥有者决定工作成本，对产品发布工作做优先级。
开发团队最具战略性的关系是与产品拥有者的关系。当开发团队成员对项目工作做了更好的估计，产品拥有者才可以更精确地计划产品的路线图。结果，产品拥有者也不会去参与诸如可以给开发团队增加内容转换和逆行功能的中途冲刺的反模式活动中。
信任为何是根本的粘合剂
软件开发工作的估计没有组织内的信任是不可能有效的。从工程师到财务到市场营销，我们因为专业人员的技能雇佣了不同的接受过训练的人。保持像一个团队工作，建立成员间的信任很重要，只有这样才能开发出最好的产品和项目成果。
不幸的是，下面这种类型的对话经常出现：
"发布性能X要多长时间？"
"我们认为要三个月"
"我需要它两个月之内完成。想办法做到。"
"呃……"
如果项目范围不做改变来适应新的发布日期，开发团队会认识到估计工作没什么关系。工程师感到非常有压力，要走捷径去影响产品质量。信任坍塌，项目可能在还未真正开始之前就崩溃了。每个人都受苦。
现实是有时候产品的确需要有一个交付日期底线。下面是一些帮助促进有效率的谈话的问题：
o这个启动项最重要的一部分是什么？（"所有的"不是一个真正的答案。）
o有没有能解构和在团队内平行工作的方法？
o我们怎样能在开发循环早些时候得到反馈来确保我们有对的最不可行的产品？
在少数案例中，一些特别的工作流不得不赶快做完。产品拥有者和业务领导可以推动团队成员多增加工作时间---但是要意识到耗尽精力长期上会降低产品质量，这个很重要。
授权给产品拥有者去关注正确项上的施工时间可以让每个人从瀑布式开发的挑战中得到解放。团队是受制于范围而不是时间。工程施工能力是一个固定的实体，这个实体可以为产品拥有者使用来发布产品。
......
版权声明：51Testing软件测试网及相关内容提供者拥有51testing.com内容的全部版权，未经明确的书面许可，任何人或单位不得对本网站内容复制、转载或进行镜像，否则将追究法律责任。
