敏捷开发看板贴纸颜色_敏捷开发 看板 - CSDN
  • 今天想与大家分享一款敏捷开发工具“看板”,该词汇来自于岛国,当我看到看板的英文时,我真的惊呆了,看板竟然就是 Kanban?! 我们可以结合 Scrum 与 Kanban,让项目管理更加有效,让资源分配更加合理,让绩效...

    今天想与大家分享一款敏捷开发工具“看板”,该词汇来自于岛国,当我看到看板的英文时,我真的惊呆了,看板竟然就是 Kanban?!

    我们可以结合 Scrum 与 Kanban,让项目管理更加有效,让资源分配更加合理,让绩效考核更加公平!

    • 对于项目经理而言,最担心的就是项目进度不可控,不知道每位开发人员具体的工作进度,有了 Kanban 一切都是那么地清晰。

    • 对于开发经理而言,最担心的就是资源分配不合理,忙的人忙死,闲的人闲死,有了 Kanban 一切都是那么地自然。

    • 对于开发人员而言,最担心的就是绩效考核不公平,“凭什么我做的比他多,拿的工资却比他少?不公平啊!”有了 Kanban 一切都是那么地公平。

    可见,项目经理、开发经理、开发人员拥有了 Kanban,也就拥有了和谐与快乐!


    那么 Kanban 到底是什么呢?我们先来看看这张表格吧:

    image

    下面我们来理解一下这个表格吧!

    • 这个表格有 5 列:Backlog(原始需求)、Selected(被选中的需求)、Develop(开发阶段)、Deploy(部署阶段)、Live(上线阶段)

    • 其中 Develop 阶段包括 2 个子阶段:Ongoing(进行中)、Done(已完成)

    • 包括 3 中角色:产品经理(红色小人)、开发人员(蓝色小人)、部署人员(绿色小人),其实还有项目经理,只是他/她贯穿于始终,所有就没有画出来了。

    在 Backlog 中放置了许多小卡片,它们在 Kanban 中被称为 WIP(Work In Process,在制品)。对于产品经理而言,WIP 是需求,而对于开发人员与部署人员而言,WIP 却是任务。

    实际这些 WIP 卡片上都带有一些文字描述,包括:标题、描述、优先级等信息。

    需要注意的是,Selected、Develop、Deploy 下方有一个数字,该数字表示此阶段中最多可以放置的 WIP 数量。例如,在 Selected 中最多只能放 2 个 WIP;在 Develop 中(包括它的子阶段)最多只能放置 2 个 WIP。这里的数字只是一个示例,具体多少可根据团队实际情况而定。有一个经验公式可以参考“WIP 上限 = 团队规模 * 2 - 1”,减 1 表示大家需要协作,例如:4 人的团队,WIP 上限是 7。

    也许有人会提出,为什么没有 Test 阶段?—— 这个可以有,这里只是一个示例而已,你不妨自行加上去。

    对于多个项目而言,可以在这张表格中添加更多的泳道(行),每一行相当于一个项目,所有的项目进度清晰明了。

    好!继续我们的 Kanban,有意思的事情即将发生!


    image

    产品经理挑选了 2 个 WIP 到 Selected 中,此时,由开发经理决定该任务的技术难度,并由项目经理将任务分配到指定的开发人员,也可将同一个任务分配给两个人,让他们去结对编程。

    开发人员(架构师与程序员)可对 Selected 中的需求进行工作量评估,可采用投票的方式进行,最终给出一个合理的评估值,整个估算过程,项目经理无需参与,主要是开发人员共同完成。

    开发经理可以对任务设置一个“分值”,这个分值可直接影响到后续的绩效考核,所以对大家来说,这个分值是公开可见的,谁做的多,谁做得少,一目了然。当然,开发人员也可以主动承担具有更具挑战的任务(为了锻炼自己,也为了多拿点钱),但任务分配的决定权始终在项目经理手中。


    image

    现在假设 A、B 两个任务已经分别被不同的开发人员处理了,那么这些任务就应该移动到 Ongoing 中,同时,产品经理可以从 Backlog 中挑选出 2 个优先级较高的需求到 Selected 中。这样就保证 Selected 与 Develop 都达到了 WIP 的上限。


    image

    有人已经把 A 做完了,那么 A 就可以移动到 Done 中了。随后,部署人员就可以开始干活了。


    image

    部署人员就可以将 A 从 Done 中移动到 Deploy 中,表示部署人员正在做这件事情。同时,做完了 A 任务的开发人员可以再做其它新任务,只需从 Selected 中移动到 Ongoing 中,移动这件事情不是开发人员随意操作的,而是有项目经理负责的。产品经理发现 Selected 中只有一个 D,就可以考虑放入一些新的需求了。


    image

    此时,部署人员遇到了问题,发现 A 部署的时候总是报错,跑不起来了。同时,其他开发人员也完成了 B 任务。


    image

    完成了 B 任务的开发人员本来是可以做新需求的,但项目经理发现 Develop 中只能放 2 个任务,所以肯定是后面的阶段出现了问题,导致整个流程受阻了。项目经理可以灵活调度人力资源,集中火力解决现在所遇到的问题。


    image

    所以项目经理不得不放弃新的任务,去让开发人员去帮助部署人员来解决问题。此时,其他的开发人员还在进行 C 任务。


    image

    部署的问题还没来得及解决,此时 C 任务也完成了,同时,产品经理也放入了新的 K 需求,确保 Selected 这个水池是装满水的。


    image

    整个部署问题看起来比较搞人,所有的开发人员全都上阵了,集中更多人的智慧,解决这个棘手的问题。此时,产品经理不能放入更多的需求,由于此时 Selected 已经满额了。其实,开发人员面对太多的需求时,往往都会倍感压力,身心憔悴。


    image

    看来这个部署问题,确实够折腾的,连产品经理都过来了凑热闹了。但他或许不懂技术,但多个人多个头脑吧,正所谓“当局者迷,旁观者清”,最终经过大家的努力,肯定会攻克这座碉堡!


    image

    几天之后,Kanban 流程依旧是稳定的,大家分工协作,人力资源合理利用。大家是一个团队,目标就是把项目做好,不会因为自己的事情做完了就闲置了。


    我们不妨将这张表格贴到墙上去吧!让每个员工都可以看到,让过路的老板们也可以看到我们的辛苦努力,这确实是一种非常好的项目管理方法!

    image

    展开全文
  • 敏捷开发方法综述

    2019-08-15 12:48:02
    什么是敏捷开发敏捷开发以用户的需求进化为核心,采用迭代、循序渐进的方法进行软件开发。在敏捷开发中,软件项目在构建初期被切分成多个子项目,各个子项目的成果都经过 测试,具备可视、可集成和可运行使用...

    什么是敏捷开发?

    敏捷开发以用户的需求进化为核心,采用迭代、循序渐进的方法进行软件开发。在敏捷开发中,软件项目在构建初期被切分成多个子项目,各个子项目的成果都经过 测试,具备可视、可集成和可运行使用的特征。换言之,就是把一个大项目分为多个相互联系,但也可独立运行的小项目,并分别完成,在此过程中软件一直处于可 使用状态。

    它采用的是迭代式开发:迭代是指把一个复杂且开发周期很长的开发任务,分解为很多小周期可完成的任务,这样的一个周期就是一次迭代的过程;同时每一次迭代都可以生产或开发出一个可以交付的软件产品。

     

    什么是Scrum?

     Scrum是一种迭代式增量软件开发过程,通常用于敏捷软件开发。包括了一系列实践和预定义角色的过程骨架。Scrum中的主要角色包括同项目经理类似的Scrum主管角色负责维护过程和任务,产品负责人代表利益所有者,开发团队包括了所有开发人员。

     

    Scrum敏捷开发的好处

       Scrum敏捷开发可以显著增加项目成功的可能。

       目前,淘宝,腾讯这样的大公司早已实行了敏捷开发管理。在北京,上海的中小型公司里Scrum敏捷开发也很流行,有很成功的项目经验。

    Scrum流程图

     从这幅图我们不难发现,完成Scrum敏捷开发的流程为:

    第一步:Product Backing   找出完成产品需要做的事情。

    第二步:Sprint Backlog   决定当前冲刺需要解决的事情。

    第三步:Sprint   冲刺。

               冲刺期间要开每日立会(Scruming Meeting),大家站着开会,大家一次报告:

                  1.我昨天做了什么。

                  2.我今天要什么。

                  3.我碰到了哪些问题。

    第四步:得到软件的一个增量版本,发布给用户。然后在此基础上进一步计划增量的新功能和改进。

    Scrum开发的一些注意事项:

    1、我们首先需要确定一个Product Backlog(按优先顺序排列的一个产品需求列表),这个是由Product Owner 负责的;

    2、Scrum Team根据Product Backlog列表,做工作量的预估和安排;

    3、有了Product Backlog列表,我们需要通过 Sprint Planning Meeting(Sprint计划会议) 来从中挑选出一个Story作为本次迭代完成的目标,这个目标的时间周期是1~4个星期,然后把这个Story进行细化,形成一个Sprint Backlog;

    4、Sprint Backlog是由Scrum Team去完成的,每个成员根据Sprint Backlog再细化成更小的任务(细到每个任务的工作量在2天内能完成);

    5、在Scrum Team完成计划会议上选出的Sprint Backlog过程中,需要进行 Daily Scrum Meeting(每日站立会议),每次会议控制在15分钟左右,每个人都必须发言,并且要向所有成员当面汇报你昨天完成了什么,并且向所有成员承诺你今天 要完成什么,同时遇到不能解决的问题也可以提出,每个人回答完成后,要走到黑板前更新自己的 Sprint burn down(Sprint燃尽图);

    6、做到每日集成,也就是每天都要有一个可以成功编译、并且可以演示的版本;很多人可能还没有用过自动化的每日集成,其实TFS就有这个功能,它可 以支持每次有成员进行签入操作的时候,在服务器上自动获取最新版本,然后在服务器中编译,如果通过则马上再执行单元测试代码,如果也全部通过,则将该版本 发布,这时一次正式的签入操作才保存到TFS中,中间有任何失败,都会用邮件通知项目管理人员;

    7、当一个Story完成,也就是Sprint Backlog被完成,也就表示一次Sprint完成,这时,我们要进行 Srpint Review Meeting(演示会议),也称为评审会议,产品负责人和客户都要参加(最好本公司老板也参加),每一个Scrum Team的成员都要向他们演示自己完成的软件产品(这个会议非常重要,一定不能取消);

    8、最后就是 Sprint Retrospective Meeting(回顾会议),也称为总结会议,以轮流发言方式进行,每个人都要发言,总结并讨论改进的地方,放入下一轮Sprint的产品需求中;

     

     

    运用Scrum开发流程中的一些场景图:

    上图是一个 Product Backlog 的示例。

     

    上图就是每日的站立会议,参会人员可以随意姿势站立,任务看板要保证让每个人看到,

    当每个人发言完后,要走到任务版前更新自己的燃尽图。



    任务看版包含 未完成、正在做、已完成 的工作状态,假设你今天把一个未完成的工作已经完成,那么你要把小卡片从未完成区域贴到已完成区域。


     

    每个人的工作进度和完成情况都是公开的,如果有一个人的工作任务在某一个位置放了好几天,大家都能发现他的工作进度出现了什么问题(成员人数最好是5~7个,这样每人可以使用一种专用颜色的标签纸,一眼就可以从任务版看出谁的工作进度快,谁的工作进度慢)

     

     

     上图可不是扑克牌,它是计划纸牌,它的作用是防止项目在开发过程中,被某些人所领导。

    怎么用的呢?比如A程序员开发一个功能,需要5个小时,B程序员认为只需要半小时,那他们各自取相应的牌,藏在手中,最后摊牌,如果时间差距很大,那么A和B就可以讨论A为什么要5个小时...

     

     

    下面列举一个Scrum敏捷开发的具体案例:

    http://www.biaodianfu.com/wp-content/uploads/2013/09/scrum-flow.png

    • Sprint 计划会议 1:原始需求者、产品负责人及团队一起,确定任务优先级,定出 Sprint 目标和既定产品 Backlog。
    • Sprint 计划会议 2:团队将既定产品 Backlog 中的每一项细化成多个任务。每个任务完成的时间限定在一天内。
    • Scrum 每日例会:项目团队成员间的一个进度协调会议。会议每天都在同一时间同一地点举行。时间限定在 15 分钟内。
    • Sprint 验收会议:由原始需求者或产品负责人断定实际所发布的功能是否与既定的 Sprint 目标一致。
    • Sprint 回顾会议:项目团队分析Sprint中的成功经验和所遇到的障碍。

    整个Sprint的周期(时间盒)确定为10天(两周),具体的时间安排为:

    • Sprint会议(0.5天)
    • 开发(8天)
    • 验收&总结(0.5天)
    • 技术提升日(1天),自主学习技术

    1、 需求收集

    1.1  需求的分类

    需求可与分为业务团队的,也可以包括团度内部的,比如性能优化。

    1.2  需求提交模板

    需求种类 优先级 需求类型 需求标题 详细描述 验收条件 价值验证 提交时间 需求人 备注
                       

    需求种类 可从以下四种情况中选择

    • – 任务
    • – 可用性问题(Bug)
    • – 性能问题
    • – 概念想法

    注意:即使是概念性的想法,目前技术上无法实现的想法都可以收集。

    优先级 可从以下五种情况中选择

    • – 特别的严重
    • – 非常重要
    • – 很重要
    • – 普通
    • – 低

    注意:切忌将所有的任务的优先级都设置的非常的高,这里不提供非常紧急这样的表述。我们只会根据重要程度去执行任务,所以紧急的任务需要业务部门及需求方尽早的提出。

    需求类型 可以是两种类型

    • – 详细需求
    • – 毛坯需求

    注意:我们的需求并不是要求一定要完整的,及时是一些非常毛坯的需求,也可以提交过来,毛坯的需求由产品负责人进行分析和梳理,暂不清楚的可选择搁置。

    需求标题 有自己进行书写,但是需要遵守的规范是采用动宾短语格式。

    比如:“导出+CN酒店每天的PV、UV等流量数据”

    注意:这里的需求内容一定是站长使用者角度是提出的,切勿出现专业的程序方面的表述:如添加一个导出的按钮。还有需要注意的是动词切忌使用大而宽泛的词,比如“管理”,类似“管理关键词”这样的需求是严格避免的,这样会使得要开发的内容变得没有清晰的边界。

    详细描述 需要按照用户故事的格式进行书写。具体用户故事格式的要求如下:

    用户故事是从用户的角度来描述用户渴望得到的功能。需要注意的是用户故事不能够使用技术语言来描述,要使用用户可以理解的业务语言来描述。一个好的用户故事包括三个要素:

    • 角色:谁要使用这个功能。
    • 活动:需要完成什么样的功能。
    • 商业价值:为什么需要这个功能,这个功能带来什么样的价值。

    用户故事通常按照如下的格式来表达:作为一个<角色>, 我想要<活动>, 以便于<商业价值>

    比如:作为一名酒店前端开发人员,我期望查看所有酒店页面的页面打开时间,以便了解哪些页面需要进行技能优化。

    一个好的用户故事同时要符合INVEST原则,INVEST原则分别是:

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

    注意:

    • 角色的范围不能过大,比如是作为一名“用户”,这样是的不被接受的。
    • 商业价值也不能大而宽泛,比如,能为公司创造业绩。如果要写也一定要对业绩做初步估算,比如,预期会给公司带来每月1万张订单。

    验收条件 是开发完成后检验的标准,所以一定要认真填写,否则可能开发出来的东西与预期不达标。

    以上面的“导出+CN酒店每天的PV、UV等流量数据”为例,它的验收条件可以为:

    • 1)   可以为每个用户设置是否拥有此导出权限
    • 2)   导出的时间可以细化的天。即可导出每天的流量。
    • 3)   导出数据的最大时间跨度为31天
    • 4)   对于导出数据做好日志记录,后期可查是谁进行了导出。
    • 5)   导出的字段包括:PV、UV、跳出率、新访客占比。

      价值验证 说明如何跟踪上线后的效果

    2、Sprint 计划会议 1

    目标:定出 Sprint 目标和既定产品 Backlog。

    2.1 会议准备

    □ 所有会议资源都已预订

    □ 会议室

    □ 投影仪

    □ 笔记本

    □ 在会议前一天确定议程,将目标和议程发送给所有与会者

    □ 原始需求人(可选择不来)

    □ 产品负责人

    □ Scrum Master

    □ 开发团队

    □ 已按优先级排列产品 Backlog整理完毕

    □ Sprint 时间表已经安排

    □ Sprint 计划会议 1 的时间安排

    □ Sprint 计划会议 2 的时间安排

    □ Sprint 的第一天已确定

    □ Sprint 的最后一天已确定

    □ Scrum 每日例会的时间安排

    □ Sprint 验收会议的时间安排

    □ Sprint 回顾会议的时间安排

    2.2 会议议程

    □ 把 Sprint 时间表公开给所有人

    □ 产品负责人向团队产品阐述需求(用户故事)

    □ 开发人员对用户故事不清楚的点可以及时提出。

    □ 产品负责人或者原始需求者负责解答不清楚的故事点。

    □ 如果讨论现场发现有遗漏的需求,可由产品负责人添加至产品Backlog。

    □ 如果对需求的优先级存在异议,可会上讨论,确定最终的执行顺序。

    □ 产品负责人& 需求方和小组成员相互认可这 Sprint 目标和既定产品 Backlog

    2.3 会议结果

    □ 为 Sprint 计划会议2的进行准备好既定产品 Backlog

    2.4 补充内容

    产品Backlog模板(基本同需求模板)

    需求种类 优先级 需求类型 需求标题 详细描述 验收条件 提交时间 需求人 备注 跟进人 预计完成时间 实际完成时间 Sprint版本号 处理情况
                               

    处理情况可从以下几种类型中选择

    • –    等待处理
    • –    正在进行
    • –    已经完成
    • –    不予处理
    • –    暂时搁置
    • –    需要讨论

    3、Sprint 计划会议 2

    目标:确定所有任务,生成 Sprint Backlog,确认 Sprint 目标

    3.1 会议准备

    □ 要求原始需求者离开会议,参会人员为

    □ 产品负责人

    □ Scrum Master

    □ 开发团队

    □ 在Sprint 计划会议1后10分钟举行

    □ Sprint 计划会议1中整理的既定产品 Backlog

    □  任务估时牌(按1,2,3,5,8,13估算)

    3.2 会议进程

    □ 团队成员按顺序分析既定产品 Backlog的讨论实现细节

    □ 编码

    □ 测试

    □ 代码审核

    □ 学习新技术

    □ 编写文档

    □ 部署

    □ 上传

    □ 可看情况确定是否使用扑克估时

    □ 任务超过一天时,需要拆成多个小任务

    □ 如果团队评估下来任务过多,可和产品负责人一起删减任务

    □ 如果团队评估下来任务过少,可和产品负责人一起从产品Blaclog中引入新的需求。

    3.3 会议结果

    □ 将最终确认的可完成的需求清单邮件至

    □ 原始需求人

    □ 产品负责人

    □ Scrum Master

    □ 开发团队

    □ 将最终确认的任务列表邮件至

    □ 产品负责人

    □ Scrum Master

    □ 开发团队

    3.4 补充内容

    Sprint Backlog模板

    优先级 需求标题 详细描述 验收条件 需求人 跟进人 处理人 任务描述 处理日期 估时 实际耗时
                         

    需求和任务是一对多的关系,及一个需求可以产生多个任务,任务可以是程序类描述,如“数据数据库设计”

    4、Scrum 每日例会

    目标:团队成员间工作进度的沟通和协调

    4.1 会议准备

    □ 邀请与会者

    □ 外部团队协助人员(如有有需要的话)

    □ 原始需求人(只有选择是否参加,过程中不可发言)

    □ 在 Sprint Backlog 上的所有任务都是可以增删修改,可重排序的

    □ 一台电脑,中间标识任务的状态,可设为“待处理”,“正在处理”,“已完成”的。

    4.2 会议进程

    注意:

    • – 会议限定在15分钟内
    • – 团队里的每个成员都必须回答以下三个问题,并考虑其相关的行动。

    □ 上次会议时的任务哪些已经完成?

    □把任务从“正在处理”状态转为“已完成”状态

    □ 下一次会议之前,你计划完成什么任务?

    □ 如果任务状态为“待处理”:转为“正在处理”状态

    □ 如果任务不在 Sprint Backlog 上:添加这个任务

    □ 如果任务不能在一天内完成:把这任务细分成多个任务

    □ 如果任务可以在一天内完成:把任务状态设为“正在处理”

    □ 如果任务状态已经是“正在处理”:询问是否存在阻碍任务完成得问题

    □ 有什么问题阻碍了你的开发

    □ 如果有阻碍你开发进度的问题:把该障碍加入到障碍 Backlog 中,Scrum Master负责记录

    □ 如果展开了一个问题的讨论

    □ 提醒团队的成员们注意把精力集中在回答关键问题上

    □ 如果相关人员想发表些言论

    □ 礼貌地提醒他,该会议只允许让小组成员讨论

    4.3 会议结果

    □ 得到最新的障碍 Backlog

    □ 得到最新的 Sprint Backlog

    □ 最新的工作进度图(燃尽图)

    □ 第一次的例会创建一封邮件,由Scrum Master会议后将例会内容回复此邮件。

    4.4 障碍Backlog

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

    10 大典型障碍

    –    会议规则没能被遵循

    –    产品远景和 Sprint 目标不清晰

    –    没有产品负责人负责回答提问

    –    产品 Backlog 未能按商业价值区分优先级

    –    并不是所有负责交付产品的人员都是团队里的成员

    –    Scrum Master 还要处理其他任务,不能集中精力

    –    团队人数过多

    –    团队没有能坐在一起工作的空间

    –    团队的 Sprint Backlog 混乱

    –    中间遇到了技术难题

    5、Sprint 验收会议

    目标:根据团队这次 Sprint 所发布的版本,评审相关的 Backlog 中的问题,检查是否已达到 Sprint 的目标。

    5.1 会议准备

    □ 所有会议资源都已预订

    □ 会议室

    □ 投影仪

    □ 笔记本

    □ 在会议前一天确定议程,将目标和议程发送给所有与会者

    □ 原始需求人(可选择不来)

    □ 产品负责人

    □ Scrum Master

    □ 开发团队

    □ 对于每个人来说 Sprint 目标都是公开的

    □ 对每个人来说既定产品 Backlog 是公开的,可获取的

    5.2 会议进程

    □ 团队按 Backlog 中的问题,逐个地介绍这次 Sprint 的结果,和演示新功能。

    □ 如果产品负责人或需求方想要改变功能:添加一个新问题到产品 Backlog 中

    □ 如果对功能有一个新的想法:添加一个新问题到产品 Backlog 中

    □ 如果小组报告项目遇到阻碍现在还没能解决:把该障碍加入到障碍 Backlog

    5.3 会议结果

    □ 对这次 Sprint 的结果和整个产品的开发状态的共识

    6、Sprint 回顾会议

    目标:通过总结以往的实践经验来提高团队生产力。

    注意:主要指导原则:不管我们现在发现了什么问题,我们必须懂得并坚信每个人通过他们当时所知的,他所拥有的技能和可得到的资源,在限定的环境下,都尽其所能做出了最好的成绩。

    6.1 会议准备

    □ 邀请与会者:

    □ Scrum Master

    □ 团队所有成员

    □ 产品负责人(可选)

    □ 附属工具

    □ 便签纸

    □ 白板

    □ 在白板上写上主要指导原则

    □ 在白板上画上一个至少三页纸连在一起长的时间轴

    □ 在白板上写上“我们的成功经验是什么”

    □ 在白板上写上“有什么能够改进”

    □ 在白板上写上“谁负责”,然后分成两个区域——“团队”和“公司”

    附属工具:

    6.2 会议进程

    □ 介绍会议目标

    □ 介绍会议主要指导原则

    □ 在时间轴上,标记出 Sprint 的开始和结束时间

    □ 向与会者解说如何使用该便签纸进行工作

    □ 派发便签,并且让每人写上他们认为这次 Sprint 中最为重要的事,限时 5 分钟

    □ 每个与会者轮流把他的贴纸贴到白板的时间轴上,并用两句话来解说这事有什么特别的地方

    □ 分发便签纸,并让每人写上“我们的成功经验是什么”,限时5分钟

    □ 每个与会者轮流把他的贴纸贴到白板“我们的成功经验是什么”的区域上,并解说。

    □ 分发便签纸,并让每人写上“有什么能够改进的”,限时5分钟

    □ 每个与会者轮流把他的贴纸贴到白板“有什么能够改进的”的区域上,并解说。

    □ 对于挂纸板上“有什么能够改进”的区域中的每一项

    □ 询问团队“谁去负责解决这个问题?”

    □ 把便签纸移到挂纸板中“谁负责”的区域中

    □ 和团队一起把这些区域按优先次序排好

    □ 给会议做个总结

    □每个与会者对 Sprint 回顾会议作简短的回馈

    6.3 会议结果

    □ 白板上“谁负责”这栏对于公司内所有人是公开的

    □ 把与公司范围相关的障碍增加到障碍 Backlog 中去

    □ 把与团队范围相关的障碍增加到障碍 Backlog 中去

    □ 整理所有会议结果,邮件至团队中所有人

     

     

     

    注明:

    案例分析参考博客:      http://www.biaodianfu.com/scrum-flow.html

    Scrum一些场景图参考:http://blog.csdn.net/bihailan123/article/details/50708863

    文章写的很简明,谢谢以上两位博主!

     

    转载于:https://www.cnblogs.com/X-knight/p/5325331.html

    展开全文
  • 敏捷研发(Scrum)

    2018-11-29 09:23:21
    敏捷开发(AD:Agile Development )以用户的需求进化为核心,采用迭代、循序渐进的方法进行软件开发。在敏捷开发中,软件项目在构建初期被切分成多个子项目,各个子项目的成果都经过测试,具备可视、可集成和可运行...

    敏捷研发

    1. 什么是敏捷研发?

    敏捷开发(AD:Agile Development )以用户的需求进化为核心,采用迭代、循序渐进的方法进行软件开发。在敏捷开发中,软件项目在构建初期被切分成多个子项目,各个子项目的成果都经过测试,具备可视、可集成和可运行使用的特征。换言之,就是把一个大项目分为多个相互联系,但也可独立运行的小项目,并分别完成,在此过程中软件一直处于可使用状态。

    敏捷的构成:敏捷=理念+优秀实践+具体应用

    1. 敏捷宣言

    1个体和交互胜过过程和工具
    是软件开发中最重要的因素。开发团队成员之间有效的交流、沟通与协作,比单纯的编程能力更为重要。人与人面对面的交流,是最有效、最迅速的交换信息的方式。
    2可以工作的软件胜过面面具到的文档
    过多的文档需要开发人员花费大量时间来维护。文档应该是为程序服务的,因此应当短小精悍、易于维护,而且主题突出。敏捷方法认为最根本的文档就是源码。
    3客户合作胜过合同谈判
    客户对产品的需求是不断变化的,试图在合同中规定项目的细节和进度显然无法应对不断变化的需求。只有开发团队和客户之间真诚的协作,加上及时的与客户交流反馈,才能让项目走向成功。



    4响应变化胜过遵循计划
    客户的需求可能在项目开发过程中不断变化,即使是在合同谈判阶段确定的需求,也可能在客户看见了逐渐成型的产品之后而发生改变。敏捷方法欢迎并且随时准备应对变化。制定计划的时候应该尽量简洁、灵活,使其能适应技术和需求方面的变化。可以说,随时响应变化的能力往往决定着一个项目的成败。

    并不是右边的不重要,只是相比而言左边的更重要。在敏捷研发中,左右两边的内容都是相当重要的

    1. 敏捷原则

    1)我们最重要的目标,是通过持续不断地及早交付有价值的软件使客户满意。

    Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.

    2欢迎需求变化,即使在开发后期也一样。为了客户的竞争优势,敏捷过程掌控变化。

    Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage.

    3经常地交付可工作的软件,相隔几星期或一两个月,倾向于采取较短的周期。

    Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.

    4)业务人员和开发人员必须相互合作,项目中的每一天都不例外。

    Business people and developers must work together daily throughout the project.

    5激发个体的斗志,以他们为核心搭建项目。提供所需的环境和支援,辅以信任,从而达成目标。

    Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.

    6)不论团队内外,传递信息效果最好效率也最高的方式是面对面的交谈。

    The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.

    7可工作的软件是进度的首要度量标准。

    Working software is the primary measure of progress.

    8)敏捷过程倡导可持续开发。责任人、开发人员和用户要能够共同维持其步调稳定延续。

    Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.

    9)坚持不懈地追求技术卓越和良好设计,敏捷能力由此增强。

    Continuous attention to technical excellence and good design enhances agility.

    10)以简洁为本,它是极力减少不必要工作量的艺术。

    Simplicity--the art of maximizing the amount of work not done--is essential.

    11)最好的架构、需求和设计出自自组织团队

    The best architectures, requirements, and designs emerge from self-organizing teams.

    12)团队定期地反思如何能提高成效,并依此调整自身的举止表现。

    At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

    1. 敏捷理念

    Value:聚焦客户价值,消除浪费

    Team:激发团队潜能,加强协作

    Adapting:不能断调整以适应变化

    1. 敏捷实践

    http://sjyuan.cc/assets/images/agile/main-events-in-one-iteration.png

    1)IPM(Iteration Plan Meeting)迭代计划会议主要是跟客户保持沟通与信息更新的一个会议。

    2)Regular catch up with client跟客户建立信任关系是合作的基础,而让客户保持愉悦,也是项目成功交付的助推剂。

    3)Standup是一项成本小收益大的活动,做好它是敏捷的第一步。

    4)Story kick-off在一个Story开始前,确保BA, QA, DEV等职能对Story的理解达成一致,并严格按照AC来验收。当然,前提是Story本身是不容置疑的。

    5)Pair结对编程的开发速度通常小于简单地将一个人的开发速度乘以2,但它依然能创造价值:知识的共享,代码质量的提高,缺陷率的降低。

    6)TDD,测试驱动开发,这项人人都称赞、却很少有人真的去做的活动,不应该只是一个被供奉起来的神。接地气,再接地气一点。

    7)Code Review不可否认的一个事实:人人都爱整洁的代码。而一个人单独编码难免会耍一些小聪明,或引入一些自身习惯难以察觉的不良代码。Code Review能让你提高警惕,并改善代码的质量。

    8)Showcase不管客户有多忙,也要定期让客户确认自己的期望是否得到满足。在签订合同前,要跟客户达成一致:Showcase的地位不可动摇。

    9)CI持续集成.没有CI的项目开发是在耍流氓。CI在Agile中是一项最基础的设施,它通过自动化来提供有效的反馈机制以及高效的部署,大大降低代了码集成和项目交付的风险。

    10)Retro即Retrospective的简写,即回顾。团队专注于交付目标,埋头干活的同时,也要懂得停下来总结过去,并更好地抬头看路。

    以上仅仅是敏捷实践中的一种,敏捷的实践是多种多样(如极限编程XP、FDD、DDD等等)。

    • SCRUM
    1. 什么是Scrum?

    Scrum的英文意思是橄榄球运动的一个专业术语,表示“争球”的动作;把一个开发流程敏捷框架的名字取名为Scrum,我想你一定能想象出你的开发团队在开发一个项目时,大家像打橄榄球一样迅速、富有战斗激情、人人你争我抢地完成它,你一定会感到非常兴奋的。Scrum 是一个用于开发和维护复杂产品的框架,是一个增量的、迭代的开发过程。

    而Scrum就是这样的一个敏捷框架,运用该框架,你就能看到你团队高效的工作。(敏捷实践中最流行的实践之一)

    http://upload-images.jianshu.io/upload_images/6272602-7c5b5fae96a2141d.gif?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240

     

    1. Scrum中的角色

    Scrum MasterSM
    保护团队
    不受外界干扰,是团队的领导者及推进者,负责提升 Scrum 团队的工作效率,控制 Scrum 中的“检视和适应”周期过程。与 Product Owner 一起将投资产出最大化,他确保所有的利益相关者都可以理解敏捷和尊重敏捷的理念。
    PS:Scrum Master是Scrum 团队中的贡献者,一般是由Scrum 团队成员担任(专职的Scrum Master比较少,专职的一般是会在敏捷转型初期设立,为了更好的进行敏捷过度);Scrum团队中任何一个成员都可以担任Scrum Master的,个人建议有比较丰富敏捷经验的研发leader或者架构师担任,不建议项目负责人或项目经理担任Scrum Master。


    TeamST)——由开发人员、测试人员、美工设计、DBA等软件研发流程中各职能人员组成
    团队负责
    交付产品并对其质量负责,团队与所有提出产品需求的人一起工作,包括客户和最终用户,并共同创建 Product Backlog 。团队按照大家的共识来创建功能设计、测试 Backlog 条目交付产品。

    PS:软件的实现者,Team运作的好坏直接关系软件产出的质量。Team是具有软件交付能力的特性团队(Team中必须包含开发人员,但不一定包含测试人员、美工设计、DBA、BA\SA等其他职能人员)。对于Team中人员职能类别越多,软件可交付的范围越大、整体管理协调的难度越大;同时Team中人员整体软件水平越高,出现高品质软件的机会也就越大,整体管理协调难度会越小。

    Product Owner
    从业务角度驱动项目,传播产品的明确愿景,并定义其主要特性。Product Owner 的主要职责是确保团队只开发对于最重要的 Backlog 条目,在 Sprint 中帮助团队完成自己的工作,不干扰团队成员,并迅速提供团队需要的所有信息。
    PS:Product Owner是Scrum团队的决策者,它定义整体软件产品的内容及发展方向。一般是由产品负责人、产品经理、运营人员,部分情况由BA\SA担任。

     

    以下个人不建议归纳为角色,下面更像是人员组:
    User——最终用户、运营人员、系统使用人员等
    很多人都可能成为最终用户,比如市场部人员、真正的最终用户、最好的领域专家,也可能是因其专业知识而被雇佣的资讯顾问。最终用户会根据自己的业务知识定义产品,并告知团队自己的期望,提出请求。

    PS:软件的主要受众群体,需求的主要来源。


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

    PS:组织内部管理者,做出的决定对团队来说影响都是巨大的,是团队的最需警惕和寻求支持的对象。


    Customer

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

     

    1. 什么是Sprint

    Sprint 本意为“冲刺”,指迭代周期,长度通常是一至六周(建议:迭代节奏保持在2周,刚接触敏捷的Scrum团队采用4周一个迭代,每月逐步递减,直至保持2周一个迭代)。

    1. Scrum中的产出物
    1. Product Backlog(PB

    Backlog 待开发项,积压的任务
    产品 Backlog 是指产品待办事项的集合,其中事务有优先级判断,先处理优先级高的事项。包括了所有需要交付的内容,其内容根据业务需求的价值顺序排列,每个 Backlog 的优先级是可以调整的,需求是可以增减的,因此产品 Backlog 将根据不断增长来持续驱动维护。

     

    1. Product Backlog Items (PBI

    Product Backlog Items 待开发需求的分组。

    Product Backlog Items 更多的意义是在于规划,其内容根据业务需求的价值顺序排列;根据公司运作方式,将PB分解成PBI,规划给各个scrum执行或多个Sprint执行。

     

    1. Sprint Backlog(SB

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

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

     

    1. User Story

    1)User Story 来描述了对用户、系统或软件购买者有价值的功能。

     

    2)用户故事通常按照如下的格式来表达:

    英文:

    As a <Role>, I want to <Activity>, so that <Business Value>.

    中文:

    作为一个<角色>, 我想要<活动>, 以便于<商业价值>

     

    3)用户故事的六个特性- INVEST

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

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

    独立性(Independent)要尽可能的让一个用户故事独立于其他的用户故事。用户故事之间的依赖使得制定计划,确定优先级,工作量估算都变得很困难。通常我们可以通过组合用户故事和分解用户故事来减少依赖性。

     

    可协商性(Negotiable)一个用户故事的内容要是可以协商的,用户故事不是合同。一个用户故事卡片上只是对用户故事的一个简短的描述,不包括太多的细节。具体的细节在沟通阶段产出。一个用户故事卡带有了太多的细节,实际上限制了和用户的沟通。

     

    有价值(Valuable)每个故事必须对客户具有价值(无论是用户还是购买方)。一个让用户故事有价值的好方法是让客户来写下它们。一旦一个客户意识到这是一个用户故事并不是一个契约而且可以进行协商的时候,他们将非常乐意写下故事。

     

    可以估算性(Estimable)开发团队需要去估计一个用户故事以便确定优先级,工作量,安排计划。但是让开发者难以估计故事的问题来自:对于领域知识的缺乏(这种情况下需要更多的沟通),或者故事太大了(这时需要把故事切分成小些的)。

     

    短小(Small)一个好的故事在工作量上要尽量短小,最好不要超过10个理想人/天的工作量(这里是按2周的迭代周期计算制定的最大标准,建议一个用户故事的粒度在3人/天左右),至少要确保的是在一个迭代或Sprint中能够完成。用户故事越大,在安排计划,工作量估算等方面的风险就会越大。

     

    可测试性(Testable)一个用户故事要是可以测试的,以便于确认它是可以完成的。如果一个用户故事不能够测试,那么你就无法知道它什么时候可以完成。

    具体用户故事相关内容可以 参考《用户故事地图》、《用户故事与敏捷方法》、《超越需求 敏捷思维模式下的分析》

     

    1. Task

    Task 是每个用户故事实际需要做的任务。

    为了能够及时,高效地完成每个 Story,Scrum 团队会把每个 Story 分解成若干个 Task。
     

    1. 障碍 Backlog

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

     

    1. Scrum 工具
    1. 任务板(看板)

     

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

    任务板有4列:
    •选择好的 Product Backlog:按照优先级,将团队在当前 Sprint 中要着手的 Product Backlog 条目或是故事放在该列中。


    待完成的任务:要完成一个故事,你得完成一些任务。在 Sprint 规划会议中,或是在进行当前 Sprint 中,收集所有特定 Backlog 条目需要完成的新任务,并将它们放入该列。


    进行中的工作:当团队成员开始某个任务后,他会将该任务对应的卡片放到“进行中的工作”列中。从上个每日 Scrum 例会开始,没有完成的任务都会放在该列中,并在上面做标记(通常是个红点)。如果某个任务在“待完成任务”列中所处时间超过一天,就尽量将该任务分为更小 的部分,然后把新任务放到那一列,移除其所属大任务卡片。如果一个新任务因为某个障碍无法完成,就会得到一个红点标记,Scrum Master 就会记下一个障碍。


    完成:当一个任务卡完成后,完成此任务的成员将其放入“完成”列,并开始选取下一张任务卡

     

     

    1. 燃尽图

    跟踪进度要由团队来完成,燃尽图的横轴表示整个Sprint 的总时间,纵轴表示 Sprint 中所有的任务,其单位可以是小时,人天等。一般来说,燃尽图有”Sprint燃尽图”和”Release燃尽图”之分。


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

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

     

    1. 规划扑克牌

    规划扑克牌即“计划扑克”(Planning Poker)是一种标有一系列数字的扑克牌。用于敏捷开发的Scrum开发团队估计故事(Story)的故事点(Story Point)。

     

    计划扑克玩法:

    1. 参加游戏的开发人每人各拿一叠扑克牌,牌上有不同的数字。
    2. 客户或者产品责任人为大家挑选 1 个 Story(Backlog),并简单解释其功能,以供大家讨论。
    3. 每个游戏参加者按自己的理解来估计完成这个 Story 所需的时间,从自己手中的牌里选 1 张合适数字的牌,并发展示给大家。
    4. 游戏参加者各自解释选择这个数字的原因,尤其是数字最大和最小的人。
    5. 根据每个游戏参加者的解释,重新估计时间并再次出牌,直到大家的估计值比较平均为止。
    1. 通用会议规则

    1)基本要求
    •每次会议都要
    准时开始、准时结束
    每次会议都采取开放形式,所有人都可以参加。(这是敏捷开放的体现。由于国情及文化等原因,暂时无法达到面向所有人的,建议采用邀请的形式)

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

    声明会议纪律
     

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

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

     

    1. 团队建设

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

    PS:具体团队建设全职和兼职中包含哪些职能,一般都是比较灵活的,但整个Scrum 团队必须保证在5—9 人之间,全职团队必须包含产品及开发人员。

     

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

     

    1. 敏捷的重要会议
    1. 产品计划会(Product Planning Meeting)--非必要

    Scrum 框架上并没有相应会议定义,个人认为在产品纳入sping前很有必要开这个会议,特别是体量庞大的产品

    会议目的
    •产品代码研发前的动员,宣讲产品理念、产品业务规划。
    •Product Backlog 拆解、形成Product Backlog Items。
    • Release Planning ,规划发布计划
    • 规划人员安排

     

    会议输出
    •Product Backlog Items
    •发布计划
    •规划迭代团队投入量


    基本要求
    •成员:Scrum Master、项目经理、客户、manager、
    •无法出席的团队成员要由同伴代表。
    •持续时间:根据产品体量而定,建议控制在2小时以内;在sping开始前
    •举办地点:最好是宽敞的会议室。

     

    1. 每日立会(Daily Standup Meeting)

     

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

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

    基本要求
    •成员:团队、Scrum Master
    •持续时间/举办地点:每天
    5~~15分钟,同样时间,同样地点
    PS:站会没有限定在一天中的什么时候开,个人建议在早上开,这样能更好安排协助解决问题。对于移动看板人任务贴纸,个人认为每个成员都应该养成做完任务及时移动任务贴纸。


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

    会议过程
    •团队聚在看板旁边,面向看板、可以围成环形。
    •从一方开始,谁拿到马克笔,谁向团队伙伴发言。
    •然后该成员
    领取或调整任务板(看板)上的任务到正确的列中。(应培养团队人员完成任务后,自觉移动任务的习惯)
    如果该成员遇到问题或障碍,就要将其报告给 Scrum Master。
    •每个团队成员重复步骤2到步骤5。

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


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

     

    1. Sprint规划会议(Sprint planning meeting)

    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 条目。

     

    扑克牌估算

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

    常见问题

    1、为什么任务要分给组而不是个人?
    答:因为怕出错了牌又说不出所以然,这样即使日后他不做这个功能,也对这个功能很了解。

    2、为什么不让最后领任务的人自己估算?
    答:因为他很可能因为不知道某代码可用、不知道某软件不行....而选择了错误的实现方法。

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

     

    1. Sprint评审会议(Review Meeting)

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

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

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

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

    持续时间:60分钟,在 Sprint 结束时进行。(
    持续时间应与迭代时长成正比;60x迭代周数,建议在30~120分钟之间,不宜过长或过短。

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

    注意事项:
    •不要展示不可能发布的产品增量。
    •Scrum Master 不要负责展示结果。
    •团队不要针对 Product Owner 展示。

    1. Sprint反思会议(Retrospective Meeting)

     

    http://sjyuan.cc/assets/images/agile/agile-development-summary-of-project-e-retro.jpg

     

    会议目的
    •该会议的对应隐喻:医疗诊断!其目是:

    检视当前这个 Sprint 中关于人、关系、过程和工具的情况如何

    找出并加以排序做得好的和潜在需要改进的主要方面;

    制定改进 Scrum 团队工作方式的计划;


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

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

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

    会议输出
    •障碍 Backlog 的输入。
    •团队 Backlog 的输入。

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

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

     

    • 对于敏捷及Scrum的思考
    1. 为什么Scrum不行?

    《为什么Scrum 不行》作者陈皓在里面加入了自己的分析

    Reason 1: Scrum的基石是相信人。创造一个安全的环境,这样每个人都能相互学习,相互直言。但是,这是不行的,这世上有很多人并不关心这些,而且政治和竞争到处都是,办公室里无小事,你和别人交心,你相信他们,最终受伤的你自己。你真的以为那里有空间让你可以去犯错,去冒险吗?

     

    Reason 2: Scrum认为只要给员工足够多的自由员工就能做得最好。这该死的理论是基于什么玩意?不可能,人的天性是懒惰的,他们才不会把事做好的,他们只会做相应报酬的工作量,还可能基本甚至达不到其相应的报酬,大多数人都在混日子。尤其是和经理比起来,谁不想能尽快地成为经理或Team leader啊,因为那样他们就可以即不干活,又挣得多。另外,你给他们自由,你就会发现,他们会只会做他们感兴趣的事,要么聊QQ,要么打游戏,看闲书,反正不干正事。直到你催了,他们才动一动。

     

    Reason 3: 因为前面的原因,所以,我们仍然要把一个PM放在Scrum团队的上面做管理,这样才会有产出。于是,PM给团队分配任何,管得细枝末节,事无巨细,天天让你做进度汇报,等等。直至把团队拖垮。

     

    Reason 4:Scrum只不过是一个流程。这世上有太多的流程,尤其是那那些执行CMMI的公司。几乎所有玩CMMI流程的公司,你都能看到的是员工都是那一副副难看的脸。所以,Scrum的流程同样会这样。因为这些都不是开发团队自发出来的,而是上面管你喜欢不喜欢按给你的。Scrum根本不可能增进你的软件质量和技术,只能是优秀的人才才可能!使用Scrum的公司都是些吝啬鬼,他们不愿花大钱招优秀的人,他们妄图使用Scrum这种东西让现有的这些廉价劳动力发挥更大的生产效率,Scrum成了push程序员最有用的工具。

     

    Reason 5:Scrum delivers ‘business value’不是这样的,实际上,Scrum不可能。这有很多原因。真正了解业务的那帮人根本不可能加入项目团队,那些人谁TMD愿意和苦逼的技术人员加班啊。 那些人喜欢和我们的用户吃吃喝喝,花天酒地的,根本不会和你们那些奇怪的东西(如:backlog)或是那堆ugly的内向古怪的技术人员打交道,更别说什么技术了。所以,你的团队就像一个客服团队或救火队一样疲于奔命。

     

    Reason 6: 一个敏捷的团队应该是持续进步的。这就是为什么Scrum总是在问什么干得好,什么需要改进,并定义行动方案。你真的以为员工想进步吗?让他们不得不去想想自己和团队怎么进步,然后他们还不得不去执行行动方案。别天真了,人的天性是不喜欢改变的,人的天性是习惯于一些按部就搬的事,也许那样做令人讨厌,但是人家还是能干点东西出来。如果你逼着人家改变,你就是在压迫人家,人家自然会反抗。

     

    Reason 7:Product Owner专注于 ‘what’ 和 ‘why’ 的问题,开发团队决定 ‘how’。很不错的分工,于是可以造就一个即高速有重质量的团队。然而,这根本不行。你的Product Owner马上就想要这个功能,他才不管你的软件开发的技术难题,人家只要快,要你meet deadline,要你给我们重要的客户做出承诺。另外,你千万不要以为你们可以轰走这个初级的product owner,因为他的后台是直接汇报到高层管理。你作为一个程序员可能只是其个小部门的一个小喽啰,或者只是外包公司,你觉得可能吗?你觉得建立信任可能吗?

     

    Reason 8: 软件质量和生产率成正比。也就是说,质量越高,生产率越高。如果质量不高,你开发效率就会低下,但是谁管呢?我们朝九晚五的上班,质量好了也是做8小时,质量差了也是做8小时,无所为嘛。另外,我们的project manager (或者是Scrum master!) 总是会批评我们没有按计划完成。所以,这根本不可能。

     

    Reason 9: “是的,如果我们只做需要的功能,那么我们就会最低的成本,对吗?,为什么这世上总是会有这些幼稚的人?这种事怎么可能啊。很多很多的银行或保险公司的项目在你还没有启动项目前就谈好了一个价格(可能还会有回扣),为了打单子,销售什么都干得出来,让你去做项目是因为你是廉价劳动力,而且,他们会不断地加需求,因为软件合同谈好的价格时候,连需求都没有,你去做了才有,还是模糊和不确定或根本就是错的,然后需求是越来越多,越改越多。等你精疲力尽的时候,你才意识到,销售早就把你卖了。

     

    上述几点,很多确实是反映了中国软件研发的现状(不管是CMMI、敏捷或者其他模式):软件生命周期内各个环节的人员各自为政,指标考核不切实际一塌糊涂,盲目追求利益,忽略软件质量……

     

    大部份人认为scrum在中国人的性格特质下,更适合那些凝聚力比较高的、自我驱动能力比较强的、技术水平比较成熟的、具备有号召力的leader(作为组织者、评判者和关系协调者)、已经具备一定沟通条件的技术团队。那么中国哪些拥有高凝聚力、高驱动力、高协调力、高技术水平的团队多么?个人认为,数量是很多的,但比例很低。

     

    那么是不是说我们不适合开展敏捷?

     

    团队素质确实是软件生产能力的表现。高素质的团队不管应用何种模式,都能有比较高的产出。那么我们为什么应用敏捷、CMMI意义呢?直接建立高素质团队不就行了?

     

    1. 为什么要敏捷

    敏捷要求那么高,Scrum在国内那么水土不服。就如同“没有人喜欢敏捷,但我们不得不敏捷。就像没有人喜欢工作,但你必须工作。”

    试想一下,拿到一份完整详尽的需求文档,逐个功能Coding,测试部署上线。不需要再次确认需求,不会有人打断思路。没有需求更改,只要自己不犯错,不存在推倒重来这才是大部分开发人员最舒服的工作方式吧,简直太完美了。但它很像瀑布,一点都不敏捷。

    既然我们喜欢的工作方式是传统的、瀑布的,为什么要敏捷?这还不都是市场环境逼的。今天的市场向我们提出了三个问题:

    1. 如何做出真正满足用户需求的产品?

    我不确定这世上是否有人可以做到,他所做出的全部决定都是对的。但绝大多数人是无法一次性做出真正满足用户需求的产品的。我们无法预测未来,我们必须通过一次次的测试,去寻找用户需要的产品是什么?想要更快地获得好的产品,必须迅速将产品推向市场,快速试验,避免走弯路。

    1. 如何满足不断变化的用户需求?

    今天所有的事情的都在快速变化,用户的需求也在变化。毫不夸张地说,我们正在全力开发的一些功能,当它们上线的时候,我们的用户已经不再需要了。我们没有办法让一切不变,我们只能选择去拥抱变化。

    1. 如何同时满足不同层次用户的需求?

    过去我们的产品会遵循产品生命周期,早期追求新奇的尝鲜者,中期普通大众,后期落后者。今天,产品的生命周期变化非常地快,我们可能会同时面对尝鲜者、普通大众、落后者,不同的用户类型的需求是不一样的,你如何满足他们?我们必须快速响应,没法快速响应,就没法留住用户,没有用户就没有一切。

    迅速将产品推向市场,拥抱变化、快速响应。今天的市场向所有的从业者提出了一个要求:拥有应对快速变化的需求的软件开发能力。而敏捷就是赋予团队应对快速变化的需求的软件开发能力的方法,而这就是敏捷流行的原因。

     

    1. 我们要怎么进行敏捷实践的

     

    1. 敏捷是一种信仰

    相信信仰的力量,信仰的力量不可估量。若团队对敏捷都不认可,那么开展敏捷几乎就没有什么意义的,敏捷永远都开展不好。

    1. 信任

    要相应敏捷团队的成员利益是一致。所有产出价值,都是团队创造的,自身应该相信团队成员都是为共同利益奋斗的。

    1. 拥抱变化

    敏捷研发是一个渐近明晰的过程,产品需求会应各种因素不断的调整,故在没有明晰前研发任务是会不断的调整。团队应该要有应对调整的原则,团队成员应该积极响应变化。

    1. 明确

    团队成员应形成团队的实践:团队成员应明白自己在敏捷整体流程中,应该明确在各个节点自己的任务和产出;团队应该要有明确的团队原则;团队成员应该对迭代目标有明确的认知。

    1. 团队素质提升

    应注重团队的成员整体素质的提升,不仅仅是团队成员本身技能上的提升,更多是敏捷团队整体的素质提升(如团队成员间的沟通、协作、应变等)。应注重团队内部问题的消化、各职能成员的知识分享和总结、各领域技术的应用、团队资料的传承等等。

    1. 保护团队

    减少对团队人员的干扰:团队成员尽量保持相应稳定,即使是团队成员调整,也应有相应的措施使团队成员互相融合,团队尽快恢复本身素质;各个环节减少干扰,保证各环节团队人员能有相对舒适的环境,以保证产出质量。

    1. 发挥团队成员的潜力

    提倡团队成员在敏捷各个环节参与,发掘团队成员各个职能技术的潜力,给与团队成员跨职能工作的几乎;通过技术分享、应用,让团队成员在参与中有更多的认知。

     

    只要做到由敏捷的理念出发,运用好各种优秀实践,充分结合自身团队情况,随着团队的提升,敏捷会越来越好。

    展开全文
  • 昨天在东莞客户封闭开发的现场,观察了一个产品开发组四个小组实施站立会议的情况,分析了他们执行的优缺点,对如何执行站立会议,如何获得站立会议的成功进行了再次归纳总结,要点如下:1 任务的分配与领用i)任务的...

    昨天在东莞客户封闭开发的现场,观察了一个产品开发组四个小组实施站立会议的情况,分析了他们执行的优缺点,对如何执行站立会议,如何获得站立会议的成功进行了再次归纳总结,要点如下:

    1 任务的分配与领用
    i)任务的责任人要明确;
    ii)任务的颗粒度小于2天;
    iii)如果有的任务颗粒度实在无法拆分到2天以内,则需要设置中间的检查点;
    iv)任务的完成时间要明确;
    v)任务的完成标准要明确;
    vi)任务识别的要尽可能完备,不要在过程中增加很多遗漏的任务。在识别任务时,团队中的各个角色都要参与,要充分讨论。
    vii)增加、修改的任务要增加小贴纸明确地在看板中标识出来,这些任务可以采用不同颜色的贴纸标识出来。
    viii)高层经理不要越级直接给团队成员下达任务。

    2 任务的完工检查
    i)不能只靠责任人汇报说完成了就认为任务已经完成了,应该有检查,如果是编码,则要通过了规范符合性的检查、工具的静态检查、人工的代码走查或单元测试,并通过客户代表的确认,如果是编写文档,则应该通过了评审,如果是预研,则应该展示了预研的结果。
    ii)要区分任务的完成与需求的完成。需求的完成需要多个任务完成的支持,不但要跟踪任务的进展,也要跟踪需求的进展。如果不是采用迭代的模型,而是采用瀑布的模型,可以定义一个任务进展的内部准则,比如对于一个USE CASE,如果需求定义完成,则任务这个需求完成了10%,如果详细设计完成,认为这个需求完成了30%,如果代码完成,则认为任务完成了50%,如果单元测试通过,则认为这个需求完成了70%,如果系统测试完成则认为完成了100%。

    3 进展的跟踪
      i)采用燃烧图标识每个小组的进展,每天站立会议完成后更新燃烧图。
      ii)采用燃烧图标识整个产品开发团队的进展,可以每天或2天等更新燃烧图。
    iii)每个小组、整个产品的进展都要及时跟踪进展。不能关注了局部,忽略了整体。

    4 站立会议
    i)每天定时、定地开站立会议,不需要事先通知;
    ii) 在站立会议上每个人当且仅当回答3个问题:
      昨天完成了什么?
      有什么难题需要别人帮助解决的?
      今天做什么?
    iii)在汇报每个人的进展时,不需要汇报是如何做的,将要如何做。
    iv)需要别人帮助的问题在会后单独讨论

    5 小组长
    i) 主持会议,确保每位组员发言时不能跑题;
    ii) 可以点评、提醒每个人的工作,但是一定要简短点评;
    iii) 如果对总体情况进行总结,一定要简短。

    6 会议纪律:
      i) 不能迟到,如果迟到就惩罚之;
    ii)只有一个声音在发言,不能一个人在发言,其他人在开小会;
    iii)非本小组的成员,可以旁观,不需要发言;
    iv)不能中途有人退席,有的人汇报完自己的进展后,就退席是不允许的。

    7 物理设施:
      i) 站立会议时一般要有白板,在白板上粘贴的是本项目组的任务状态:未开始的任务,进行中的任务,中断的任务,完成的任务。其实也有一些敏捷的工具,可以电子化sprint backlog,但是还是不如物理的白板更有视觉的冲击力。
    ii) 白板的面积要大,如果所有的任务不能在白板上贴下,则可以只贴本次迭代的或最近一段时间的,比如2周的。
    iii) 如果白板面积不够,可以不用贴纸,手写任务。
    iv) 贴纸容易掉,可以用小磁条粘在白板上或不干胶
    v)限于办公环境,每个小组的站立会议可以错开时间开。

    8 其他注意事项
    i) 一定要当面开会,不能邮件替代站立会议;
    ii) 一定要每天开会,每天跟踪项目的进展;
    iii) 不需要整理会议纪要,除非有其他目的;

    展开全文
  • 站立会议

    2015-02-25 18:31:36
    昨天在东莞客户封闭开发的现场,观察了一个产品开发组四个小组实施站立会议的情况,分析了他们执行的优缺点,对如何执行站立会议,如何获得站立会议的成功进行了再次归纳总结,要点如下: 1 任务的分配与领用 i)...
  • 现在市面上免费的项目管理工具多如牛毛,然而在工作中一旦用错了工具,就不是免费不免费的事了,如果对项目整体进度造成影响,就得不偿失了。本着让项目管理者省钱又省力的目标,我们今天来测评一下那些热门的项目...
1
收藏数 13
精华内容 5
关键字:

敏捷开发看板贴纸颜色