.png)
首页>
情境三：团队里有一名成员同时是另一职能部门的成员。由于职能经理在不断的分配任 务，该成员不能完成本项目委派的任务，你应该怎么做？
和职能经理进行讨论，看如果改善现在的情况，使该团队成员能全身心聚焦于当前的项 目。
关于可视化
情境一：如果一名主管/产品负责人请求获得有关某个 sprint 状态的信息，你可以引导 他做什么？
指导主管查看信息看板，信息看板展示 sprint 状态。
情境二：产品负责人询问每次迭代的进展情况以及后续迭代的工作期望，你应向产品负 责人提供什么？
燃尽图和燃起图
燃尽图体现了已完成工作与迭代计划的比较，可以反映工作进展情况；
燃起图体现已完成工作的累积情况，体现完成工作的走势，可以反映后续工作的预期。
关于变更、新技术和缺陷
情境一：在一次团队计划会议上，团队建议变更，增加产品价值，但需要额外工作并会 影响到进度计划，你应该怎么做？
要求产品负责人批准继续，对于增加的额外的工作量是否增加了产品价值，只有产品负 责人最有发言权，所以这种变更需要经过产品负责人的批准，再决定是否继续。
情境二：一名团队成员在工作过程中意识到，其中一项任务所花的时间比原始估算的时 间长很多，你和团队应该怎样做才能规避这种情况发生呢？
一项任务所花费的时间比原始估算的时间长，很可能是将用户故事拆分成任务时，该任 务规模太大，所以可以将该任务分成多个部分，拆分后，也可以被其他成员进行领取。
情景三：一名团队成员被分配去通过实验新技术解决一个问题，你要求他提供一份详细 的结果报告。对于这项新成果，你最好做怎样的安排？
让团队成员通过讨论会议分享成果，此举最符合敏捷价值观和原则。
情境四：如果发现可能影响产品发布日期的关键障碍，敏捷项目管理师应该怎么做？
通知项目团队，与团队共享，让他们协作获得解决方案，积极应对。
第一次迭代工作完成，要召开评审会议和回顾会议了，按照约定，两个会议的时间就要 占掉半天的时间，有成员急于进入下一次迭代中，所以对此会议表示不满。作为 SM，你决定给大家再次强调一下这两个会议的价值。你会这样说：
评审会议（Review）
参会人：项目所有团队成员及所有关注产品的人；
时长：2 小时（根据整个迭代时长来确定）；
做法：使用演示形式为干系人展示完成的迭代工作；
目标：促进下一步工作的互助与合作。
回顾会议（Retrospective）
参会人：项目所有团队成员
时长：2 小时 做法：将要在下个迭代中实现的有效改进方法。
哪些做法可以保持
哪些做法需要改进
如何改进的具体想法
我们怎样才能在下个迭代中做的更好
目标：周期性的回顾，总结工作中的经验教训。
家决定体验一下这两个会议，以下是两个会议过程中可能的一些情境，你作为 SM， 你会怎么决策？
情境一：第一次召开的评审会议并不顺利，团队开始对之前的流程有了怀疑情绪，此外， 干系人建议产品质量也需要审计。你赶紧召开了回顾会议,在回顾会议上，你应该怎么做？
与队员一起制定一份纠正措施计划，在回顾会议上和团队成员一起回顾哪些方法可以进行改善。
情境二：在召开评审会议前，你发现用户故事中的一项功能不完整，团队对此次迭代评 审会议的现场感到担忧，你应该怎么做？
你应该跟团队按计划参加评审会议，接受对已完成工作的反馈，评审会议敏捷中提倡透 明度，所以要正常进行，并且要接受反馈，最后可以做适当的调整。
情境三：在评审会议上，敏捷项目团队意识到在约定期限内全面发布待办列表是不可能 的，你和团队应该怎么做？
与 PO 一起协商范围和进度计划，协商是否可以调整进度或者范围，待办列表重新排序 是 PO 的职责，团队不能做。
情境四：在回顾会议上，你意识到一些团队成员压力大且工作不开心，你应该怎么做？
你带着大家识别哪些做的好，哪些做的不好。回顾会议的主要任务就是对上一迭代期间 的过程回顾，在下一次迭代期保留做的好的地方，改进做的不好的地方。
情境五：一位成员给你反馈了一个情况：在迭代过程中，某成员建议使用一种过程改进 技术，但该技术导致降低速度并产生一些质量问题，团队已经进行修正，但是职能经理很不高兴。应该怎么做可以让事情的效果更好呢？
在更改过程之前，应该主动邀请职能经理参与过程回顾，共同找到达成共识的方法。
情境六：在回顾会议上，燃尽图显示项目落后于进度计划，项目团队意识到时因为一名 经验不足的敏捷工程师造成团队速度下滑。你应该如何解决这个问题？
应该帮助这名工程师找到问题提升效率，比如可以在回顾会议上建议结对编程。因为结 对编程的过程中，可以由资深的工程师带领经验不足的工程师一同工作，既能培训新手，也能提高工作效率。
情境七：在你心中，哪一项传统开发实践方法与敏捷回顾会议相当？
经验教训会议，总结上一阶段的工作，发现问题，分析问题，解决问题，吸取经验，更 好的完成下一阶段的工作。
评审和迭代会议的结束宣告第一次迭代正式落下帷幕,按原计划接下来还有 5 次迭代， 因为有了第一次的体验，后面的迭代已经不需要你在每个阶段去一一解读了，很多环节大家 都可以自组织，你感觉非常欣慰。当然，一些需要你协调和沟通的情况还会不时发生，如下 是一些情境，依然是考验的判断和决策。
情境一：项目团队在经过四次迭代后，项目团队意识到以目前的速度，将需要八次迭代， 你和项目团队应该怎么做？
与产品负责人合作，协商发布计划和待办列表优先顺序，最有市场价值的最容易实现的 先开发，先发布。
情境二：团队再次遇到之前版本延迟的问题，有些团队成员感到沮丧，因为在前一次回 顾会议中以识别到这个问题的纠正措施，为保持团队士气，应该怎么做？
一定要及时进行讨论和采取行动利于保持士气，建议为在回顾会议中发现的问题制定一 份行动计划
情景三：团队完成了一次迭代以及大部分用户故事，团队希望确保功能间具有相关性， 团队下一步应该怎么做？
通过一次评审会议和迭代演示，获得产品负责人和项目干系人的反馈，产品负责人和项 目干系人针对产品增量进行评审后反馈给团队，最终决策权在产品负责人和项目干系人。
情境四：项目干系人希望知道某个特定功能是否包含进下一个发布版本中，为解决这个 需求，你应该怎么做？
首先要判断该功能的优先级别，如果优先级高可以考虑尽快做；也要考虑团队的效率和 自信心，是否能够将这个功能包含到下一个发布本中。
情境五：团队在与客户接洽方面有困难，客户几乎不回应问题，经常缺席迭代和评审和 演示，但是仍然期望产品按时交付并满足期望，敏捷项目管理师应该怎么做？
要求产品负责人获得必要的客户反馈
如果客户不能全程参与，可以由产品负责人跟客户沟通，再由产品负责人将客户的意见 和想法反馈给团队。
最终经过 5 个月的时间，这个项目顺利交付，无论是团队还是客户还是高层，都对这次 的体验感到满意。
客户觉得自己在整个项目推进的过程中可以提出自己的新想法，还能有效的加入到开发 的过程中。
高层除了对成果交付的时间和质量表示满意外，还对这个团队呈现出来的精神面貌感到惊讶，虽然这个项目的变更非常多，但团队里没有任何负面情绪，大家似乎都自然而然的接 受了这些。
团队感觉自己有了一次非常不一样的项目体验，大家都在期待下一个项目是不是可以把 Scrum 玩儿的更好。
作为 SM，你提议大家再次把敏捷宣言拿出来阅读一遍，在实际体验了一次敏捷后，再 读这几句话，感受更深了。
我们通过身体力行和帮助他人来揭示更好的软件开发方式。经由 这项工作，我们形成了如下价值观： （敏捷宣言）
传统预测型 | 敏捷项目管理
个体与交互 重于 过程和工具
可用的软件 重于 完备的文档
客户协作 重于 合同谈判
响应变化 重于 遵循计划
在每对比对中，右项并非全无价值，但我们更看重左项
返回上一部分内容：https://www.hxtdpx.com/PMPrz/6741.html
粤公安备案 44010602008731号