设计网站平台西宁网站seo
信息发射源、看板是敏捷相关的词汇。
需求不明确：敏捷的关键词。
明确的端对端工作范围是传统项目管理的关键词。所以，应该采用：混合的，多轨制，瀑布态这样的声明周期
STACEY矩阵。
敏捷价值观指引者我们敏捷的实现。所做的任何事物，是否有易于价值观。
敏捷价值观
敏捷关注的是人，流程和工具服务于人
敏捷过程中写合适够用的问题文档即可，软件才是真正关注的
客户合作是双赢状态，谈判是博弈的状态。
敏捷是拥抱拜变化，但是不是无原则接受变化
敏捷是适应性状态，敏捷不=快 ，敏捷是适应市场。
敏捷原则
pmp：核心思想就是：让客户满意。
三：Scrum体系-三种角色。
Scrum体系流程图：产品代办事项列表--迭代代办事项列表--迭代本身--最终交付物 这样的一个过程
1:3355
勇气：干预做没做过达不到的事情
开放：SCRUM上需要开放，尽量不要私下，需要被更多人知道，被更多人吸收。
专注：某一段时间，大家都专注到一件事情上
承诺：强调团队的承诺，而不是个人的承诺，拆解条最好是团队的承诺，而不是某个人或者领导经理的承诺，团队开诚布公的进行彼此的承诺。
尊重：尊重个人的想法，意见，决定，我们认为他是想和团队是一致的。
三种角色：
1：产品负责人
客户代表：产品负责人和铲平经理都是客户代表，但是产品负责人对产品进行限定。
定义所有产品功能：产品负责人有全部决定权，敏捷中需求是讨论出来的。
决定产品发布的内容和日期：产品负责人最大的一个权限，S中PM说了算，PMP中都是商量的一个结果，传统中是计划的，基于技术本身能力界定，但是不一定符合市场，PMP中又产品经理或者po负责。PMP中投资回报率很难找到一个人负责。
对产品的投入产出负责
根据市场变化对需要开发的功能排列有限顺序：敏捷中，产品负责人进行优先级排序，因为他是客户代表。
合理的调整产品功能和迭代顺序
认同或者拒绝迭代的支付：这是产品负责人的权利，判断这个迭代交付的行或者不行。
确保开发团队知道产品代办事项列表：确保开发人员了需求。
2：Scrum Master
SM不做决策，PM决策是很强的。团队自行做决策
早期SM和PM相对统一，制定规则。管理期望、管理相关方、制定沟通策略、管理承诺。
项目执行起来之后，SM和PM进行切割，SM不做决策。
鼓励言论自由：传统自由文档中，需求是团队讨论出来的。前期可以制定一些规则，但是规则不一定适配，敏捷中所有的决定烦死都是有团队决定产生，一开始可以有一些规则。
保证仪式：
团队有问题，优先团队内部解决。尽量不要上升到领导
保护团队一个整体。SM是一个服务型人员，PM是一个领导行人员，SM所做的一切都是服务于团队，打成PO制定的规划。
团队成员被其他事情打断和影响，SM需要保护他们，让他们专注。
自组织：自我决策--自我驱动--自我搞定
3：开发团队：开发人员、测试人员、po、工具建设人员
自主选择
全职能：人可以做abc都行，可以互补，这样少了谁都行。开发应该可以测试。测试可以开发。一定时间内，每个人都facus到这个项目上，不要干别的项目的事。
跨团队本身不进行解决：外部团队问题，拉外部团队一起解决问题
决策在团队内：去中心化决策
平级：正哥的开发团队是一个等级。他做什么活有另外一个人决定是不合理的。这里必须是一个平级的概念。
三种工件
产品代办事项列表
本质上就是排了序的需求池
产品的需求列表：包含了业务需求、技术需求、NFR(非功能性需求)、培训、学习、其他要做的都可以放到这个产品需求列表。
PO对该列表进行优先级排序，也都是PO进行维护。技术需求也需要PO同意才能加。
每个迭代开始前，优先级排序还可以再修正。
代办事项列表中的条目以用户故事的形式体现。
DEEP原则：适当详细、被估算的（po和sm）、涌现的、排了优先级的。
放多少有PO决定，做多少有团队决定。涌现的：
不能直接进下一个迭代，这是原则性问题。延长冲刺，也不用考虑
迭代代办列表
团队成员主动领取的是任务，不是故事，做多少工作是由团队决定的。
团队成员，可以添加减少或者更改迭代中的任务，而不是故事。
迭代列表中的任务进行了估算。剩余工作量的挂算每天需要更新。
团队成员只做代办事项列表中的问题。其他都不接。
产品增量-- 交付物
迭代成果+已有成果就是交付物。
每次交付必须符合验收标准。每次交付必须处于可用装填。不管是否PO要不要发布，但是必须要能上线。
五种活动
1：产品梳理会
又叫产品梳理会
增删改查用户故事
估算规模：敏捷建议使用相对估算法。与基线对比极限要相对小的，不要绝对小的。
故事优先级排序：莫斯科、kano模型基于用户满意度行奋度。权重分析。
拆解用户故事
可以邀请利益相关者进行参与和评审
可以有技术和相关的讨论
都是项目级别的进度图。都是支持发布计划的。
最小可交付价值
最小可售单元
最小可行性产品。
滑板就是MVP
适应型就是敏捷型的关键词。
用户故事：用户故事可以给很多人看，开发、测试、交谈、验收标准是什么。
用户故事地图：和发布计划是一个概念
2：迭代计划会
迭代开始的标志：规划会议。计划会议就是规划会议。
规划会议，取决于迭代时长。梳理会开完之后，我们开计划会议，规划会议输出的是燃尽图。PO、研发、SM 团队所有成员，把接下来要做的事情进行去人，让PO调整优先级。按历史顺序，进行承诺。
承诺的是越稳定约好，不能贪多，团队速率是针对一个迭代产生的。不升跨团队进行比较。
规划会的定义完成的定义：DOD就是验收的标准、完成的标准。
什么是探测：敏捷中使用的一种技术。只用来判定可行性：风险、技术、商业模式。判断这些的可行性。
发现了风险不好识别、技术不好确定、商业模式是否可行，需要采用刺探得技术。
采用锚点法。
3：迭代回顾会
除了站会外时间最短的互动，一般在15分钟到半个小时之间。
开发团队、PO、SM 企业利益相关者等等。
4：迭代
5：每日站会
po sm dev tem都必须要来。谁都可以来开。但是，只有po sm dev tem可以说话。
为了打成sprint目标，我昨天做了啥，今天计划做啥，啥制约了我。
这个活动不进行讨论。
站会也会同步生成燃尽图、燃起图，这是一回事。
6：迭代评审会
这里指的就是最终的产品验收评审。就是交付软件给客户相关利益方的一个行为。
和外部交互的会议，把外部人员拉过来进行演示
原则上是计划会议的一半
输出的是一份修订的产品事项列表，客户可能会有新的需求出来
这个活动在迭代最后倒数第二个去进行。这是为了和利益相关放步调一致。
4应该是版本燃尽图
精益与看板体系
这是用来进行透明的贵管理干系人的期望有促进作用的工具
燃起图、燃尽图、看板或者任务版本、风险看板等，都是为了把信息进行展示的。
工作流程的可视化、限制在制品的数量。度量管理活动、显示话规则。建立反馈环路、在写作与实验中改进。
看板和KANBAN
SCRUM板和任务板几乎就是一回事。看板可以看到故事的
极限编程的重点实践：持续集成、TDD、结对编程。代码集体所有权、小型发布。
持续集成：持续提交代码到代码库、持续代码进行测试。减少代码冲突，对于整个交付有信心。
TDD；测试驱动开发、测试线性，开发照着测试开发
结对编程：老带新、技能的复制、攻坚解决大难题。
代码集体所有权：
敏捷团队管理
敏捷方式下，管理团队方案是十分不一样。
变更管理
敏捷中的变更来讲，首先拿scrum来讲，scrum里边首先没有变更这个说法。在每个迭代内控制计划、执行、检查、改进是不变的。再迭代之间，我们进行变更。人员、需求、环境、计划都可以变更。
团队创建
冲突管理：回避、拖鞋、缓解、合作、对抗
冲突层级：问题待解决、异议、竞赛、运动、战争。
团队领导：
成熟阶段：授权型
形成阶段：指导型
震荡阶段：
规范阶段：
敏捷创建的是自组织团队，所以管理基于团队，不基于任务。团队应该在一起。
服务型领导：帮助团队> 命令团队 移除障碍>创建障碍 保护团队 >干扰团队。
传统PMP里边wbs任务拆解是项目经理拆和技术经理拆，敏捷中需要团队自己拆。敏捷是承诺的，团队自己承诺的，而不是某个人做出的命令和承诺。
A 正确答案：
敏捷中：将热血奉献给团队，帮助他。
一个团队成员，效率比较低：帮助他 、帮助 他。 帮助他。帮助他。我帮助他找，不是代替他找。
D：团队自己决定、我们要帮助他。
敏捷回顾
1：敏捷宣言
敏捷实践的四个实践。
燃尽图和燃起图，都指的是迭代周期里边的。没加前缀的话。