2015-05-10 17:30:54 yingrenzhe68 阅读数 49
  • 敏捷开发——SCRUM

    SCRUM是当前较火的一种敏捷开发方法,有用户故事、冲刺、燃尽图等很多很酷的玩法,有牛B的产品负责人、SCRUM Master,有很强的自组织团队。

    13678 人正在学习 去看看 张传波

  最近把之前学习 Scrum 的资料整理为一篇文档,在接下来的团队和项目开发中,根据项目的情况引入 Scrum 的一些实践,提高团队成员之间的协作能力和项目的交付质量。

        参考资料:

        Scrum 工具

        Scrum 中的角色

        Scrum Master——项目负责人、项目经理

        保护团队不受外界干扰,是团队的领导和推进者,负责提升 Scrum 团队的工作效率,控制 Scrum 中的“检视和适应”周期过程。与 Product Owner 一起将投资产出最大化,他确保所有的利益相关者都可以理解敏捷和尊重敏捷的理念。

        Team——开发人员、测试人员、美工设计、DBA等全职能性团队

        团队负责交付产品并对其质量负责,团队与所有提出产品需求的人一起工作,包括客户和最终用户,并共同创建 Product Backlog 。团队按照大家的共识来创建功能设计、测试 Backlog 条目交付产品。

        Product Owner——产品负责人、产品经理、运营人员

        从业务角度驱动项目,传播产品的明确愿景,并定义其主要特性。Product Owner 的主要职责是确保团队只开发对于组织最重要的 Backlog 条目,在 Sprint 中帮助团队完成自己的工作,不干扰团队成员,并迅速提供团队需要的所有信息。

        User——最终用户、运营人员、系统使用人员

        很多人都可能成为最终用户,比如市场部人员、真正的最终用户、最好的领域专家,也可能是因其专业知识而被雇佣的资讯顾问。最终用户会根据自己的业务知识定义产品,并告知团队自己的期望,提出请求。

        Manager——管理层、投资人

        管理层要为 Scrum 团队搭建良好的环境,以确保团队能够出色工作,必要的时候,他们也会与 Scrum Master 一起重新组织结构和指导原则。

        Customer——客户、系统使用人员、运营人员

        客户是为 Scrum 团队提出产品需求的人,她会与组织签订合同,以开发产品。一般来说,这些人是组织中的高级管理人员,负责从外部软件开发公司购买软件开发能力。在为内部产品的公司中,负责批准项目预算的人就是客户。

        Scrum 中的产出物

        Product Backlog——Backlog 待开发项,积压的任务。

        产品 Backlog 包括了所有需要交付的内容,其内容根据业务需求的价值顺序排列,每个 Backlog 的优先级是可以调整的,需求是可以增减的,因此产品 Backlog 将根据不断增长来持续驱动维护。

        Sprint Backlog——Sprint 本意为“冲刺”,指迭代周期,长度通常是一至六周。

        在 Sprint 开始前,定义本次 Sprint 要讨论的“Sprint Backlog”,从中产生本次 Sprint 要完成的 “已定 Product Backlog”。

        已定 Product Backlog

        Sprint 计划会议的产物,它定义了团队所接受的工作量,在整个 Sprint 过程中它将保持不变。

        User Story、Task——用户故事、任务

        用 User Story 来描述 Sprint Backlog 里的项目,User Story 是从用户的角度对系统的某个功能模块所作的简短描述。一个 User Story 描述了项目中的一个小功能,以及这个功能完成之后将会产生什么效果,或者说能为客户创造什么价值。一个 User Story 的大小和复杂度应该以能在一个 Sprint 中完成为宜。如果 User Story 太大,可能会导致对它的开发横跨几个 Sprint,此时就应该将这个 User Story 分解。

        为了能够及时,高效地完成每个 Story,Scrum 团队会把每个 Story 分解成若干个 Task。每个Task 的时间最好不要超过8小时,保证在1个工作日内完成,如果 Task 的时间超过了8个小时,就说明Task的划分有问题,需要特别注意。

        障碍 Backlog——问题列表,积压的待处理事务。

        列举了所有团队内部和团队相关的和阻碍项目的进度的问题,Scrum Master 需要确保所有的障碍 Backlog 中的问题都已分配并可以得到解决。

        通用会议规则

        基本要求

  • 每次会议都要准时开始、准时结束。
  • 每次会议都采取开放形式,所有人都可以参加。

        会前准备

  • 提前邀请所有必须参会的人,让他们有时间准备。
  • 发送带有会议目标和意图的会议纲要。
  • 预订会议所需的全部资源:房间、投影仪、挂图、主持设备,以及此会议需要的其他东西。
  • 会前24小时发送提醒。
  • 准备带有会议规则的挂图。

        会议推进

  • 展开讨论时,会议的推进人必须在场。他不能参与到具体讨论中,但是他需要注意讨论进程,如果讨论参与者失去重点,他还要将讨论带回正规。
  • 推进人展示会议的目标和意图。
  • 有必要时,推进人可以商定由某个撰写会议记录。
  • 推进人可以记录团队的意见,或是教授团队如何自己记录文档;而且推进人可能会在挂图上进行记录,将对话可视化。
  • 推进人会对会议进行收尾,并进行非常简短的回顾。

        会议输出

  • 使用手写或挂图说明来记录文档,给白板和挂图上的内容拍照。
  • 必须传达会议记录和大家对会议结果的明确共同认知。

        让团队坐在一起!

  • 大家都懒的动,尽量让“产品负责人”和“全功能团队”都坐在一起!
  • 互相听到:所有人都可以彼此交谈,不必大声喊,不必离开座位。
  • 互相看到:所有人都可以看到彼此,都能看到任务板——不用非得近到可以看清楚内容,但至少可以看到个大概。
  • 隔离:如果你们整个团队突然站起来,自发形成一个激烈的设计讨论,团队外的任何人都不会被打扰到,反之亦然。

        团队建设

  • Scrum 团队最佳人数控制在“5~9”人。
  • 全职能性团队:开发组(后台开发、前端开发、测试人员——3~8人)、Scrum Master(项目经理)、产品负责人
  • 兼职团队成员:美工、DBA、运维

        每日立会(Daily Standup Meeting)——建议下班前开始

        会议目的

  • 团队在会议中作计划,协调其每日活动,还可以报告和讨论遇到的障碍。
  • 任务板能够帮助团队聚焦于每日活动之上,要在这个时候更新任务板和燃尽图。

        构成部分

  • 任务板、即时贴、马克笔
  • 提示:ScrumMaster 不要站在团队前面或是任务板旁边,不要营造类似于师生教学的气氛。

        基本要求

  • 成员:团队、Scrum Master
  • 无法出席的团队成员要由同伴代表。
  • 持续时间/举办地点:每天15分钟,同样时间,同样地点。
  • 提示:团队成员在聆听他人发言时,都应该想这个问题:“我该怎么帮他做得更快?”

        会议输出

  • 团队彼此明确知道各自的工作,最新的工作进度图。
  • 得到最新的“障碍 Backlog”
  • 得到最新的“Sprint Backlog”

        会议过程

  • 团队聚在故事板旁边,可以围成环形。
  • 从左边第一个开始,向团队伙伴说明他到现在完成的工作。
  • 然后该成员将任务板上的任务放到正确的列中。
  • 如果可以的话,该成员可以选取新的任务,交将其放入“进行中工作”列。
  • 如果该成员遇到问题或障碍,就要将其报告给 Scrum Master。
  • 每个团队成员重复步骤2到步骤5。

        每个人三个问题:

  • 上次会议时的任务哪些已经完成?:把任务从“正在处理”状态转为“已完成”状态。——今天完成了什么?
  • 下次会议之前,你计划完成什么任务?:如果任务状态为“待处理”,转为“正在处理”状态。如果任务不在 Sprint Backlog 上,则添加这个任务。如果任务不能在一天成,把这任务细分成多个任务。如果任务可以在一天内完成,把任务状态设为“正在处理”。如果任务状态已经是“正在 处理”,询问是否存在阻碍任务完成得问题。——明天做什么?
  • 有什么问题阻碍了你的开发?:如果有阻碍你的开发进度的问题,把该障碍加入到障碍 Backlog中。——今天遇到了什么问题?

        注意事项

  • 不要迟到
  • 不要超出限制时间
  • 不要讨论技术问题
  • 不要转变会议话题
  • 不要在没有准备的情况下参加
  • Scrum Master 不要替团队成员移动任务卡片,不要替团队更新燃尽图。
  • Scrum Master 不要提出问题,团队成员不要向 Scrum Master 或管理层人员报告。
  • 如果不能出席会议,需要通知团队,并找一名代表参加。

        任务板

  • 任务板集合了选择好的 Product Backlog 和 Sprint Backlog,并以可视化方式展示。
  • 任务板只能由团队维护,使用不同颜色的“即时贴”来区分开发人员,或者在“即时贴”写上接受任务的姓名。
  • 尽量使用大白板,也可以使用软件。

        任务板有4列:

  • 选择好的 Product Backlog:按照优先级,将团队在当前 Sprint 中要着手的 Product Backlog 条目或是故事放在该列中。
  • 待完成的任务:要完成一个故事,你得完成一些任务。在 Sprint 规划会议中,或是在进行当前 Sprint 中,收集所有特定 Backlog 条目需要完成的新任务,并将它们放入该列。
  • 进行中的工作:当团队成员开始某个任务后,他会将该任务对应的卡片放到“进行中的工作”列中。从上个每日 Scrum 例会开始,没有完成的任务都会放在该列中,并在上面做标记(通常是个红点)。如果某个任务在“待完成任务”列中所处时间超过一天,就尽量将该任务分为更小 的部分,然后把新任务放到那一列,移除其所属大任务卡片。如果一个新任务因为某个障碍无法完成,就会得到一个红点标记,Scrum Master 就会记下一个障碍。
  • 完成:当一个任务卡完成后,完成此任务的成员将其放入“完成”列,并开始选取下一张任务卡。

敏捷开发 Scrum 总结

        燃尽图(Burn Down Chart)

  • 跟踪进度要由团队来完成,燃尽图的横轴表示整个Sprint 的总时间,纵轴表示 Sprint 中所有的任务,其单位可以是小时,人天等。一般来说,燃尽图有”Sprint燃尽图”和”Release燃尽图”之分。
  • 团队每天更新燃尽图。
  • 如果燃尽图一直是上升状态,或当 Sprint 进行一段时间之后,Sprint 燃尽图上的Y值仍然与 Sprint 刚开始时相差无几,就说明这个 Sprint 中的 Story 过多,要拿掉一些 Story 以保证这个 Sprint 能顺利完成。 如果Sprint 燃尽图下降得很快,例如 Sprint 刚过半时Y值已经接近0了,则说明这个 Sprint 分配的任务太少,还要多加一些任务进来。在 Sprint 计划会议上,如果团队对即将要做的任务理解和认识不充分,就很可能导致这两种情况的出现。(锻炼团队人员的自我估算时间)
  • 燃尽图要便于团队更新,没必要让它看起来很炫,也不要过于复杂,难以维护。

        Release 燃尽图:记录整个Scurm项目的进度,它的横轴表示这个项目的所有Sprint, 纵轴表示各个Sprint开始前,尚未完成的工作,它的单位可以是个(Story 的数量),人天等。

敏捷开发 Scrum 总结

        Sprint 规划会议——第一部分(上午)

        会议目的

  • 该会议的工作以分析为主,目的是要详细理解最终用户到底要什么,产品开发团队可以从该会议中详细了解最终用户的真实需要。在会议的结束,团队将会决定他们能够交付哪些东西。
  • 产品负责人在会前准备:条目化的需求(用户故事),优先级排序,最近1~2个迭代最希望看到的功能。会前准备至关重要,可帮助产品负责人理清头绪,不至于在迭代期内频繁提出变更、增加或删除故事。

        基本要求

  • 迭代计划会在每个迭代第一天召开,目的是选择和估算本次迭代的工作项。
  • 只有团队成员才能决定团队在当前 Sprint 中能够领取多少个 Backlog 条目的工作。

        构成部分:

  • 经过估算和排序的 Product Backlog。
  • 挂图、马克笔、剪刀、胶水、即时贴、白板、铅笔和蜡笔。
  • 假期计划表、重要人员的详细联系信息。
  • 参会成员:团队成员、Scrum Master、产品负责人

        持续时间:在 Sprint 中,每周该会议占用时间为 60 分钟,在早上召开该会议,这样还有可能在同一天召开 Sprint 规划会议的第二部分。

        会议输出

  • 选择好的 Product Backlog 条目。
  • 各个 Backlog 条目的需求。
  • 各个 Backlog 条目的用户验收测试。

        会议过程

  • 从第一个 Product Backlog 条目(故事)开始。
  • 讨论该 Product Backlog 条目,以深入理解。
  • 分析、明确用户验收测试。
  • 找到非功能性需求(性能、稳定性...)
  • 找到验收条件。
  • 弄清楚需要“完成”到何种水平。
  • 获得 Backlog 条目各个方面的清晰了解。
  • 绘制出所需交付物的相关图表,包括流程图、UML图、手绘草图、屏幕 UI 设计等。
  • 回到步骤1,选取下一个 Backlog 条目。

        流程检查:询问团队能否快速回答下列问题,只需要简要回答即可:“我们能 在这个 Sprint 中完成第一个 Backlog 条目吗?”如果能得到肯定的回答,那么继续询问下一个 Backlog 条目,一直到已经分析完的最后一个 Backlog 条目。——接下来,休息一下。在休息后,对下一个 Backlog 条目展开上述流程。

        结束流程:

  • 在 Sprint 规划会议第一部分结束前留出 20 分钟。
  • 再次提问——这次要更加严肃、正式:“你们能否完成第一个 Backlog 条目,...第二个,...?”
  • 如果团队认为他们不能再接受更多的 Backlog 条目,那就停下来。
  • 现在是非常重要的一步:送走 Product Owner,除了团队和 Scrum Master 之外的所有人,都得离开。
  • 当其他人都离开后,再询问团队:“说真的——你们相信自己可以完成这个列表?”
  • 希望团队现在能短暂讨论一下,看看他们到底认为自己能完成多少工作。
  • 将结果与 Product Owner 和最终用户沟通。

        注意事项:不要改变 Backlog 条目大小,不要估算任务。

        Sprint 规划会议——第二部分(下午)

        会议目的

  • 该会议的工作以设计为主,产品开发团队可以为他们要实现的解决方案完成设计工作,在会议结束后,团队知道如何构建他们在当前 Sprint 中要开发的功能。

        基本要求

  • 只有产品开发团队才能制定解决方案,架构师或其他团队之外的人只是受邀帮助团队。

        构成部分:

  • 能够帮助团队在该 Sprint 中构建解决方案的人,比如厂商或是来自其他团队的人员。
  • 选择好的 Product Backlog 条目。
  • 挂图......

        注意事项:不要估算任务,不要分配任务。

        会议输出

  • 应用设计、架构设计图、相关图表
  • 确保团队知道应该如何完成任务!

        会议过程

  • 从第一个 Backlog 条目开始。
  • 查看挂图,确定对于客户的需求理解正确。
  • 围绕该 Backlog 条目进行设计,并基于下列类似问题:
    • 我们需要编写什么样的接口?
    • 我们需要创建什么样的架构?
    • 我们需要更新哪些表?
    • 我们需要更新或是编写哪些组件?
    • ......

        当团队明确知道自己应该如何开发该功能后,就可以转向下一个 Backlog 条目了。在会议的最后 10 分钟,团队成员使用即时贴写出初步的任务。这能帮助团队成员知道接下来的工作从哪里开展,将这些任务放在任务板上。

        持续时间:在 Sprint 规划会议第一部分完成后,召开该会议。可以将午餐作为两次会议的一个更长久的休息。但是要在同一天完成 Sprint 规划第一部分,在 Sprint 中,每周该会议占用时间为 60 分钟。

        估算会议——根据项目情况合并到 Sprint 第二部分会议

        会议目的

  • 要做好战略规划,你需要知道 Backlog 中各项的大小,这是版本规划的必要输入;如果想知道团队在一个 Sprint 中能够完成多少工作,这个数据也是必须的。
  • 团队成员可以从会议中知道项目接下来的阶段会发生哪些事情。

        基本要求

  • 只有团队才能作估算,Product Owner(产品负责人)需要在场,以帮助判定某些用户故事能否拆分为更小的故事。

        构成部分:

  • Product Owner 根据业务价值排定 Product Backlog 各项顺序。
  • 需要参加的人员:Team、Product Owner、User、Scrum Master

        注意事项:

  • 不要估算工作量大小——只有团队能这么做。
  • Product Owner 不参与估算。

        会议过程

  • Prodcut Owner 展示她希望得到估算的 Product Backlog 条目。
  • 团队使用规划扑克来估算 Backlog 条目。
  • 如果某个 Backlog 条目过大,需要放到下一个或是后续的 Sprint 中,团队就会将该大 Backlog 条目划分为较小的几个 Backlog 条目,并对新的 Backlog 条目使用规划扑克进行估算。
  • 重新估算 Backlog 中当前没有完成、但是可能会在接下来三个 Sprint 中要完成的条目。

        持续时间:该会议时间限制为不超过90分钟。如果 Sprint 持续时间长于一周,那么每个 Sprint 举行两次估算会议比较合适。

        会议输出

  • 经过估算的 Product Backlog。
  • 更小的 Backlog 条目。

        扑克牌估算(Planning Poker)

        具体步骤:

  • 每个人各自估算后独立出暗牌,听口令一起开牌。
  • 数值最大者与最小者PK,其他人旁听也可参考。
  • 讨论结束后重新出牌和开牌。
  • 重复上述过程,直到结果比较接近。

        常见问题

        1、为什么任务要分给组而不是个人?

        答:因为怕出错了牌又说不出所以然,这样即使日后他不做这个功能,也对这个功能很了解。

        2、为什么不让最后领任务的人自己估算?

        答:因为他很可能因为不知道某代码可用、不知道某软件不行....而选择了错误的实现方法。

        3、为什么不让师傅估算大家采纳,他不是最厉害吗?

        答:师傅的想法常常是徒弟们理解不了的,比如为什么不留在女儿国而偏偏去西天取经之类的,共同估算就是让大家在思考中对照自己的实现方法和师傅差异的过程。

        Sprint 评审会议(Review Meeting)——根据项目需要举行

        会议目的

  • Scrum 团队在会议中向最终用户展示工作成果,团队成员希望得到反馈,并以之创建或变更 Backlog 条目。

        基本要求

  • Sprint 复审会议允许所有的参与者尝试由团队展示的新功能。

        构成部分

  • 有可能发布的产品增量,由团队展示。

        会议输出

  • 来自最终用户的反馈。
  • 障碍 Backlog 的输入。
  • 团队 Backlog 的输入。
  • 来自团队的反馈为 Product Backlog 产生输入。

        持续时间:90分钟,在 Sprint 结束时进行。

        会议过程

  • Product Owner 欢迎大家来参加 Sprint 复审会议。
  • Product Owner 提醒大家关于本次 Sprint 的目的:Sprint 目标、Scrum 团队在本次 Sprint 中选定要开发的故事。
  • 产品开发团队展示新功能,并让最终用户尝试新功能。
  • Scrum Master 推进会议进程。
  • 最终用户的反馈将会由 Product Owner 和/或 Scrum Master 记录在案。

        注意事项:

  • 不要展示不可能发布的产品增量。
  • Scrum Master 不要负责展示结果。
  • 团队不要针对 Product Owner 展示。
  • Sprint 反思会议(Retrospective Meetin)——根据项目需要举行

        会议目的

  • 该会议的对应隐喻:医疗诊断!其目的不是为了找到治愈方案,而是要发现哪些方面需要改进。

        构成部分

  • 参与人员:团队成员、Scrum Master

        基本要求

  • 从过去中学习,指导将来。
  • 改进团队的生产力。

        注意事项

  • 不要让管理层人员参与会议。
  • 不要在团队之外讨论找到的东西。

        会议输出

  • 障碍 Backlog 的输入。
  • 团队 Backlog 的输入。

        持续时间:90分钟,在 Sprint 评审会议结束后几分钟开始。

        会议过程

  • 准备一个写着“过去哪些做的不错?”的挂图。
  • 准备一个写着“哪些应该改进?”的挂图。
  • 绘制一条带有开始和结束日期的时间线。
  • 给每个团队成员发放一叠即时贴。
  • 开始回顾。
  • 做一个安全练习。
  • 收集事实:发放即时贴,用之构成一条时间线。每个团队成员(包括 Scrum Master)在每张即时贴上写上一个重要的事件。
  • “过去哪些做的不错?”:采取收集事实同样的过程,不过这次要把即时贴放在准备好的挂图上。
  • 做一个分隔,以区分“过去哪些做的不错”和接下来要产出的东西。
  • “哪些应该改进?”:像“过去哪些做的不错”那样进行。
  • 现在将即时贴分组:
  • 我们能做什么》团队 Backlog 的输入。
  • 哪些不在我们掌控之内?》障碍 Backlog 的输入。
  • 根据团队成员的意见对两个列表排序。
  • 将这两个列表作为下个 Sprint 的 Sprint 规划会议第一部分和 Sprint 规划会议第二部分的输入,并决定到时候要如何处理这些发现的信息。

        附两张流程图(资料截图)

敏捷开发 Scrum 总结

敏捷开发 Scrum 总结

 

 

转自:http://www.open-open.com/lib/view/open1330413325514.html

2015-08-01 14:25:15 benxiaohai529 阅读数 621
  • 敏捷开发——SCRUM

    SCRUM是当前较火的一种敏捷开发方法,有用户故事、冲刺、燃尽图等很多很酷的玩法,有牛B的产品负责人、SCRUM Master,有很强的自组织团队。

    13678 人正在学习 去看看 张传波

抽空学习了下敏捷开发,觉得跟自己的一些想法不谋而合,如果一个团队能实施scrum,那效率一定非常高,非常适合移动开发,Android,IOS,WM等小team开发一个app。希望对大家也有帮助,

  前期可能会觉得有点别扭,但是坚持下来,效果会非常不一样。你会发现,效果高很多,而且规范。

  产品backlogScrum的核心,也是一切的起源。从根本上说,它就是一个需求、或故事、或特性等组成的列表,按照重要性的级别进行了排序,它里面包含的是客户想要的东西,并用客户的术语加以描述。

         包括以下字段:

 ID – 统一标识符,自增长

 NAME – 简短的、描述性的名称

 Importance – 产品负责人评出一个数值,指示这个条目有多重要,比如10 – 150,分数越高越重要。

 Initial estimate(初始估算) – 团队的初步估算该条目的工作日。

 How to demo – 简单的测试规范,这段描述可以作为验收测试的伪码表示。

 Notes – 相关信息、解释说明和对其它资料的引用等,一般都非常简短。

 

为了便于产品负责人判断优先级别,我们也会在产品backlog中使用一些其它字段

 Track(类别) – 当前故事的大致分类,例如后台系统优化。这样产品负责人就可以很容易选出所有的优化条目,把他们的级别都设得比较低。类似的操作执行起来都很方便。

Components – 数据库,服务器,客户端。团队或者产品负责人可以在这里进行标识,以明确哪些技术组件在这个条目的实现中会被包含进来。这种做法在多个Scrum团队协作的时候很有用比如一个后台系统团队和一个客户端团队他们很容易知道自己应当对哪些需求负责。

  Requestor(请求者) – 产品负责人可能需求记录是哪个客户或相关干系人最先提出了这项需求,在后续开发过程中向他提供反馈。

 

 

 

 

 

         产品负责人应当理解每个故事的含义(通常需求都是由他来编写的,但是有的时候其他人也会添加一些请求,产品负责人对它们划分先后次序)。他不需要知道每个需求具体是如何实现的,但是他要知道为什么这个需求会在这里。

         Sprint计划会议非常关键,应该算是Scrum中最重要的活动。要是它执行的不好,整个sprint甚至都会被毁掉。举办Sprint计划会议,是为了让团队获得足够的信息,能够在几个星期内不受干扰的工作,也是为了让产品负责人能对此有充分的信心。

         Sprint计划会议成果:

1.  Sprint目标。

2.  团队成员名单(以及他们的投入程度,如果不是100%的话)

3.  Sprint backlog(Sprint中包括的需求列表)

4.  确定好sprint演示日期

5.  确定好时间地点,供举行每日scrum会议

                            

         整个团队和产品负责人都必须参加sprint计划会议。原因在于,每个需求都含有三个变量,它们两两之间都对彼此有着强烈依赖。

         

范围(Scope)和重要性(Importance)由产品负责人设置。估算(estimate)由团队设置。在sprint计划会议上,经过团队和产品负责人面对面的对话,这三个变量会逐步得到调整优化。会议启动后,产品负责人一般会先概况一下希望在这个sprint中达成的目标,还有他认为最重要的故事,接下来,团队从最重要的故事开始逐一讨论每个故事,一一估算时间。

 

质量分为内部质量和外部质量

         外部质量 是系统用户可以感知的。运行缓慢、让人迷糊的用户界面就属于外部质量低劣。

         内部质量 指用户开不到的要素,它们对系统的可维护性有深远影响。可维护性有深远影响。可维护性包括系统设计的一致性、测试覆盖率、代码可读性和重构等等。

 

一般来说,系统内部质量优秀,外部质量仍有可能很差。而内部质量差的系统,外部质量肯定也不怎么样。牺牲内部质量是一个糟糕透顶的想法。现在节省下来一点时间,接下来的日子里你就要一直为它付出代价。一旦我们放松要求,允许代码库中暗藏问题,后面就很难恢复质量了。

 

 

用生产率计算来估算

         1.得出估算生产率。

         2.计算在不超出估算生产率的情况下可以加入多少故事。

         生产率是“已完成工作总量”的一个衡量方式,其中每一个需求都是用它的原始估算进行衡量的。

下图中,左边是sprint启动时的估算生产率,右边是sprint结束时的实际生产率。每个矩形都是一个需求,里面的数字表示这个需求的原始估算。

注意,这里的实际生产率建立在每个故事的原始估算基础之上,在sprint过程中对需求时间进行的修改都被忽略了。敏捷软件开发和精益制造的要求:把事情完全做完!达到可以交付的状态!事情只做了一半,它的价值就是0(也许还会是负数)

This Sprint’s Estimated velocity:

         (Available Man-Days) * (Focus Factor) = (Estimated Velocity)

投入程度(Focus Factor)用来估算团队会在sprint中投入多少精力。投入程度低,就表示团队估计会受到很大干扰,或者他们觉得自己的时间估算太过理想化。要想得出一个合理的投入程度,最好的办法就是看看上一个sprint的值(对前几个sprint取平均值自然更好)

Last Sprint’s Focus Factor:

         (Focus Factor) = (Actual Velocity) / (Available Man-Days)

生产率计算

1,  直觉反应、

2,  基于昨日天气的生产率计算、

3,  基于可用人-天和估算投入程度的生产率计算

在大多数sprint计划会议上,大家都会讨论产品backlog中的需求细节。对故事进行估算、重定优先级、进一步确认细节、拆分,等等都会在会议上完成。

要想收到好的效果,不妨创建一些索引卡,把他们放到墙上(或一张大桌子上)

这种用户体验比计算机和投影仪好得多:

         大家站起来四处走动他们可以更长时间的保持清醒,并留心会议进展。

         他们有更多的个人参与感(而不是只有那个拿着键盘的家伙才有)

         多个故事可以同时编辑。

         重新划分优先级变得易如反掌 – 挪动索引卡就行。

         会议结束后,索引卡可以拿出会议室,贴在墙上的任务板上。

把需求拆分成任务后,时间估算就变得更容易(也更精确)

 

不要让任务拆分出现在产品backlog,原因有二:

         任务拆分的随机性比较强,在sprint进行中,它们常常会发生变化,不断调整,所以保持产品backlog的同步很让人头大。

         产品负责人不需要关心这种程度的细节。

 

使用计划纸牌做时间估算

         估算是一项团队活动 --- 通常每个成员都会参与所有需求的估算。为啥要每个人都参加?

1,  在计划的时候,我们一般都还不知道到底谁会来实现哪个需求的哪个部分。

2,  每个需求一般有好几个人参与,也包括不同类型的专长(用户界面设计、编程、测试、等)

3,  团队成员必须要对需求内容有一定的理解才能进行估算。要求每个人都做估算,我们就可以确保他们都理解了每个条目的内容。这样就为大家在sprint中相互帮助夯实了基础,也有助于需求中的重要问题被尽早发现。

4,  如果要求每个人都对需求做估算,我们就会常常发现两个人对同一需求的估算结果差异很大。我们应该尽早发现这种问题并就此进行讨论。

         每个人都会得到如上图的13张卡片。在估算需求的时候,每个人都选出一张卡片来表示他的时间估算(man-day的方式表示),并把它正面朝下扣在桌上。所有人都完成以后,桌上的纸牌会被同时揭开。这样每个人都会被迫进行自我思考,而不是依赖于其他人估算的结果。如果在两个估算之间有着巨大差异,团队就会就辞进行讨论,并试图让大家对需求内容达成共识。他们也许会进行任务分解,之后再重新估算。这样的循环会往复进行,知道时间估算趋于一致为止,也就是每个人对这个需求的估算都差不多相同。

         重要的是,我们必须提醒团队成员,他们要对这个故事中所包含的全部工作进行估算。而不是他们自己负责的部分工作。测试人员不能只估算测试工作。

         有些卡片比较特殊:

1,  0 = “这个故事已经完成了” 或者这个故事根本没啥东西,几分钟就能搞定

2,  ? = “我一点概念都没有,没想法。

3,  咖啡杯 = “我太累了,先歇会吧

 

把需求拆分成任务

         故事是可以交付的东西,是产品负责人所关心的。任务是不可交付的东西,产品负责人对它也不关心。

需求拆分成更小的需求

 

 

需求拆分成任务

1,  新组建的Scrum团队不愿意花时间来预先把故事拆分成任务。有些人觉得这像是瀑布式的做法。

2,  有些故事,大家都理解的很清楚,那么预先拆分还是随后拆分都一样简单。

3,  这种类型的拆分常常可以发现一些会导致时间估算增加的工作,最后得出的sprint计划会更贴近现实。

4,  这种预先拆分可以给每日例会的效率带来显著提高

5,  及时拆分不够精确,而且一旦开始具体工作,事先的拆分结果也许会发生变化,但我们依然可以得到以上种种好处。

 

最后界限在哪里

         优先级列表:

1,  Sprint目标和演示日期。

2,  经过团队认可、要添加到这个sprint中的需求列表。

3,  Sprint中每个需求的估算值。

4,  Sprint中每个需求的如何演示

5,  生产率和资源计算,用作sprint计划的现实核查。包括团队成员的名单及每个人的承诺(不然就没法计算生产率)

6,  明确每日例会固定举行的时间地点。

7,  把需求拆分成任务。这个拆分也可以在每日例会上做,不过这回稍稍打乱sprint的流程。

技术需求:需要完成但又不属于可交付物的东西,跟任何故事都没有直接关联,不会给产品负责人带来直接的价值。如:安装持续构建故武器、编写系统设计概览、重构DAO层、

Sprint信息页

Sprint backlog

 

 

 

 

燃尽图

 

让团队坐在一起:

            一起意味着:

1.  互相听到:所有人都可以彼此交谈,不必大声喊,不必离开座位。

2.  互相看到:所有人都可以看到彼此,都能看到任务版

3.  隔离:如果你们整个团队突然站起来,自发形成一个激烈的设计讨论,团队外的任何人都不会打扰到。

 

产品负责人应该离团队很近,既方便团队成员走过来讨论问题,他也能随时踱到任务版前面去。但是他不应该跟团队坐在一起。为什么?因为这样他就无法控制自己不去关注具体细节,团队也无法凝结成整体(即达到关系紧密、自组织、具有超高生产力的状态)

 

怎样更新任务版

无论sprint backlog是什么形式,都要尽力让整个团队参与到保持sprint backlog及时更新的工作中来,我们曾经试过让Scrum master自己维护sprint backlog,他就不得不每天都去询问大家各自剩余的工作估算时间。这种做法的缺点是:

1.  Scrum master把太多时间用在了管理之类的工作上,而不是为团队提供支持,消除他们的障碍

2.  因为团队成员不再关心sprint backlog ,所以他们就意识不不到sprint的状态,缺少了反馈,团队整体的敏捷度和精力的集中程度都会下降。

如果sprint backlog设计得很好,那每个人都应该很容易修改它。

 

 

 

怎样进行sprint演示

Sprint演示是Scrum中很重要的一环。一次做的不错的演示,即使看上去很一般,也会带来深远影响。

1.  团队的成果得到认可,他们会感觉很好。

2.  其他人可以了解你的团队在做些什么。

3.  演示可以吸引相关干系人的注意,并得到重要反馈。

4.  演示是一种社会活动,不同的团队可以在这里相互交流,讨论各自的工作。这很有意义。

5.  做演示会迫使团队真正完成一些工作,进行发布(即使是只在测试环境中)。如果没有演示,我们就会总是得到99%完成的工作。有了演示以后,也许我们完成的事情会变少,但它们是真正完成的。这比得到一堆貌似完成的工作要好得多,而且后者还会污染下一个sprint

Sprint演示检查列表

1.  确保清晰阐述了Sprint目标。如果在演示上有些人对产品一无所知,那就花上几分钟来进行描述。

2.  不要花太多时间准备演示,尤其是不要做花里胡哨的演讲,把那些玩意扔一边去,集中精力演示可以实际工作的代码。

3.  节奏要快,也就是说要把准备的经历放在保持演示的快节奏上,而不是让它看上去好看

4.  让演示关注于业务层次,不要管技术细节。注意力放在我们做了什么,而不是我们怎么做的

5.  可能的话,让观众自己试一下产品。

6.  不要演示一大堆细碎的bug修复和微不足道的特性,你可以提到一些,但是不要演示,因为他们通常会花很长时间。而且会分散大家的注意力,让他们不能关注更加重要的需求。

 

Scrum回顾

 回顾是Scrum中第二重要的事件(最重要的是sprint计划会议),因为这是你做改进的最佳时机。如果没有回顾,团队就会不断重犯同样的错误。

 回顾组织:

1.  根据要讨论的内容范围,设定为13小时

2.  参与者:产品负责人,整个团队。

3.  在不受干扰的情况下讨论。

4.  一般不要在团队房间中进行回顾,因为这往往会分散大家的注意力。

5.  制定某人当秘书。

6.  Scrum master 向大家展示sprint backlog ,在团队的帮助下对sprint做总结。包括重要事件和决策等。

7.  轮流发言,每个人都有机会在不被人打断的情况下讲出自己的想法,他认为什么是好的,哪些可以做的更好,哪些需要在下个sprint中改变。

8.  我们队预估生产率和时机生产率进行比较。如果差异比较大的话,我们会分析原因。

9.  快结束的时候,Scrum master对具体建议进行总结,得出下个sprint需要改进的地方。

我们的回顾会议一般没有太规整的结构,不过潜在的主题都是一样的:我们怎样才能在下个sprint中做的更好

Scrum回顾白板:

图中的三列分别是:

1.  Good : 如果我们可以重做同一个sprint,哪些做法可以保持。

2.  Could have done better: 如果我们可以重做同一个sprint,哪些做法需要改变。

3.  Improvements:有关将来如何改进的具体想法。

第一列和第二列是回顾过去,第三列是展望将来。

团队通过头脑风暴得出所有的想法,写在即时贴上,如何用圆点投票来决定下一个sprint会着重进行哪些改进。每个人都有三块小磁铁,投票决定下个sprint所要采取措施的优先级。他们可以随意投票,也可以把全部三票投在一件事情上。根据投票情况,选出几项重点进行过程改进,在下一个回顾中,跟踪这些改进的执行情况。不要想一口吃成个胖子,这一点很重要,每个sprint只关注几个改进就够了。

 

定义你的验收标准

除了普通的产品backlog之外,产品负责人还会定义一系列的验收标准,它从合同的角度将产品backlog中重要性级别的含义进行了简单分类。

验收标准规则的例子:

1.  所有重要性>= 100的条目都必须在1.0版中发布,不然我们就会被罚款。

2.  所有重要性在50-99之间的条目应该在1.0中发布,不过也许我们可以在紧接着的一个快速发布版中完成这些。

3.  重要性在25-49之间的条目也都是需要的,不过可以在1.1版中发布

4.  重要性<25的条目都是不确定的,也许永远不会用到。

对最重要的条目进行时间估算

为了制定发布计划,产品负责人需要进行时间估算,至少是要估算在合同中包含的故事。跟sprint计划会议一样,这是产品负责人和团队协作共同完成的团队进行估算,产品负责人描述条目内容,回答问题。

 

 

 

统计一切因素,生成发布计划

有了时间估算和生产率,可以很容易的把产品backlog拆到sprints中:

3sprints=9个星期=2个月。这是我们要向客户许诺的最后期限么?要视合同情况,范围限制有多严格,等等而定。我们通常都会增加相当多的时间缓冲,以避免糟糕的时间估算、未预期的问题和未预期的特性等造成影响。在这种情况下,我们可能会同意把发布日期定在三个月后,让我们保留一个月。我们可以每隔三个星期就给客户演示一些有用的东西,并在过程中邀请他们更改需求。

 

调整发布计划

每个sprint之后,我们都要看一下这个sprint的实际生产率。如果实际生产率跟估算生产率差距很大,我们就会给下面的sprint调整生产率,更新发布计划。如果这会给我们带来麻烦,产品负责人就会跟客户进行谈判;或者检查一下是否能够在不违反合同的情况下调整范围;或者他跟团队一起找出一些方法,通过消除某些在sprint中发现的严重障碍,提高生产率或是投入程度。

 

 

 

 

 

 

组合使用ScrumXP

Scrum注重的是管理和组织实践,而XP关注的是实际的编程实践。这就是为什么它们可以很好的协同工作—-- 它们解决的是不同领域的问题,可以互为补充,相得益彰。

 

结对编程

1.  结对编程可以提高代码质量。

2.  结对编程可以让团队的精力更加集中

3.  结对编程令人精疲力竭,不能全天都这样做。

4.  常常更换结对是有好处的。

5.  结对编程可以增进团队间的知识传播。速度快到令人难以想象。

6.  有些人就是不习惯结对编程。不要因为一个优秀的开发人员不习惯结对编程就把他置之不理。

7.  可以把代码审查座位结对编程的替代方案。

8.  领航员”(不用键盘的家伙)应该自己也有一台机器。不是用来开发,而是在需要的时候稍稍做一些探索尝试、当司机”(使用键盘的家伙)、遇到难题的时候查看文档,等等。

9.  不要强制大家使用结对编程。鼓励他们,提供合适的工具,让他们按照自己的节奏去尝试。

测试驱动开发(TDD)

         测试驱动开发意味着你要先写一个自动测试,然后编写恰好够用的代码,让它通过这个测试,接着对代码进行重构,主要是提高它的可读性和消除重复。整理一下,然后继续。

它会把开发-构建-测试这三者构成的循环变得奇快无比,同时还可以充当一张安全网,让开发人员有足够的信心频繁重构,伴随着系统的增长,设计依然可以保持整洁和简单。

增量设计

一开始应该保持设计简单化,然后不断进行改进;而不是一开始努力保证它的正确性,然后就冻结它,不再改变。

代码标准

绝大多数程序员都有他们自己特定的编程风格。例如他们如何处理异常,如何注释代码,何时返回null等等。有时候这种差异没什么关系,但在某些情况下,系统设计就会因此出现不一致的现象,情况严重,代码也不容易看懂。这时代码标准的用处就会凸显,从造成影响的因素中就可以知道了。

 

 

 

在每个sprint中少做工作来提高质量

回到sprint计划会议上,简单来说,就是别把太多故事都放到sprint里面去!如果碰到了质量问题,或者验收测试周期太长,干脆就每个sprint少干点!这会自动带来质量提升、验收测试周期缩短、影响终端用户的bug减少,并在短期内得到更高的生产率,因为团队可以始终关注与新的东西,而不是不断修复出现问题的旧功能。相对于构建大量功能,然后不得不在惊慌失措的状态下做热修复来说,少构建一些功能,但是把它弄的稳定点儿,这样做要合算得多。

 

Sprint周期 vs. 验收测试周期

解决下一个sprintbug的冲突

可以开始构建新东西,但是要给‘将旧功能产品化’分配高优先级

一般我们完成一个sprint以后就会开始进行下一个。但是我们会在接下来的sprint中花一些时间解决过往sprint中留下的bug。如果修复bug占用了太多时间,从而导致接下来的sprint遭到严重破坏,我们就会分析问题产生的原因以及如何提高质量。我们会确保sprint的长度,使之足以完成对上个sprint中一定数量bug的修复。随着时间推移,经过几个月以后,修复上个sprint遗留bug所有的时间久会减少。而且当bug发生以后,所牵扯的人也更少了,所以不会总是干扰整个团队。现在这种做法已经的到了更多人的认可。sprint计划会议上,考虑到会花时间修复上个sprintbug,所以我们会把投入程度设得足够低。

 

 

 

产品层次的Scrum-of-Scrums

这个会议非常重要。我们一周开一次,有时候频率会更高。在会议上我们会讨论集成问题,团队平衡问题,为下个sprint计划会议做准备,等等。

议程安排如下:

1.  每个人围着桌子坐好,描述一下上周各自的团队都完成了什么事情,这周计划完成什么事情,遇到了什么障碍。

2.  其他需要讨论的跨团队的问题,例如集成。

团体层次的Scrum-of-Scrums

会议的形式为:

1.  开发主管介绍最新情况。例如即将发生的事件信息。

2.  大循环。每个产品组都有一个人汇报他们上周完成的工作,这周计划完成的工作,及碰到的问题。其他人也会作报告。

3.  其他人都可以自由补充任何信息,或者提问问题。

Scrum master检查列表

         Sprint开始阶段

                   Sprint计划会议之后,创建Sprint信息页面

1.  在wiki上创建从dashboard指向所创建页面的链接。

2.  把页面打印出来,贴在通过团队工作区域之外的墙上,让经过的人都可以看到

给每个发邮件,声明新的sprint已经启动。邮件中要包括sprint目标和指向sprint信息页面的链接。

更新sprint数据文档。加入估算生产率、团队大小和sprint长度等等。

确保每日Scrum会议可以按时开始和结束。

为了保证sprint可以如期完成,需要适当地增删故事。确保产品负责人了解这些变化

确保团队可以及时得知Sprint backlog和燃尽图的最新状况。

确保存在的问题和障碍都能被解决,并报告给产品负责人以及开发主管。

         sprint结束时

                   进行开放式的Sprint演示

                   在演示开始前一两天,就要通知到每个人。

与整个团队以及产品负责人一起开Sprint回顾会议。开发主管也应该受邀参加,他可以把你们的经验教训大范围传播开来。

更新sprint数据文档。加入实际生产率和回顾会议中总结出的关键点。 

过程与工具、面面俱到的文档、合同谈判、遵循计划

         个体与交互                胜过                 过程与工具

         可以工作的软件            胜过         面面俱到的文档

         客户协作                           胜过                  合同谈判

         响应变化                           胜过                  遵循计划

2017-12-01 16:12:13 yangmq1024 阅读数 343
  • 敏捷开发——SCRUM

    SCRUM是当前较火的一种敏捷开发方法,有用户故事、冲刺、燃尽图等很多很酷的玩法,有牛B的产品负责人、SCRUM Master,有很强的自组织团队。

    13678 人正在学习 去看看 张传波

http://www.scrumcn.com/agile/scrum-knowledge-library/scrum.html#tab-id-1                  

SCRUM框架包括3个角色、3个工件、5个事件、5个价值

3个角色

  1. 产品负责人(Product Owner)
  2. Scrum Master
  3. 开发团队

3个工件

  1. 产品Backlog(Product Backlog)
  2. SprintBacklog
  3. 产品增量(Increment)

5个事件

  1. Sprint(Sprint本身是一个事件,包括了如下4个事件)
  2. Sprint计划会议(Sprint Planning Meeting)
  3. 每日站会(Daily Scrum Meeting)
  4. Sprint评审会议(Sprint Review Meeting)
  5. Sprint回顾会议(Sprint Retrospective Meeting)

5个价值

  1. 承诺 – 愿意对目标做出承诺
  2. 专注– 把你的心思和能力都用到你承诺的工作上去
  3. 开放– Scrum 把项目中的一切开放给每个人看
  4. 尊重– 每个人都有他独特的背景和经验
  5. 勇气– 有勇气做出承诺,履行承诺,接受别人的尊重

透明(在软件开发过程的各个环节保持高度的可见性)、检验(工作完成的效率,检验工作成果人员的技能水平和积极性。)、适应(最终产品是不合格

过程控制通常有两种方式,第一种方式是预定义的过程,第二种方式是经验性过程。

“在过程运行机制相当简单易懂的情况下,典型的做法是采用预定义的建模方式。如果过程复杂程度超出预定义方式的能力范围,便应用经验性方式。”

产品待办事项列表通常以价值、风险、优先级和必须性排序

产品负责人至少在每个 Sprint 评审的时候追踪剩余工作总量。

开发团队每天追踪剩余总和并预测 达成 Sprint 目标的可能性。通过在 Sprint 中不断追踪剩余工作,开发团队可以管理自己 的进度。

Sprint Burndown Chart 显示了Sprint中累积剩余的工作量,它是一个反映工作量完成状况的趋势图。 图中Y轴代表的是剩余工作量,X轴代表的是Sprint的工作日。

5个事件
(1)

每个 Sprint 都可以被视为一个项目,为期不超过一个月。就如同项目一样,Sprint 被用于 完成某些事情。每个 Sprint 都会定义要开发什么,还有一份设计过和灵活的计划用来指导 如何做这些事、工作内容和最终产品。

如果 Sprint 目标过时,那么 Sprint 就会被取消。所有未完成的产品待办列表 项都会被放回到产品待办列表中,并重新估算。取消 Sprint 会消耗资源,因为每个人都必须重新集合在另一个 Sprint 计划会议来开始另一 个 Sprint 。

(2)

Sprint 会议的输入是产品待办列表、最新的产品增量、开发团队在这个 Sprint 中能力的预 测以及开发团队的以往表现。开发团队自己决定选择产品待办列表项的数量。只有开发团 队可以评估接下来的 Sprint 可以完成什么工作。

在 Sprint 计划会议的最后,开发团队规划出在 Sprint 最初几天内所要做的工作,通常以一天 或更少为一个单位。开发团队自组织地领取 Sprint 待办产品列表中的工作,领取工作在 Sprint 计划会议和 Sprint 期间按需进行。

了达成 Sprint 目标,需要实现相应的功能 和实施所需的技术。如果所需工作和预期的不同,开发团队需要与产品负责人沟通协商 Sprint 待办列表的范围。

(3)

每日 Scrum 站会是一个以 15 分钟为限的事件,它让开发团队同步开发活动,并为接下了的24小时制定计划

每日 Scrum 站会在同一时间同一地点举行,以便降低复杂性。在会议上,每一个开发团队 成员都需要说明:

  • 昨天,我为帮助开发团队达成 Sprint 目标做了什么?
  • 今天,我为帮助开发团队达成 Sprint 目标准备做什么?
  • 是否有任何障碍在阻碍我或开发团队达成 Sprint 目标?
  • Scrum Master 确保开发团队每日站会如期举行,但开发团队自己负责召开会议。Scrum Master 教导开发团队将每日 Scrum 会议时间控制在 15 分钟内。
  • Scrum Master 强制执行每日 Scrum 站会规则——只有开发团队成员才能参加。
(4)

Sprint 评审会议在 Sprint 快结束时举行 ,用以检视所交付的产品增量并按需调整产品待办 列表。

对于长度为一个月的 Sprint 来说,评审会议的限时为 4 小时。对于较短的 Sprint 来说,会 议的时间会有所缩短

  • 产品负责人邀请 Scrum 团队和主要的利益攸关者参加会议;
  • 产品负责人说明哪些产品待办列表项已经“完成”和哪些没有“完成”;
  • 开发团队讨论在 Sprint 期间哪些工作做的很好,遭遇到什么问题以及问题是如何解决 的;
  • 开发团队演示“完成”的工作并解答关于所交付增量的问题;
  • 产品负责人讨论当前的产品待办列表的情况。他/她根据到目前为止的进度来预测可能的完成日期(如果有需要的话);
  • 参会的所有人就下一步的工作进行探讨,这样, Sprint 评审会议就能够为接下了的Sprint 计划会议提供有价值的输入信息;
  • 评审市场或潜在的产品使用方式所带来的接下来要做的最有价值的东西的改变;同时,
  • 为下个预期产品版本的发布评审时间表、预算、潜力和市场
(5)

Sprint 回顾会议发生在 Sprint 评审会议结束之后

对于长度为 一个月的 Sprint 来说,会议的限时为 3 小时。对于较短的 Sprint 来说,会议时间通常会缩 短。Scrum Master 要确保会议举行

  • 检视前一个 Sprint 中关于人、关系、过程和工具的情况如何;
  • 找出并加以排序做得好的和潜在需要改进的主要方面;同时,
  • 制定改进 Scrum 团队工作方式的计划。
在 Sprint 回顾会议结束时,Scrum 团队应该明确接下来的 Sprint 中需要实施的改进。在下 一个 Sprint 中实施这些改进是基于Scrum 团队对自身的检视而做出的适当调整。


SCRUM的四大支柱

(1)
在Scrum的开发模式下,我们将开发周期分成多个1-4周的迭代,每个迭代都交付一些增量的可工作的功能。

迭代的长度是固定

这里需要强调的是在每个迭代必须产出可工作的增量功能,而不是第一个迭代做需求、第二个迭代做设计、第三个迭代做代码。
(2)
增量是一个 Sprint 及以前所有 Sprint 中完成的所有产品代办事项列表条目的总和。 
无论产品负责人是否决定真正发布它,增量必须可用
(3)
自组织团队还需要自己监督和管理他们的工程过程和进度,自组织团队自己决定团队内如何开展工作,决定谁来做什么,即分工协作的方式。
(4)
Product Backlog是一个需求的清单,Product Backlog中的需求是渐进明细的,Backlog当中的条目必须按照商业价值的高低排序。

在Scrum中,只要有足够1-2个Sprint开发的细化了的高优先级的需求,我们就可以启动Sprint了,而不必等到所有的需求都细化之后。我们可以在开发期间通过Backlog的梳理来逐步的细化需求。

SCRUM团队


Scrum开发团队的主要职责包括如下五个方面:

  • 执行Sprint
  • 梳理产品Backlog
  • 做Sprint计划
  • 每天跟进工作进展,并对他们的工作做检查和调整
  • 每个迭代对产品和团队的工作过程做检查和调整
  • 开发团队有如下10方面的特征:

    • 自组织
    • 多元化、跨职能的完整团队
    • 团队成员符合T型技能,即一专多长
    • 持续改进
    • 最大限制的沟通
    • 透明沟通
    • 2个披萨的团队大小(5-9人)
    • 专注、投入
    • 按照可持续的节奏工作
    • 团队长期存在,人员稳定

    对于自组织团队来说,他们拥有如下权利:

    • 团队决定谁做什么,即任务的分配
    • 团队决定如何做,如何实现目标,即团队做技术决策
    • 团队需要在确保目标的前提下制定团队内的行为准则
    • 团队有义务保持过程的透明性
    • 团队监督和管理他们的过程和进度

    自组织团队的环境下,管理层关注在如下几个方面:

    • 确定团队目标和愿景
    • 确定团队上下文,组织结构、团队结构、团队组成
    • 提供环境和支持(安全感、良好的团队空间、氛围,技能辅导等)
    • 授权团队
    • 训练协作
    特性团队

如果我们的产品开发团队只有在10人以内,我们使用一个跨职能的Scrum团队,可以很容易地按照scrum和敏捷的方式开发产品。 

如果产品团队规模较大,考虑团队的结构和组织方式。



在传统的开发模式下,我们习惯于按照系统的架构模块,或者系统分层组织团队,也有的团队按照系统需求、开发、测试结合系统架构混合组织的方式

按照Scrum和敏捷的交付模式,组件团队有如下一些限制:

第一:按照组件来组织团队,很难避免团队之间的依赖,跨团队的协调和依赖管理更加复杂,不利于跨组件或者各个层之间的沟通。

第二:每个团队专注在自己的模块,由于各模块、或分层需求工作量的不同,很容易产生等待,并且容易产生低价值的交付。

第三:由于职责单一,限制了学习,使得专业更加单一化

第四:Sprint结束的时候无法提交可交付的增量产品功能,延迟价值交付



特性团队的特点:

  • 长期稳定的团队,逐个端到端完成客户特性
  • 以客户为中心的特性驱动
  • 跨职能、完整团队
  • 共享代码库,统一的持续集成
  • 拥有通用型专家

  • 特性团队的好处:

    • 团队内可以做到端到端,所以减少了等待,周期加快
    • 比较容易在一个Sprint中交付可用的产品增量
    • 减少了团队之间依赖,计划会更容易
    • 责任范围的扩大,各种不同领域的专家在一个团队,增加了
    • 个人学习和团队学习的机会

    用户故事的六个特性- INVEST

    INVEST = Independent, Negotiable, Valuable, Estimable, Small, Testable

    一个好的用户故事应该遵循INVEST原则。

    • 独立性(Independent)— 要尽可能的让一个用户故事独立于其他的用户故事。用户故事之间的依赖使得制定计划,确定优先级,工作量估算都变得很困难。通常我们可以通过组合用户故事和分解用户故事来减少依赖性。
    • 可协商性(Negotiable)— 一个用户故事的内容要是可以协商的,用户故事不是合同。一个用户故事卡片上只是对用户故事的一个简短的描述,不包括太多的细节。具体的细节在沟通阶段产出。一个用户故事卡带有了太多的细节,实际上限制了和用户的沟通。
    • 有价值(Valuable)— 每个故事必须对客户具有价值(无论是用户还是购买方)。一个让用户故事有价值的好方法是让客户来写下它们。一旦一个客户意识到这是一个用户故事并不是一个契约而且可以进行协商的时候,他们将非常乐意写下故事。
    • 可以估算性(Estimable)—开发团队需要去估计一个用户故事以便确定优先级,工作量,安排计划。但是让开发者难以估计故事的问题来自:对于领域知识的缺乏(这种情况下需要更多的沟通),或者故事太大了(这时需要把故事切分成小些的)。
    • 短小(Small)— 一个好的故事在工作量上要尽量短小,最好不要超过10个理想人/天的工作量,至少要确保的是在一个迭代或Sprint中能够完成。用户故事越大,在安排计划,工作量估算等方面的风险就会越大。
    • 可测试性(Testable)—一个用户故事要是可以测试的,以便于确认它是可以完成的。如果一个用户故事不能够测试,那么你就无法知道它什么时候可以完成。一个不可测试的用户故事例子:软件应该是易于使用的。
    敏捷估算
  • 估算扑克的使用方法:

    • 每个团队成员拿到一组卡片,包括0,0.5,1,2,3,5,8,13,20,40,?,∞,共计12张。
    • 产品负责人或者一名团队成员扮演阅读者的角色,他负责阅读需要估算产品Backlog的条目,并且询问大家是否有疑问。
    • 团队讨论这个条目。
    • 当团队理解了这个条目之后,每个团队成员按照自己的想法给出估算结果,并且选择对应的扑克出牌,估算结果不能告诉其他人,出牌时数字朝下扣在桌面上。
    • 所有人都出牌之后,阅读者向大家确认是否都已经确定估算结果,确认后,数”1,2,3″,大家同时展示估算结果。
    • 团队评估不同的估算结果.我们是否想法一致?我们是否存在分歧?有没有什么是我没有考虑到的?讨论之后可以再估算一轮,最终团队需要达成一致。
    • 回到第二步,开始估算下一个条目。
    估算大小,而不是估算时间周期,使用相对估算,而不是绝对估算
  • 记录每个Sprint的团队速度

    团队速率是一个Scrum团队在一个Sprint中实际完成的故事点数,通过团队速率可以知道团队做的有多快。新开始的项目或产品开发,或者是新团队,没有初始速度,我们可以做1-2个Sprint测算一个速度,作为初始速度。在Sprint执行过程中,我们要记录每个Sprint的速度,为以后的计划做参考。



  • 在Sprint进行过程中,如下内容不能发生变化:

    • Sprint的目标
    • Sprint的质量目标和验收标准
    • 开发团队的组成

    集中优势兵力各个击破

    在Sprint执行的过程中,团队要避免一个萝卜一个坑的工作方式,团队要协作,并且要集中优势兵力各个击破。

    团队按照蜂拥式(Swarming)的工作方式,团队先集中工作在少数几个需求上面,协作完成它们,然后在开始下一批需求。按照这样的方式一方面可以加强团队协作,另外也有利于及早完成一些需求,让这些需求及早验收。


  • 为什么每日站会没有效果?

    每日站会和传统的项目会议有如下几点不同:

    1.       不会有ScrumMaster或者其他任何人来指派任务。

    2.       团队成员不是向ScrumMaster汇报情况,每日站会是团队自己的会。

    3.       团队成员不会在会上讨论或者解决问题,大家会把问题记录下来,会后找相关的人讨论或召开具体的讨论会议。

    4.       任何团队之外的人不得发言或干扰会议。

    Scrum的最基本原则是“Inspect and Adapt”(检视然后适应),如果什么事情做得很好,问问自己为什么,然后寻找提升的办法

    Martin Fowler’s 《Patterns of Daily Stand-up Meetings》

    你如何知道每日站会起到了很好的效果?

    一个好的每日站会有如下几个特点:

    1.       ScrumMaster不会逐个的问每个人问题,如果是,那么这个会议已经沦为了报告会。

    2.       团队成员互相交流,不是向ScrumMaster报告。

    3.       每日站会都会在15分钟以内完成。如果你遵守了规则并按照正确的方式开会,你就不需要再担心超时了。

    4.       站会结束后,ScrumMaster知道哪些问题需要帮助团队成员解决

    一个自组织的团队有一个非常明显的每天的节奏:Daily Scrum之前非常安静,每日站会之后会有一段活跃的讨论,到中餐前的时候就慢慢安静下来了。午饭之后会有另外一个阶段的活跃讨论,当下班前慢慢的安静下来。


  • 完成的定义

  • 每个增量都附加于之前所有增量并经过充分测试,以此保证所有的增量都能工作。

    随着 Scrum 团队的成熟,我们预期“完成”的定义会扩大,包含更严厉标准来保证高质量。

    需要注意的是,如果在每个迭代,我们对“完成”的标准要求过低,那么这会导致在每个迭代,我们都会遗留一些完成外的工作,完成外的工作持续累计会增加项目的风险,有可能导致产品负责人决定发布的时候,产品却因为累积了过多的完成外的工作而无法发布,以致于我们还需要一个额外的Sprint来使它稳定。

    SCRUM MASTER检查单

    一位合格的ScrumMaster通常能够同时处理2到3个团队的事务。如果你愿意把你的角色限制在组织会议,控制时间盒以及处理团队成员提出的障碍的话,你可以将这个角色当作成兼职来对待

  • 我们推荐每个7人左右的团队都有一位专职的ScrumMaster,尤其是刚开始实施Scrum的时候。

  • Product Owner干得怎么样?

    • 你可以通过帮助Product Owner维护产品待办事列表和发布计划来提高他的效率。(需要注意的是只有Product Owner才能给待办事列表里面的项目排列优先级。)
    • 产品待办事列表里面的项目已经根据Product Owner的最新想法排好优先级了吗?是不是所有来自股东的需求都已经被待办事列表中的项目涵盖了?要记得待办事列表是涌现的。
    • 产品待办事列表的大小是否还能够维护呢?为了使列表更容易维护,应该将细粒度的项目放在靠前的位置,而把粗粒度的项目放在底部。但是要注意的是如果在分析需求上面花费过多的时间,效果只会适得其反,因为你的需求会在团队和客户/股东的持续谈话中发生变化
    • 需求(特别是在产品待办事列表最顶端的需求)能够以独立的、有价值的、可协商的、可估计的、可测试的小粒度用户展现出来吗?
    • 你是否已经让你的Product Owner了解什么是技术债务以及如何避免吗?其中一个方法就是把自动化测试和重构这两项任务加入到每个待办事列表项目的完成的定义中。
    • 待办事列表是不是能让所有股东都能够看懂?
    • 如果你正在使用自动工具来管理你的待办事列表,想一下它真的能够帮助你吗?自动化的管理工具有可能成为ScrumMaster了解信息的障碍
    • 你能够通过有效地把信息打印出来然后传达给其他人吗?
    • 能够通过制订可视化图表来传达足够的信息吗
    • 你有曾经帮助过Product Owner整理待办事列表项目,然后分配到不同的版本中去吗?
    • 是否所有人(包括股东和团队)都知道目前的团队速率是否能够赶上发布的计划呢?
    • Product Owner有根据上次Sprint评审会议来调整发布计划吗?通常Product Owner应该至少在个Sprint之后调整发布计划,一般来说会把一些工作放到后面的版本中,原因是发现了一些更重要的工作要做。你可以在每个Sprint评审会议的时候给大家展示Mike Cohn的产品和版本燃尽图,这样就可以更早地发现当前的进度是不是能够符合预期。


2016-02-18 22:28:13 wu__di 阅读数 2419
  • 敏捷开发——SCRUM

    SCRUM是当前较火的一种敏捷开发方法,有用户故事、冲刺、燃尽图等很多很酷的玩法,有牛B的产品负责人、SCRUM Master,有很强的自组织团队。

    13678 人正在学习 去看看 张传波

     前两天,有群里的朋友在管理团队开发过程中有一些敏捷方面的疑问,类似如何评估工作量、如何高效的进行早会等问题。今天开一篇敏捷开发相关的文章,说说我对敏捷的理解和实践。

     Scrum 是什么?

     Scrum 是一个用于开发和维持复杂产品的框架 ,是一个增量的、迭代的开发过程。在这个框架中,整个开发过程由若干个短的迭代周期组成,一个短的迭代周期称为一个Sprint,每个Sprint的建议长度是2到4周,在互联网开发领域,像类似app的开发,可以缩短到一周。在Scrum中,使用产品Backlog来管理产品的需求,产品backlog是一个按照商业价值排序的需求列表,列表条目的体现形式通常为用户故事。Scrum团队总是先开发对客户具有较高价值的需求。在Sprint中,Scrum团队从产品Backlog中挑选最高优先级的需求进行开发。挑选的需求在Sprint计划会议上经过讨论、分析和估算得到相应的任务列表,我们称它为Sprint backlog。在每个迭代结束时,Scrum团队将递交潜在可交付的产品增量。

     接下来我们以实际的项目为例,详细阐述敏捷开发的运用。

1.首先,项目开展之前,项目经理同产品部门达成一致,明确产品的形态,功能等,项目经理输出backlog,针对本次迭代,列出需求列表,并进行优先级排列。

2.

(1)backlog输出后组织开发人员进行本次迭代会议,会议上向所有开发人员通报本次迭代的任务,时间点。

(2)根据本轮迭代的需求按照story的优先级,组织大家进行任务的认领。此时有两种方式,一种是项目经理根据每个开发人员的特点指定任务,另一种是让大家自己根据兴趣认领。

(3)第三步与第二步其实是并列的,安排story的时候需要评估工作量。工作量的评估也有两种方式,一种是大家举手表决,比如对于story A,三个人给出的工作量是4天,另外两人给出的5天和3天,这个时候就需要最低和最高的给出具体的原因分析,最后取合理值。另外一种是个人认领了相应的story,这时候可以给出工作量,或者在任务分配后,预留一段时间,会后大家反馈给项目经理。

      注意:工作量的评估不单单包括开发的过程,还包括前期的分析设计,自测以及测试部的签收等,要预留出时间,以免工作量评估与时间时间相差悬殊。

(4)迭代会议完成后,项目经理在确定完工作量后,将backlog归档,后期按照这个结果进行每天的项目进度跟踪。

(5)正式迭代开始前,所有的story都需要上状态墙,状态墙分为以下几个部分:初始化、分析、设计、编码、自测、BA验收、测试,最初story都走到初始化阶段。

(6)迭代开始,每天早上进行站立会议,时间尽量缩短,每人不超过2分钟,先描述自己昨天干了什么工作,今天准备干什么,同时将相应的story移到对应的状态。

(7)本轮迭代结束,项目经理召开迭代总结会议,针对本次迭代的情况,进行总结。主要包括以下几个方面:迭代是否符合预期,有没有延期等。然后组织大家针对本次迭代过程有哪些好的方面和不好的方面,每人分别写几条。项目经理进行归类,挑选出公认的观点,进行总结,同时督促大家在下一轮迭代过程中发扬上次的优点,避免上次的缺点。

        以上就是敏捷开发的全部过程。在实践的过程中,要根据项目本身的情况,如果团队人员较多,可以划分出来,比如安卓和iOS,还可以按业务再细分,每次早会时间控制在15分钟以内,提高效率。此外,backlog确定后,迭代过程中不要插入其他需求,破坏敏捷的完整性,新需求放到下次迭代。

        欢迎大家添加我的微信,有任何问题都可以一起讨论,不限于安卓,iOS,后台,项目管理,创业等。

 

2010-02-26 10:22:00 ljinddlj 阅读数 5588
  • 敏捷开发——SCRUM

    SCRUM是当前较火的一种敏捷开发方法,有用户故事、冲刺、燃尽图等很多很酷的玩法,有牛B的产品负责人、SCRUM Master,有很强的自组织团队。

    13678 人正在学习 去看看 张传波

敏捷开发Scrum——Sprint Retrospective

Moakap总结

Scrum中,每个Sprint结束的时候会有两个会议(Sprint Review/DemoSprint Retrospective回顾)。这两个会议是对过去的一个Sprint的一个总结,其中Review/Demo是检查过去一个Sprint的产出(What),主要是PO根据先前的计划来检查Team在过去一个Sprint的工作成果,包括一些Demo,以及未完成部分的总结和分析;而Retrospective则是回顾过去一个Sprint整个Team的运作模式,有什么好的和不好的实践,怎样在未来的Sprint做的更好,强调How

Sprint Retrospective(回顾)

Sprint Retrospective会议主要是整个Team讨论过去的一个Sprint的运作,如何改进使Team更良好的运作。讨论的内容可以是任何有关Team建设的问题,包括工作流程、团队实践、团队内部/外部沟通、团队气氛以及相关工具的使用等等。

Scrum并不是一种方法,而是给软件开发流程提供了一种框架,在整个框架下,不同的项目、团队需要根据具体条件,适时调整实践方法。而Retrospective会议正是一个Scrum团队自我调整的机会。

会议的参加者包括整个Scrum团队、Scrum MasterProduct Owner。会议由Scrum Master主持,一般以下边两个问题开始:

1.       过去的一个Sprint里,我们有哪些好的方面?

2.       过去一个Sprint存在哪些问题?

整个Team就这两个问题进行公开讨论,方式也可以是多样的。可以大家一起讨论,Scrum Master在讨论过程中将大家的观点记录在白板上;也可以让Team每个成员在便签纸上写下自己的答案,可以要求每个问题至少写三点,然后每个人把自己的答案贴在白板上,并给出相关解释。

讨论完毕后,对讨论结果进行分类。对于好的方便,在下个Sprint继续保持并发扬;对于存在的问题,列出Action Point去解决问题。列出的Action Point也会在下个Sprintbacklog中体现出来,并且是高优先级的项目。

注意:不引起任何变化的Retrospective只是浪费时间。

Watch Ken Schwaber's guidance on the Sprint Retrospective Meeting.

 

Scrum敏捷开发

阅读数 18

没有更多推荐了,返回首页