认识达内从这里开始

对于软件开发公司来说，一般都会有好几个开发小组，而这些开发小组之间都会存在着竞争的。而敏捷开发会大大提高竞争力度。今天，我们就一起来了解一下，如何才能更好的制作一个敏捷开发时间表。

软件供应商会根据你的公司情况以及类似公司的软件实施经验，预估软件的实施期限。这时，你可能还不清楚，实施这款软件都需要什么以及哪些是必不可少的。你的预期是，这款软件一定会适合你的业务并且非常容易部署。而且，这款软件必须一次性部署完毕，而不能一点一点地部署。你也许还能够预先进行一些数据转换，但是重要的新功能必须在一个时间点部署完毕，并且部署时间不能超过几周。

高层管理人员通常非常期望通过实施新软件，来利用更好的新功能。他们分析业务需求，从而推算出“上线”的佳时间，然后将这个日期告诉主题和IT部门。但是，通常这些在经过简短的调查之后会回复高层管理人员，这个日期是不可能的。

这些人才更专业，知道必须要做什么。他们是，你不能忽视他们的话。这时，高层管理人员问，“那么，到底都应该做些什么?”们然后会尽力用一种简单明了的方式，在一个比较高的层次解释如何实施这个软件。高层管理人员对于细节不感兴趣，他们需要有一个高层次的理解，即有哪些主要项目活动、每项活动要花费多少时间、谁来做这项活动。

团队通常面临三大挑战：

合理预估必须做什么以及做多久。

建立实施控制，提供反馈，从而满足时间表。

协调软件实施和现有的敏捷实践之间的冲突。

敏捷规划时间表(PALSchedule，即PlannedAgileLeadershipSchedule)可以用每个人都能够理解的方式，清晰地展示高层次的工作分组。

方法论的冲突

在创建敏捷规划时间表的过程中，团队会面临一个挑战。你们已经非常艰难地转向了敏捷流程，但是软件包的部署通常是一个瀑布模型。瀑布模型和敏捷模型有点像油和水的关系，互不相容。你怎样来调和这两种流程模型呢?你想要保持敏捷流程，但是你又有一个指定的上线截止日期。

方法论调和：敏捷模型vs瀑布模型

软件实施团队由负责评估现有功能和新功能的主题、负责基础设施的IT以及某些业务属性所需的各种。这些必须开会决定必须做什么来实施新的软件。将必须做的大型活动分派给每个小组，制定绝对能够完成这些活动的短时间范围。不要担心具体的计划，保持高级别的角度。将这些安排到一个基于高层管理人员指定日期的时间线上。如果你不熟悉IT软件实施，供应商可以帮助识别需要考虑的高级组件。

如何创建敏捷规划时间表：

敏捷规划时间表的英文名字是PALSchedule，即PlanAgileLeadershipSchedule。如何创建这种时间表，以下活动可以说是简单的解释：

在时间表的表头标明月份和星期。

挑选一个日期。

根据这个日期进行倒推。

确定完成计划所需的主要领域/团队。

各个团队用颜色进行标注。

标注关键路径上的主要工作。关键路径通常由功能主题所说的领域组成。

评估每项工作的持续时间。

有些领域可以并行进行，而其它领域则需要按顺序进行。

标注并行工作。这些通常都是数据转换、性能、基础建设、设置和安全所需的活动。

确保将依赖记录和考虑在内。例如，只有基础设施就位才能进行集成测试。

建立里程碑。里程碑通常是下一次主要迭代的终点或开端。

明确每个里程碑的就绪标准和完成标准。这是团队在下一个后续阶段开始之前，如何判断什么必须被完成的方法。这使得目标保持清晰和可测量。

几乎所有工作都是增量迭代的。

将所有精英团队都映射到敏捷规划时间表上。

标注冲刺。

上文定义的时间表“挽具”适用于所有的冲刺。

明确交汇点或者里程碑。

所有团队都可以查看时间表并依据时间表跟踪工作进度。

如果里程碑标准达成，团队对时间表的所有验收就是“可行的”。

清晰可测量的数据应该支持就绪标准的完成情况。

指标要每天发布和评审。

每个团队控制他们各自的流程(冲刺、项目计划、任务活动、测试等等)。充分明确团队的集成时间点，并将时间安排公布给所有的团队成员。时间安排要精确到天和小时。每个人都拥有活动完成的发布权和任务归属的转移权。

警示

敏捷规划时间表是增量迭代的。时间表的每个阶段都是基于前一个阶段构建的。每个过程领域指定的任务都更加困难。

小心80/20原则。不要自以为是地认为你已经完成了大部分工作，实际上你可能只完成了一小部分。后的20%功能验证通常是复杂的功能，比初的80%花费的时间要更长。

尽早实施“快乐路径”。这意味着，你从业务流程的开始推进到新软件的结尾。如果一切正常会怎么样呢?你可以将一个功能从开始推进到结尾，然后投入其它的功能验证工作。

对于非常复杂的功能，仔细写下来，要先写综合测试，再写代码。这也要求你稳定针对测试的数据。这是大部分团队都会犯的比较常见的错误。我过去几乎在每一个项目都听到，“这个方法很难说清...“。口头解释功能如何生效是很常见的。更好的方案是用预期数据建立测试，对测试中的功能执行特定操作并提供预期的结果。这可以在电子表格上高效完成。这种方案有许多好处。大多数时候，不同的主题可能会对系统应该如何工作有不同的期待。商定的电子表格消除了这一误解。如果数据没有稳定，那么数据会影响预期的结果。通过创建数据或者“修复”数据元素为特定的数值，主题和开发人员才会知道这个功能上的数据影响。在数据稳定期间加入额外的元素是非常常见的，因为团队在创建电子表格的时候还不会考虑到这些。当然，这个电子表格也在工具支持的敏捷流程中。

每天公布工具的统计数据。在统计数据中给出有意义的可执行的信息，例如什么完成了，什么没有完成。记住，在这里，低级别的活动连接到敏捷规划时间表。工具应该支持所有这些活动。如果工具中的低级别活动没有完成，敏捷规划时间表就存在风险。好的数据统计通常是可视化的，因此，在数据统计中包含这三种可视化展示(燃尽图、柱状图和饼图)。所有的工具都有使得团队深入这些图标背后具体信息的功能。这使得团队很容易确切知道什么被完成了。

许多工具都有仪表板，团队可以在其中跟踪进度。确保仪表板给出了团队保持跟踪所需的信息。

不要用电子邮件来描述或支持团队活动，例如需求收集、测试或缺陷跟踪。几乎毫无例外，电子邮件是每一个实施团队的祸根。好在项目一开始，就教导团队成员应该怎么写邮件以及邮件应该抄送给谁。团队成员应该在基本的指导方针上达成一致。指导方针应该始终如一地执行。需求应该在你的开发软件中明确规定(而不是在邮件中)。测试应该在测试软件中明确规定(而不是在邮件中)。这些软件通常非常稳健，能够给出非常棒的文档和跟踪记录。它向你给出展示项目状态的统计数据。邮件会从上到下麻痹团队，好少用为妙。

测试软件是必需的。项目状态的测量数据来自这个软件。如果需求、活动、测试等没有在软件中展示，那么它不算必需的软件。你必须寻找能够验证完成情况的指标。软件记录了冲刺活动，记录了测试。当团队演示证明就绪标准的完成指标时，管理人员可以根据敏捷规划时间表查看相关数据。

作者：LeighKoetter

译者：张健欣

来源：infoq

【免责声明】：本内容转载于网络，转载目的在于传递信息。文章内容为作者个人意见，本平台对文中陈述、观点保持中立，不对所包含内容的准确性、可靠性与完整性提供形式地保证。请读者仅作参考。