各位老铁们，今天由我来为大家分享敏捷的小知识，以及敏捷知识分享的相关问题知识，希望对大家有所帮助。如果可以帮助到大家，还望关注收藏下本站，您的支持是我们最大的动力，谢谢大家了哈，下面我们开始吧！
由于周六就要开始项目经理考试了，这里复习一下敏捷知识，加深印象吧。
个体以及互动胜过流程和工具
可用的软件胜过完整的文档
客户合作胜过合同谈判
响应变化胜过遵循计划
敏捷项目章程应包含 3个关键信息：
由于敏捷方法本身就是为了应对需求和项目的不确定，因此对于敏捷项目的范围一般很少详细定义，它会随着整个项目的进行而变化。所以，敏捷项目章程通常比传统的项目章程粗略，章程包含的内容相对较少。敏捷章程更多聚焦在项目如何运行，而不是具体要做什么。
团队章程是团队的社会契约，规定团队成员之间彼此互动的方式。团队章程由项目团队
共同制订。团队章程的目标是创建一个敏捷的环境，在这个环境中，团队成员可以发挥他们
作为团队的最大能力。
团队章程的内容包括：
燃尽图是一个用来展示迭代进度的信息发射源，以图形化的方式展现了团队本迭代内剩余的工作量（y轴）与工作日（x轴）的关系。其目的是监控迭代进度或者项目的进度，追踪剩余总和并预测达成迭代目标的可能性。一般，在团队每日站会开会后，由团队更新燃尽
图。
风险燃尽图是用于跟踪项目伴随时间风险的风险管理技能，是项目风险严重程度的累积。
通过风险燃尽图，干系人可快速查看随着时间项目风险管理的绩效（比如提高、降低以及相应的数值）。严重度（影响和收益的产品）是沿着竖轴绘制，横轴是时间。在理想情况下，风险严重度会随着时间降低。
燃起图以图形化的方式展现了项目或团队多个迭代的需求累计完成情况（y轴）与各迭代（x轴）的关系。通过延长实际线（按最近迭代或平均斜率），可以大致判断要完成当前的所有需求还需要几个迭代。燃起图可以看出项目范围的变化。
除了显示已完成的工作量，燃起图还能显示项目中的实际总工作量。
任务看板是一种很好的追踪和报告价值的方法。团队在过程中可以及时地发现问题、快速反馈，同时，工作项的完成也会增加信心。
故事地图是客户价值优先级排序的工具，提供了一个关于功能何时交付的产品路线图。
故事地图还可以用作跟干系人沟通的工具，把故事放在墙上作为一个项目计划的信息发射源。
故事地图鼓励大家用不同的方式参与，通过可视化的展示引发干系人的关注。
用户故事是大小适中的，可以被理解的商业功能模块。敏捷团队通常依赖用户故事和用
户故事待办事项（通常可以等价为产品待办事项）进行商业需求优先级的排序。
产品路线图为产品负责人所拥有，是产品需求的高层级概述，常用作特性优先级排序、特性归类和粗略时间框架确定的工具。产品路线图又勾画出产品多个版本的演变过程，是项目层面的粗粒度计划，关注的是目标而不是细节。
冲刺的输出是潜在可交付的产品增量（Product Shippable Increment，PSI），冲刺过程中迭代目标不变、质量目标不降低。冲刺开发是有节奏地小步快跑，但建立在坚实的质量基础上。
一个冲刺就是一个时间盒（有时间限制），在这个时间盒中至少应该有产品发布，时间盒的长度一般是 2~4周。迭代周期长短的设定取决于团队应对外界需求变化的能力。冲刺可以在时间盒结束前取消，但只有产品负责人才有权力取消 Sprint。如果某个Sprint对其所在环境失去了价值和意义，那么它就应该被取消。当取消某个 Sprint时，任何做完和完成的产品待办事项都需要进行评审，所有未完成的内容都会被放回到产品待办列表中，并重新估算。
在第一个 Sprint之前有一段特殊时期，被称为 Sprint 0（零迭代），也称为 Inception阶段，用来完成一些必要的准备工作。Sprint 0的周期不应该太长，一般在 4周以内。
冲刺规划会用于确定在这个冲刺中需要交付哪些产品，以及如何达成目标。产品负责人展示产品待开发项，整个团队成员对其进行讨论，分享彼此的观点。开发团队基于他们的估算预测在这个冲刺中将要交付的产品，并决定这些功能将如何进行交付以实现冲刺的目的。长度为 1个月的冲刺，其计划会议最长不超过 8小时，其中 4小时用于选择用户故事，4小时用于估算分配。
每日站会是一个拥有时间盒的每日会议（通常不超过 15分钟）。这个会议每天在同样的时间和地点召开，每个开发团队成员只回答三个问题：
每日站会提出的问题和风险要及时曝光，张贴在显眼的地方。每日站会可以确定由谁解决问题，但不制订解决方案。只有 Scrum团队的成员，可以在会议中发言。产品负责人可以不参加每日站会，即使参加也不能发言，以免破坏站会的时间盒。
每日站会可以带来透明性、信任和更好的绩效，能帮助快速发现问题，并促进团队的自组织和自立。
冲刺评审是一个在冲刺结束时举办的会议，用来检查增量或者开发出来的产品，必要时也可对产品待开发项进行调整。评审会通常的形式为演示+验收，仅演示当前冲刺完成的条目。开发团队证明工作已经“完成”，并且对此增量回答任何问题。产品负责人决定此增量是否“完成”，具有一票否决权。产品负责人和团队讨论剩余的产品待开发项，以及下一步需要完成的工作。对于周期为 1个月的冲刺，评审会议的限时为 4小时。
产品待办事项列表也称为产品需求池、产品功能列表，是一份涵盖产品中已知所需每项内容的有序列表，包括业务需求、技术需求、NFR（非功能需求）、Bug、Spike等，它是产品需求变动的唯一来源。产品负责人负责管理产品待办事项列表的内容、可用性和排序。
一个好的产品待办列表需要符合“DEEP”原则：
产品待办列表一直处于动态变化，它会随着产品及其应用环境的改变而演进，需要持续更新以反映出需求。任何人（产品负责人、SM、开发团队）随时都可以向 PB表中增加事项，但仅产品负责人负责排序，有最终决定权。
产品待办列表中排序越高的事项比排序低的事项拥有更多细节，任何一个产品待办事项都能够在 Sprint的时间盒期限内适当地完成。这些能够在 Sprint中完成的产品待办事项列表称为“准备就绪”（DoR），它们将作为 Sprint计划会议中的待选产品列表项。
待办产品列表项的足够透明程度要通过产品待办列表精化活动来实现。
Sprint待办列表是一组为当前 Sprint选出来的产品待开发项，同时附上交付产品增量和实现 Sprint目标的计划。Sprint待办列表是开发团队对于下一个产品增量所需功能及其工作的预测，关注的是团队怎么做才能在一个迭代内交付。
Scrum开发团队可以在 Sprint期间修改 Sprint待办列表。当新工作出现时，Scrum开发团队需要将其加入 Sprint待办列表中；当计划中的某个部分失去意义时，就可以将其从 Sprint待办列表中移除。Sprint待办列表由 Scrum开发团队全权负责，团队中的任何人都可以添加、删除或更改迭代中的工作项。Sprint待办列表中的任务实现顺序也由 Scrum开发团队决定，因为开发团队最清楚任务之间的依赖关系。对于剩余工作量的估算（绝对估算，人天等）每天需要更新。Sprint待办列表中的每项任务由一个人负责（通过认领而不是指派的方式）。
增量是一个 Sprint完成的所有产品待办列表项，以及之前所有 Sprint所产生的增量价值的总和。在 Sprint的结尾，新的增量必须是“完成”的，这意味着它必须可用并且达到了 Scrum团队“完成”的定义的标准。在每个 Sprint结束时，团队必须有新的增量交付。
1.什么是Scrum？
Scrum是软件开发中最为流行的敏捷框架。它是一种迭代的方法，核心是冲刺（迭代术语）。为了支持这一过程，Scrum团队使用特定的角色，工件和事件。Scrum团队在整个项目中通过检验确保他们达成过程中每一部分的目标。
2. Scrum的三个角色
Product Owner： 代表项目的业务需求方，并负责解释需求。
Scrum Master：负责引导保护团队，移除障碍。这里需要注意，Scrum Master不是团队成员，不是产品负责人，他是一个独立的角色，是敏捷和Scrum的思想专家。 Scrum Master通过分享敏捷和Scrum的经验帮助团队成长。Scrum Master的目标是建立一支优秀的高绩效的自组织团队。
Scrum Team： 执行日常工作。开发团队专注于项目并且是跨职能的，也就是说每个成员在项目中都能承担多种项目工作。
3. Scrum的工件
Product Backlog：产品待办事项列表是一个排序的列表,包含所有产品需要的东西,也是产品需求变动的唯一来源。产品负责人负责产品待办事项列表的内容、可用性和优先级。
Spring Backlog：Sprint代办事项列表是一组为当前 Sprint选出的产品代办事项列表条目,外加交付产品增量和实现 Sprint目标的计划。Sprint代办事项列表是开发团队对于哪些功能要包含在下个增量中,以及交付那些功能所需工作的预计。Spring Backlog有Scrum团队自行讨论决定。
增量：增量是一个 Sprint完成的所有产品待办列表项的总和，以及之前所有 Sprint所产生的增量的价值总和。在 Sprint的最后，新的增量必须是“完成”的，这意味着它必须可用并且达到了 Scrum团队“完成”的定义的标准。增量是在 Sprint结束时支持经验主义的可检视的和已完成的产品组成部分。增量是迈向愿景或目标的一步。无论产品负责人是否决定发布它，增量必须可用。
4. Scrum的优势
通过尽早反馈，及时调整，做出有价值的，让客户满意的产品。
5.作为Scurm Master，如何管理自己的团队
a.管理团队的四种方式/心态模式
教导和辅导法
共享Scrum和敏捷的经验，并利用自己的经验提出更多的实践和方法。适用于团队建设初期，团队刚刚转型或者刚学习了Scrum思想但还没有真正的实践过。这个时候需要Scrum Master分享自己的经验和实践，帮助团队理解敏捷和Scrum.
移除障碍法
注意这里的移除障碍是指Scrum Master将责任，活动和所有权下放给团队，让团队接管任务，自行解决问题，而不是Scrum Master帮助团队解决问题。
引导法
引导意味着不干扰讨论的内容或解决方案本身，只是推进讨论流程。引导使得沟通更有效率，引导帮助团队定义目标，可交付结果和预期结果。
适用于团队已经渡过了初期的建设，并取得了一定的成功。这个时候Scrum Master需要引导团队，防止团队自得于所取得的成功，止步不前。
教练法
应用于团队后期，不仅关注个人成长，而且关注团队的自我组织，责任感和所有权。
所有的这些都离不开观察法， Scrum Master需要通过观察法来决定使用什么方式管理团队。
b. ScrumMasterWay的三个层次
我的团队: 只对开发团队负责
关系:建立一支自信的Scrum团队，将产品负责人整合到团队中，在Scrum的三个角色之间建立平衡的关系。然后强调Scrum团队与其他利益相关者建立良好的关系和联系。
整个系统:将重点转移到整个系统，将敏捷思维方式和Scrum价值观带入公司层面，帮助组织改变对员工的态度，改变管理和领导风格，改变产品所有权和战略，从而使得组织变得更灵活，更欢迎变革。
推荐《有效管理敏捷团队－快速成为优秀的ScrumMaster》
通过敏捷知识讲座的分享，巩固了相关的敏捷知识，同时也发现了一些不牢靠，理解不深的地方，需要后续进一步加强。另外，通过在公司内部开展敏捷知识讲座分享，让更多的人了解敏捷，认识敏捷，为以后做敏捷项目打下一定的基础。
会议背景：
一个前期开发的项目组，项目组成员分散在新加坡和成都的办公室。开发团队中新同事比较多，对敏捷的了解及自身职责不足，因此组织了这样一个敏捷知识的分享会，目的在于统一团队成员的认识，明确大家的目标。
会议内容：
1.敏捷的来由及敏捷宣言：重点在于对敏捷宣言的解读，提醒大家重视沟通和产出。
2.Scrum框架的介绍：由于这个项目使用了Scrum框架，因此着重介绍了Scrum的角色及事件。使项目组对自身角色的职责和每个事件所需要完成的目标有初步了解。
3.公司敏捷框架：公司敏捷框架是以Scrum为核心构建的，因此做了个简略的公司敏捷框架的介绍。
4.讨论作为远程团队，我们应该如何做。
会议心得：
作为远程团队，如何将敏捷框架落地，在与PO和Scrum Master的远程沟通中，如何保持良好的沟通渠道，从而达到Sprint目标。
如何去完成Sprint的事件，从而提高团队整体水平，逐步实现一个自组织的开发团队，是我们在这个比较特别的敏捷团队架构下所面临的挑战。
文章分享结束，敏捷的小知识和敏捷知识分享的答案你都知道了吗？欢迎再次光临本站哦！