敏捷开发分享(三)

一 敏捷与禅道

敏捷

一种项目管理风格,这种项目管理的风格专注于商业价值的尽早交付、项目产品和流程的持续改进、
范围的灵活性、团队投入以及能反应客户需求且经过充分测试的产品交付。

禅道

一. 禅道是专业的研发项目管理软件

二. 禅道是灵活的项目管理软件

三. 禅道是有保障的项目管理软件

四. 禅道是敏捷的项目管理软件

 1. 完整支持敏捷方法scrum

 2. 增加测试、文档、发布、计划、待办等功能

 3. 基于敏捷而不限于敏捷，更合适国情

五. 禅道是开源免费的项目管理软件

 1. 基于ZPL协议发布

 2. 源代码开放，不限商用

 3. 强大扩展机制，丰富插件

其他管理工具

1. MyCollab
2. Odoo
3. OpenProject
4. OrangeScrum
5. ]project-open[
6. Taiga
7. Tuleap Open ALM
8. JIRA

二 项目流程

禅道的项目流程

三 相关术语

什么是用户故事

User stories, 用户故事是指一种对某个产品需求的简单描述, 具体来说就是需求是什么, 为谁完成.
你的用户故事至少包括以下内容:

       1. 标题: <用户故事的名称>
       2. 作为: <用户 或 角色>
       3. 我想: <采取这样的行动>
       4. 以便: <我获得这样的益处> 

什么是冲刺

在敏捷项目中, 一个冲刺是指一段确定的迭代时间, 在这段时间内, 开发团队从开始到结束持续创建 特定的一组产品功能. 在每次冲刺结束时, 开发团队创建的产品应该能正常工作并可以进行演示.

1. 一个项目内的所有冲刺应具有相同的时长: 保持冲刺时长一致可以帮你衡量开发团队的表现, 并能更好的计划每次新的冲刺.
2. 每次冲刺包括下列事项:
   a. 在冲刺开始时进行冲刺计划
   b. 每日例会
   c. 开发时间----冲刺主体
   d. 冲刺结束时进行冲刺评审和冲刺回顾
3. 冲刺待办列表, 冲刺待办列表(任务列表)是与当前冲刺和相关任务关联的用户故事清单.
   a. 为你的冲刺设定目标
   b. 选择支持这些目标的用户故事
   c. 将用户故事分解为具体的开发任务
4. 冲刺计划会议 开发团队会在每次冲刺的第一天召开冲刺计划会议, 开发团队成员要确保整个会议过程都能够全身 心的投入.每周冲刺会议不应该超过两个小时.
5. 会议内容
   设定任务目标和选择用户故事
   a. 讨论并设定冲刺目标.
   b. 评审来自产品待办列表中的用于支持冲刺目标的用户故事, 并修订他们的相关估算.
   c. 确定团队在当前的冲刺中可以做出哪些承诺.
   为冲刺待办列表创建任务
   a. 创建与每个用户故事相关联的冲刺待办列表任务.请确保任务围绕着完工定义的每一部分:已开发. 已集成. 已测试. 已归档.
   b. 再次检查确认团队可以在冲刺的可用时间内完成任务.
   c. 每名开发团队成员应该选择他/她的首要任务.

        开发团队成员应该每次只完成一个用户故事的一个任务, 以实现蜂群式协作----整个开发团队为一个需求持续工作直到完成. 蜂群式协作式在段时间内完成工作的非常有效的方法.

        实际上会议的第二部分主要是将故事分解成单独的任务, 并个每个任务分配数小时的时间. 开发团队的目标应当是在不超过一天的时间内完成任务.

四 敏捷团队的一天

跟踪进展

       禅道中的冲刺任务列表,任务看板和燃尽图是跟踪进展的两个工具, 通过他们可以让团队能在任何时间对任何人展示冲刺进展.

1. 冲刺任务列表:
          在冲刺计划阶段,工作重点是把用户故事和任务加到待办列表中.而冲刺阶段则每天要更新 冲刺待办列表并跟踪开开发团队的任务进展.

2. 任务看板:
           任务看板可以快速便捷的展示当前冲刺过程中开发团队正在做的和已经完成的任务.
   禅道的任务看板包括:
   a. 未开始: 任务中剩下的需要完成的任务或bug.

   b. 进行中: 开发团队正在开发的任务或者正在解决的bug.进行中的任务原则上一个开发团队 成员只有一个进行中的任务或bug.如果有多个,那就意味着要么团队成员没有及时更新任务状态,要 么就是团队成员正在囤积他们想要做的任务.无论哪种方式都不是我们想要的结果.这样的话,在冲刺结束的时候很可能会出现很多完成一半的任务, 而不是更多的100%完工.

   c.已暂停: 当有多个任务(bug)指派到你的时候, 你可以选择按优先级暂停任务(bug)或者寻求 他人的帮助.(时刻记得我们是一个团队,我们要一起完成这个冲刺)

   d. 已完成: 当任务测试没有问题或者bug解决后,测试人员要将这个任务或bug的状态更新到已 完成的状态.

   e. 已取消: 产品负责人随时可以根据实际情况将当前的任务取消.

   f. 已关闭: 产品负责人对已完成的故事进行审核, 并确认它已经完成后, 会将这个任务关闭.

       开发团队的成员应该学会控制你进行中的任务数量, 把其他任务留在待办列表中. 理想状态下开发团队成员一次只开始一个任务, 全力投入在这个任务上,并尽快完成它.

3. 燃尽图
          通过禅道中自动生成的燃尽图能让所有人一眼就看出冲刺的状态, 进展情况非常的清楚. 通过比较可用的小时数和实际的剩余工作, 可以随时看出工作是否按计划进行,状态是否良好.以下是在冲刺中不同情况的冲刺中的燃尽图的状态:
   a. 符合预期

          该图展示了一个正常冲刺的状况. 随着开发团队完成任务, 深挖出一些细节或者发现一些开始没有考虑到的工作,
          剩余工作小时数会相应增减.尽管剩余工作量偶尔会增加, 但基本是可控的, 团队会全力以赴在冲刺结束前完成所有用户故事及任务.
   
   b. 较复杂

          在这种冲刺里, 实际的工作量增长到开发团队认为不可能全部完成. 团队能够在冲刺早期发现这个状况, 并与产品负责人协商从冲刺中移除部分任务, 从而仍然可以完成冲刺目标.
   
   c.较简单

          在这种冲刺中, 开发团队提前完成了一些关键的任务并与产品负责人协商为冲刺加入新的任务.
   
   d.无参与
          燃尽图里有一条直线意味着团队要么没有更新燃尽图, 要么当天没有任何进展. 不管是哪种情况, 都预示着将来可能会出问题.就像心电图, 冲刺燃尽图中出现一条水平直线绝对不都会是好事.
   
   e. 假象
          这种燃尽图模式在新的敏捷团队中很常见, 团队成员在更新任务时会把对工作用时的估算修改和剩余的可用时间一样,而不是真正的工作用时.
   
   f. 快速失败
   

冲刺中的敏捷角色

产品负责人:

Scrum主管:

Scrum团队成员:

1. 选择需求最高的任务并尽快完成
2. 对某个用户故事或任务不清楚的时候, 要尽快要求产品负责人澄清.
3. 跟开发团队成员合作设计某个特定的用户故事或任务, 如有需要则寻求他人帮助,其他成员需要的时候,你也要帮助他们. 4. 组织同行评审彼此的工作.
4. 根据冲刺需要接受你正常角色意外的任务.
5. 根据确认完工定义,开发出完整的功能.
6. 每天报告你的进展.
7. 提前预想工作中可能存在的障碍.
8. 记录你所遇到的问题和对团队开发有帮助的想法.
9. 完成你在冲刺计划时承诺的冲刺目标.

创建可交付功能

冲刺中日常工作的目标是以可交付的形式创建产品的可交付功能.
为了创建可交付功能, 开发团队和产品负责人需要参与以下三种主要的活动.
这三种活动可以随时发生,他们之间没有严格的顺序

细化: 在敏捷项目中, 细化是确定一个产品特性细节的过程.

开发:

1. 遵循开发团队商定好的设计标准.

2. 在开发前建立自动化测试.

3. 如果在开发过程中出现新的,可有可无的功能需求,把他们加到产品待办列表中.避免开发这次冲刺之外的新功能.

4. 集成当天完成的编码变更, 对已完成编码的变更进行测试.以保证变更100%的正确.

5. 进行代码评审以保证遵循代码开发标准. 识别需要修正的地方, 把这些修正作为任务加入到冲刺待办列表中.

6. 在工作进行中同步创建技术文档,不要等到当前冲刺结束,甚至发布前的那次冲刺结束才写文档.

   持续集成是指在软件开发中对每一次代码构建都做集成和全面的测试.
   持续集成可以帮助识别能够引发灾难性的一些问题.

验证:

1. 自动化测试
          自动化测试是指用计算机程序来为你的代码做大部分的测试. 有了自动化测试, 开发团队可以快速开发并测试代码, 这对敏捷项目是一个非常大的好处.通常敏捷项目团队白天编码, 晚上执行自动化测试. 早上项目团队可以评审测试程序生成的错误报告, 在每日例会中报告发现的问题并在白天的工作中立即修正哪些问题.自动化测试可以包括但不限于: 单元测试. 系统测试. 静态测试

2. 同行评审
          同行评审就是指开发团队成员评审其他人的代码. 如果 小明 写了程序A, 小红 写了程序B, 那么小明可以评审程序B, 小红可以评审程序A, 反之亦然. 客观的同行评审有助于确保代码的质量.

3. 产品负责人评审
          当任务在完成状态时, 产品负责人应该通过执行一些检查来验证用户故事或具体任务是否符合完工定义, 当用户故事符合完工定义的时候, 产品负责人应该讲该故事或任务关闭.

结束一天的工作

       每天结束工作的时候, 开发团队应该用过更新冲刺任务列表来报告任务进展----哪些任务完成了,
新开始的任务还剩多少小时的工作量.

       要根据整在进行中的任务的剩余工作量来更新冲刺待办列表. 更新的状态应该实事求是, 不要花
时间跟踪已经用了多少小时在什么任务上. 跟踪已用时间经常用来检测最初的预测是否准确, 而
这在可以自我修正的敏捷模型中是没有必要的.

       Scrum团队每天按照这样的周期进行工作, 直到冲刺结束, 然后就要进行冲刺评审和冲刺回顾了.

五 展示工作和集成反馈

冲刺评审

       冲刺评审是在冲刺中展示展示并评审开发团队完成的用户故事的一个会议.

准备演示

       冲刺评审这个名词听上去可能很正式, 但本质上敏捷中的展示是非正式的.冲刺评审展示的准备工作应该很快, 最多几 分钟. 会议需要准备组织, 但不需要很多华丽的包装

        开发团队在冲刺评审中演示的代码必须是符合完工定义的, 这意味着代码必须是经过充分的 开发, 测试, 集成, 归档.

冲刺评审会议

        冲刺评审会议中有两项内容:

1. 展示Scrum团队已完成的工作.
2. 收集干系人对这些工作的反馈意见.

       关于收集反馈在整个项目周期中随时都应该进行,在整个项目周期中应该按以下方式不断重复:

1. 每天, 开发团队成员在高度协作的环境中一起工作, 这种环境有利于通过同行评审和非正式的沟通来进行反馈.

2. 整个冲刺过程中, 每当开发团队完成一项需求, 产品负责人会评审可工作的功能是否可接受, 并提出反馈意见.

3. 冲刺结束时, 项目干系人在冲刺评审会议中对完成的功能提出反馈意见.
   每个冲刺结束时,应该对这个冲刺中的所有反馈进行归纳存档.

4. 对每次发布, 使用该产品的客户会针对新增的可用功能提出反馈意见.

       Scrum的规则之一是冲刺中每周用于评审会议的时间不能够超过一个小时

冲刺回顾

冲刺回顾是一项会议, 在该会议上Sccrum主管, 产品负责人, 其他干系人都可以一起与开发团队讨论当前冲刺的进行状况和如何在下一个冲刺中改进.

计划回顾

       每位Scrum团队成员都应该思考一些关键问题并且做好针对这些问题进行讨论的准备. 冲刺中哪些事项做的比较好? 哪些
需要改变,如何进行改变?

冲刺回顾会议

1. 冲刺回顾会议室一个以行动为导向的会议, Scrum团队会在下次冲刺中立即应用在回顾中学到的东西.

2. 冲刺回顾会议不是一个辩证会议, 如果你听到诸如 “因为”, 之类的词, 我们很可能是跑题了.

3. 冲刺回顾会议应包含: 冲刺中哪些任务进行的比较好? 我们想做什么改变? 我们如何实施这些改变?

开放讨论的话题

1. 成果: 比较计划的工作量和开放实际完成的工作量. 评审冲刺燃尽图.
2. 人员: 讨论团队构成和团队意识.
3. 关系: 讨论交流. 合作意识.
4. 流程: 仔细检查这些流程----寻求支持, 开发和代码评审
5. 工具: 不同的工具是怎样为Scrum团队工作的(工具是为了提高效率)
6. 生产力: 团队怎样才能提高生产力并在下个冲刺中完成更多的工作.

       以上讨论的话题可以不必全部进行, 每次可以准备一到两个话题进行讨论, 但是一定要有结果. 确保从冲刺回顾中得出的结论在整个项目过程中被用以检查并调整当前的项目状态.

检查与调整

       冲刺回顾是把你检查与调整的想法付诸实施的最佳时机之一. 在回顾中, 你会碰到一些挑战并想到一些解决方案, 会后不要把这些方案束之高阁, 而是要把改进作为你每天工作的一部分.所有的改进方案我们应该整理并放到禅道上的公共区域, 以保证每位成员都能够随时的去查阅.在后续的回顾会议上, 一定要对之前的改进方案进行评审, 并确保把改进方案落到实处.

**敏捷方法可以快速的发现项目中的问题, 所有的这些工具和实践都能够帮助开发团队 发现影响效率的因素并加以改善, 从而使开发团队在每次冲刺中都有所进步.**