敏捷开发&团队之日常
Posted 点融黑帮
tags:
篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了敏捷开发&团队之日常相关的知识，希望对你有一定的参考价值。
一．什么是敏捷开发
敏捷开发（scrum）是一种以人为核心、迭代、循序渐进的开发方法。在敏捷开发中，软件项目的构建被切分成多个子项目，各个子项目的成果都经过测试，具备集成和可运行的特征。换言之，就是把一个大项目分为多个相互联系，但也可独立运行的小项目，并分别完成，在此过程中软件一直处于可使用状态。因此敏捷开发是一个用于开发和维持复杂产品的框架 ，是一个增量的、迭代的开发过程。
二． 敏捷的特点及呈现
❶敏捷开发模型
✦特点：
不要求需求预先完备定义，支持用户参与，支持需求的渐进式完善和确认，能够适应用户需求的变化。
✦使用范围：
需求复杂、难以确定、动态变化的软件系统。
❷传统瀑布模型
✦特点
简单，分阶段，阶段间存在因果关系，不支持用户参与，要求预先确定需求。
✦使用范围：
需求易于完善定义且不易变更的软件系统。
❸ 敏捷过程展现
➀ 产品负责人PO
主要负责确定产品的功能和达到要求的标准，指定软件的发布日期和交付的内容，同时有权力接受或拒绝开发团队的工作成果。
✚职责：
★ 清晰地表达产品代办事项列表条目；
★ 对产品代办事项列表中的条目进行排序,最好地实现目标和使命，并且最大化实现ROI；
★ 确保开发团队所执行工作的价值；
★ 确保产品代办事项列表对所有人可见、透明、清晰,并且显示 Scrum 团队的下一步工作；
★ 确保开发团队对产品代办事项列表中的条目达到一定程度的理解。
➁ Scrum Master
主要负责整个Scrum流程在项目中的顺利实施和进行，以及清除挡在客户和开发工作之间的沟通障碍。
✚职责：
★领导并指导组织采用 Scrum；
★ 在组织范围内计划 Scrum 的实施；
★ 帮助员工及干系人理解并实施 Scrum 和经验性产品的开发；
★发起能提升Scrum 团队生产力的变革；
★与其他 Scrum Master 一起工作,帮助组织更有效的应用Scrum.
➂ Scrum 开发团队
主要负责软件产品在Scrum规定流程下进行开发工作，包括功能实现、测试等团队，不同职能的团队人数控制在5~10人左右，相互协作使得最终能达到Sprint的目标。
✚职责：
★ 他们是自组织的,没有人(即使是 Scrum Master 都不可以)告诉开发团队如何把产品 代办事项列表变成潜在可发布的功能；
★开发团队是跨职能的,团队作为一个整体拥有创造产品增量所需要的全部技能；
★Scrum 不认可开发团队成员的头衔,无论承担哪种工作他们都是开发者。此规则无一例外；
★ 开发团队中的每个成员可以有特长和专注领域,但是责任归属于整个开发团队；
★ 开发团队不包含如测试或业务分析等负责特定领域的子团队。
◆四． Scrum的三个工件和运作模式 ◆
产品待办事项列表(Product Backlog) |
产品待办事项列表是一个经排序的持续完善的清单列表,包含所有产品需要的东西,也是产品需求变动的唯一来源。产品负责人负责产品待办事项列表的内容、可用性和优先级。 |
待办事项列表 (Sprint Backlog) |
Sprint 待办事项列表是一组为当前 Sprint 选出的产品代办事项列表条目,外加交付产品增量和实现 Sprint 目标的计划。整个列表将记录整个开发过程中各个事项的实现情况。 |
燃尽图 (Burn-down Chart) |
Sprint Burndown Chart 显示了Sprint中累积剩余的工作量，它是一个反映工作量完成状况的趋势图。 图中Y轴代表的是剩余工作量，X轴代表的是Sprint的工作日。在Sprint开始的时候，Scrum Team会标示和估计在这个Sprint需要完成的详细的任务。所有这个Sprint中需要完成，但没有完成的任务的工作量是累积工作量，团队会根据进展情况每天更新累积工作量，如果在Sprint结束时，累积工作量降低到0，Sprint就成功结束。 |
❶应用Scrum的团队中，整个开发过程由若干个短的迭代周期组成，一个短的迭代周期称为一个Sprint，每个Sprint的建议长度是2到4周(唯品花目前使用1周的Sprint).
❷ 在Scrum中，使用产品Backlog来管理产品的需求，产品backlog是一个按照商业价值排序的需求列表，列表条目的体现形式通常为用户故事。Scrum团队总是先开发对客户具有较高价值的需求。
❸在Sprint中，Scrum团队从产品Backlog中挑选最高优先级的需求进行开发。挑选的需求在Sprint计划会议上经过讨论、分析和估算得到相应的任务列表，我们称它为Sprint backlog.
❹ 在每个迭代结束时，Scrum团队将递交潜在可交付的产品增量。
Scrum的日常
➀ 我们首先需要确定一个Product Backlog（按优先顺序排列的一个产品需求列表），这个是由产品负责人 负责的；
➁Scrum开发团队(包括产品负责人)根据Product Backlog列表，做工作量的预估和安排；
➂有了Product Backlog列表，我们需要通过 Sprint计划会议从中挑选出一个Story作为本次迭代完成的目标，这个目标的时间周期是1~4个星期，然后把这个Story进行细化，形成一个Sprint Backlog；
➃ Sprint Backlog是由Scrum开发团队去完成的，每个成员根据Sprint Backlog再细化成更小的任务（细到每个任务的工作量控制在0.5-1天内能完成），并将细化后的任务以贴便签到看板的形式体现出来供后续跟进；
➄ 在Scrum开发团队完成计划会议上选出的Sprint Backlog过程中，需要进行每日站立会议，每次会议控制在15分钟左右，每个人都必须发言，并且要向所有成员当面汇报你昨天完成了什么，并且向所有成员承诺你今天要完成什么，同时遇到不能解决的问题也可以提出，每个人发言完成后，要同步更新自己负责的看板；
➅ 在Scrum每日站立会议过程中，将参会成员遇到的问题整理到所有人可见的看板中，记录所有需要跟进的事项；
➆ 当一个Story完成，也就是Sprint Backlog被完成，也就表示一次Sprint完成，这时，我们要进行 评审会议，产品负责人和客户都要参加（最好本团队老板也参加），每一个Scrum开发团队的成员都要向他们演示自己完成的软件产品（这个会议非常重要，一定不能取消）；
➇最后就是 Sprint回顾会议，也称为总结会议，以轮流发言方式进行，每个人都要发言，总结并讨论改进的地方，放入下一轮Sprint的产品需求中；
⑨ 当一轮Sprint的工作完成时，就开始计划下一轮的Sprint的工作计划，直到所有Story都完成为止（计划好的n轮Sprint计划）；
❶ 精确：瀑布模式通常会在产品起点与最终结果之间规划出一条直线,然后沿着直线不断往前走。然而当项目到达终点时,用户通常会发现那已经不是他们想去的地方。而敏捷方法则采用小步快跑,每走完一步再调整并为下一步确定方向,直到真正的终点；
❷ 质量：敏捷方法对每一次迭代周期的质量都有严格要求，这些都为敏捷项目的整个开发周期提供了可靠的质量保证；
❸ 速度：敏捷团队只专注于开发项目中当前最需要的、最具价值的部分。这样能很快地投入开发。另外,较短的迭代周期使团队成员能迅速进入开发状态；
❹丰厚的投资回报率：在敏捷开发过程中,最具价值的功能总是被优先开发,这样能给客户带来最大的投资回报率；
❺高效的自我管理团队：敏捷开发要求团队成员必须积极主动,自我管理。在这样的团队中工作,每个团队成员的技术能力、交流、社交、表达和领导能力也都能得以提高。
七：Scrum常见问题总结及解决方案
➀ 故事分解任务过程中任务规划较粗，会造成在评估时造成工时不准确，存在资源浪费和资源使用不均衡的情况。
团队把工作拆分成更加细致的任务，控制在小时级的工作量，不要超过一天。这样更有利于团队为了同一个故事而共同努力，也便于协调多人同时参与，可以有效保证团队资源的均衡利用，同时也便于成员确认每天的进展。
➁ 每日站会过程中，Scrum Master会不自觉的成为主导、主持人的角色，通过问答形式与站会成员交流。
团队成员面对所有参会人员进行交流，而不是单独为PMO进行工作汇报，并引导团队成员自己掌控每日站会，从而带动整个团队的参会、工作积极性，同时控制好会议有序高效进行。(前一天做的事情、当天准备做的事情、遇到的问题)。
➂ 个别核心人员迟到或缺席，导致站立会的效率和质量下降。
确定项目的固定站会时间和必须参会人员，原则上缺席需要安排BackUp；若确定缺席，需提前告知团队成员，以便评估早会是否照常进行还是适当推迟进行；必要时可引入奖罚机制。
➃ 没有实施Sprint回顾会议，进行问题总结和跟踪。
固定1-2个迭代周期组织团队成员发起Sprint回顾会议，借助回顾的方式与团队成员共同参与讨论，总结出在上一个迭代中遇到的所有问题，并商讨产出完整的后续改进方案和流程，重要的一点是在以后的迭代中能够做到有效地跟踪并解决这些问题。
➄ 没有做好Product BackLog管理。
协调各产品经理(Product Owner)统一整理并维护Product BackLog，制定明确的优先级，使得开发、测试团队成员能够清晰、高效地筛选并完成每个Sprint内容。
今日推荐
以上是关于敏捷开发&团队之日常的主要内容，如果未能解决你的问题，请参考以下文章