冲刺(Sprint)期间要做什么

开始冲刺

一旦您已经完善了积压列表, 设置里程碑(Milestone), 并且树立一个冲刺目标, 恭喜您已经准备好开始冲刺了！

开始之后, 一切都是为了要保持项目进行. 以下是为保持一切顺畅需要做的事情.

开发冲刺的日常工作

在冲刺过程中, 任务面板是一切工作的中心. 使用标签和管道, 随着工作的推进将Issue拖动并投放到正确的位置.

如果您已经设置一个能够反映您的团队真实工作情况的任务面板, 那么它们应该确切的描述出工作目前的进展. 这部分说明了为什么每一个参与项目的人都得使用面板是如此重要的.

我们得强调, 很多团队并不习惯这种程度的个人自主. 起初可能会觉得不自然. 许多开发人员习惯于被告知要做什么, 许多管理者习惯于掌控项目管理流程的每个部分.

这并不是因为管理者糟糕或者开发人员懒惰, 这是因为大多数的项目管理工作流程和工具都偏离了真实的工作(代码)，这让我们有理由期待开发人员很大程度上参与. 这就是我们构建ZenHub的原因. 如果您的团队不习惯这个系统 - 或者他们没有效率地使用这个系统 - 把所有人聚集在一起, 正式向他们介绍这个全新的工作方式.

每个人积极使用面板, 您的开发人员将能够在更短的时间内完成更多任务. 项目主管会花更少的时间追着大家了解更新情况. 每个人都受益！

每日立会

每天, ZenHub团队进行一个短立会, 我们很快的汇报一下我们昨天的工作, 今天要做什么, 以及阻碍和困难. 在早上进行(经常端着一杯咖啡)，我们每个人, 包括销售, 设计, 还有市场都参加会议，有助于早早的为一天做好准备.

这不仅是一个共享信息以及发现阻碍的方式, 现场站会也非常有价值, 会议中要求大家公开承诺: 你非常明确的宣布将要交付什么. 这让每个人都为自己这一天负有责任.

要小心每日立会的两个常见错误. 一: 我们很容易花太多时间讨论我们的工作, 而对于我们的阻碍谈论的不够. 提及自己的阻碍是对队友的慷慨行为.

二: 立会经常转变成技术讨论. 它们理应很短, 所以如果您开始讨论些什么, 将这件事放入GitHub issue，开始一天的工作.

了解自己: 使用燃尽图

燃尽图显示您完成的工作(关闭的Issue)与预计速度(之前认为能够完成的工作量)之间的关系. 虽然它们经常与Scrum有关 - 一种包含频繁发布, 渐进式发展, 并且专注于客户需求的敏捷方*论法** - 它们对于任何团队来说都是一个很方便的小工具.

在冲刺期间, 每天查看燃尽图, 看工作是否在按计划进行. 它是关注范围的绝佳办法. 如果您发现自己高估了能完成的工作, 别担心 - 这是一个很常见的失误. 只需停止开始新的Issue, 并专注于完成(至少)现有的几个.

作为项目进展的早期指标, 燃尽图可以帮助团队在期限内完成工作并跟踪他们的速度. 由于它可以展示完成的和未完成的工作, 因此是一个方便用户使用的报告工具 - 能够最快回答问题:"项目进展如何?".

以下是付费内容

增建您的燃尽图

在ZenHub里, 每一个Milestone(sprint)都有自己的燃尽图. 要'构建'燃尽图的x轴, 选择Milestone的起止日期.

当带有估算的Issue被添加到Milestone里时, 它们会显示在这个Milestone的燃尽图上. Issue关闭后会出现一个新的数据点. 如果您的团队完成的工作和对角线时间线很接近的话, 就可以自信的认为您能实现您的目标.

注意: 在ZenHub里, 您可以自定义哪个管道转化为图表上的新数据点.

完成就真的完成了？也许吧.

当您问团队中十个不同的成员"一个Issue怎样算完成?", 很有可能会得到十个不同的答案.

质量保障人员说测试完了算完成.

开发人员说当拉取请求被合并到过渡阶段(staging)算完成.

CEO会认为到了用户手中算完成.

确立一个团队中每个人都理解并认同的"完成"定义是非常关键的.

冲刺过程中的测试和质量保障

如果一个功能没有被测试就不能算 "完成". 因此, 测试是冲刺中的一个持续的过程.

我们坚持要把任务分解成小块儿是有原因的. 越早完成一个Issue, 测试过程就会越早开始. 开始测试的时间与冲刺的开始时间越近, 您最终就更有可能交付有价值的代码.

我们建议添加一个"可进行QA"管道以保持Issue可见并持续向前发展. 或者, 使用被阻止(Blocked by) 或可进行测试(Ready for testing) 标签来让其他的团队成员知道他们可以在哪方面提供帮助.

拉取请求(Pull Request)和代码审核(Code Review)

GitHub用拉去请求来告诉您的团队您正在要求一次代码合并. 其他成员可以审核提议的代码, 讨论不同的解决办法, 添加后续更改.

"代码审核对于可读并可维护的代码来说是必要的...它对于编程的意义和编辑(editing)对于写作的意义是一样的,"Trey Hunner(Python 软件基金会的主管，也是Python每周谈(Weekly Python Chat)的主持人)说, "您可以审核自己的代码, 但是让其他人参与进来通常更有成效."

我们坚持一定要让其他人来审核您的代码. 我们将拉取请求看做是学习的机会. 事实上, 从我们的开发人员入职便将拉取请求作为基石，新的团队成员在第一天就能推出有价值的代码.

要做到这一点, 对"良好的"拉取请求有一些标准化会非常有帮助.

像Issue一样, 您可以设置拉取请求模版, 以下是一个范例:

(我们包含了一个客户评论区, 这样我们就能够记得回送到最初请求这个功能或提交这个Bug的用户了.)

一个好的拉取请求里还要有什么?

• 一定 要创建"单一职责"拉取请求, 每次只更改一件事情. 一个"妄想改变一切"的拉取请求是最没有帮助的.
• 一定 鼓励您的团队添加一个标题来描述合并之后会产生什么结果.
• 一定 充分利用@-mention 标注团队成员, 提示他们具体哪些部分需要特别的关注.
• 并且用任何办法, 一定要在审核别人的拉取请求时对它们的优点做出评论.

在冲刺结束时, 开放的拉取请求应该被合并, 关闭或者移到下一个Milestone. 如果能将拉取请求作为建设性的对话和表扬的中心, 它将是让您的工程团队成员成为良师益友的强大力量.