敏捷思想理念
敏捷宣:
我们正在通过亲自开发和帮助他人开发，发现开发软件的更好方法。通过这项工作，我们开始更重视:
- 个体以及互动而不是过程和工具
- 可用的软件而不是完整的文档
- 客户合作而不是合同谈判
- 应对变更而不是遵循计划
也就是说，右栏中的项目固然有价值，但我们更重视左栏中的项目。
敏捷12原则：
- 我们的最高目标是，通过尽早持续交付有价值的软件来满足客户的需求
- 欢迎对需求提出变更，即使在项目开发后期也不例外。敏捷过程要善于利用需求变更，帮助客户获得竞争优势。
- 要经常交付可用的软件，周期从几周到几个月不等，且越短越好。
- 项目实施过程中，业务人员与开发人员必须始终通力协作。
- 要善于激励项目人员，给予他们所需的环境和支持，并相信他们能够完成任务。
- 无论是对开发团队还是团队内部，信息传达最有效的方法都是面对面的交谈。
- 可用的软件是衡量进度的首要衡量标准。
- 敏捷过程提倡可持续的开发。项目发起人、开发人员和用户应该都能够始终保持步调稳定。
- 对技术的精益求精以及对设计的不断完善将提高敏捷性。
- 简洁，即尽最大可能减少不必要的工作，这是一门艺术。
- 最佳的架构、需求和设计将出自于自组织团队。
- 团队要定期反省怎样做才能更有效，并相应地调整团队的行为。
敏捷里的 3种角色、5个仪式、3个工件、5个价值观
3种角色
产品负责人
- 清晰地表达产品待办列表项
- 对产品待办列表项进行排序，最好地实现目标和使命
- 优化开发团队所执行工作的价值
- 确保产品待办列表对所有人可见、透明、清晰，并且显示scrum团队的下一步工作
- 确保开发团队对产品待办列表项有足够的理解
Scrum Master
- 在项目生命周期早期定义基本规则
- 确保团队理解干系人期望
- 同团队沟通项目愿景，有利于确保团队
- 认识到他们的目标同项目总目标紧密一致
- 以连贯的单元模式工作
- 对愿景给予承诺
团队
- 有自主权选择如何最好地满足目标，并且为之负责。
Scrum三个工件
Scrum的工件以不同的方式表现工作任务和价值，可以用来提供透明性以及检视和调整的机 。Scrum中的工件就是为了最大化关键信息的透明性，因此每个人都需要有相同的理解。
产品待办列表(Product Backlog)
- 产品需求列表
- 产品负责人对该列表进行优先级排序
- 待办事项列表中的条目以用户故事的形式呈现
sprint待办列表(Sprint Backlog)
- 是产品待办列表的子表，只记录当前迭代的工作
- 将用户故事拆分成任务，团队成员主动领取任务
- 团队成员可以添加、删减或者更改迭代中的任务。
产品增量(PSPI: Potentially Shippable Product Increment)
- 团队在迭代内完成交付成果，集成到以往的迭代成果中，形成增量式的交付。
- 每次交付的用户故事必须符合验收条件
scrum会议（5个仪式）
冲刺计划会议
- Scrum团队的所有成员出席，在此次会议中，开发团队识别当前冲刺开发交付的产品待办事项中的故事。
- 这个会议时间箱为：一个月的冲刺，会议时间8小时，4个小时用于选择故事和4个小时估算分配。
每日站立会议
- 由Scrum Master和开发团队参加，产品负责人可以自行选择是否参加。每日站立会议是快速专注的会议，用来分享迭代或迭代进展。
- 每个团队成员就他们将要完成的任务对其他人做口头承诺。
- 每个团队成员回答以下问题
- “昨天做什么？"
- “今天将做什么？"
- “遇到了什么问题？“
- 每日立会只有猪的角色可以发言，鸡的角色不可以发言
- 这次会议时间箱15分钟，每天发生在同一时间和地点。
冲刺评审会议(review)
这次会议是由Scrum团队的所有成员参加。
开发团队将可能移交的可交付物开发特性演示给干系人和项目发起人。
Sprint评审会议的结果是一份修订的产品待办列表，确定很可能进入下个Sprint的产品待办列表项。
这个会议时间箱为一个月的迭代，4个小时，比冲刺计划会议的持续时间更短。
1、 冲刺评审是在迭代末期进行的时间盒（有指定时间限制）会议，此时不断变化的解决方案展示给利益相关者，他们的反馈得到收集。
该会议是：
- 针对冲刺末期召开，
- 被时间盒定义到四个小时，按月冲刺和较短的时间段；
- 冲刺评审会议由包括开发团队，产品负责人，scrum Master,和企业的利益相关者的整个团队出席；
- 这些冲刺评审会议被团队通过录音、快照来展示产品。
2、 冲刺评审的益处
进行常规冲刺评审会议有助于：
- 产品根据利益相关者的需要在变化；
- 任何反馈或升级在即将到来的冲刺或发布中被记录和强调，
- 优先级排序的待办事项将被展示给利益相关者去评估是够满足他们的期望； 逐步完善未来的项目计划。
3、 冲刺评审的重要性
在一个2周冲刺的项目中，没有组织冲刺会议将导致项目进度落后于整整一个月。
这是因为：
- 开发的需求没有满足利益相关者的期望；
- 为即将到来的冲刺所选择的需求，没有同利益相关者的需求保持一致。
冲刺回顾会议：（ret ros pect ive)
是由Scrum团队的所有成员参加。这次会议的焦点是对整个迭代进行回顾。细节包括：什么进行顺利，缺少什么，需要改变什么等等。团队就未来的迭代改进计划达成一致。这个会议时间框为一个月的迭代，3个小时，比迭代评审时间短。
冲刺回顾是针对迭代末期进行的时间盒（有指定时间限制）会议，目的是认识团队可以如何提高他们的工作方式，就未来的迭代改进计划达成一致，该会议： 针对冲刺末期召开，
被时间盒定义到三、四个小时按月冲刺和较短的时间段；
由包括开发团队，产品负责人，ScrumMaster,和企业的利益相关者的整个团队出席； 在冲刺回顾中，团队将认识到他们做的好的领域以及有待改进的领域。
来自于回顾会议的反馈对实施持续改进策略和最大化团队交付价值非常关键。
细节包括：什么进行顺利，缺少什么，需要改变什么等等“
冲刺回顾是针对迭代末期进行的时间盒（有指定时间限制）会议，目的是认识团队可以如何提高他们的工作方式，就未来的迭代改进计划达成一致，该会议：
- 针对冲刺末期召开，
- 被时间盒定义到三、四个小时按月冲刺和较短的时间段；
- 由包括开发团队，产品负责人，ScrumMaster,和企业的利益相关者的整个团队出席；
- 在冲刺回顾中，团队将认识到他们做的好的领域以及有待改进的领域。
- 来自于回顾会议的反馈对实施持续改进策略和最大化团队交付价值非常关键。
- 细节包括：什么进行顺利，缺少什么，需要改变什么等等“
待办事顶梳理（Grooming）
scrum团队在冲刺中经常会面进行待办事项的梳理。
梳理或细分是一种逐步完善待办事项的方法，所以它会保留现有信息同时反映利益相关者的需要。
该会议有助于：
- 增加新用户故事；
- 丢弃不相关的用户故事； 估算新增加的用户故事； 重新估算用户故事；
- 对用户故事进行优先级重排序；
- 史诗分解成更小的用户故事。
需要记住的点：
- 梳理会议提供了调整估算范围的最佳时机；
- 利益相关者的期望通过对产品待办事项进行与时俱进的更新来管理；
- 己经完成优先级排序和更新的产品待办事项应该作为冲刺评审会议的一部分由利益相关者来评审；
- 来自于运营和维护问题的反馈需要被考虑，新需求必须添加到产品待办事项中；
- 识别出的现有缺陷经过分析后，需要确保他们在梳理会议上被讨论。
其他只是点:
优先级技术MoSCoW
MoSCoW技术是进行需求优先级排序的敏捷方法。在这种技术下，需求基于以下方面排序．
1） Must 必须有: 这些需求是强制性的
2） Should 应该有: 这些需求不是强制性的，但是高度渴望的
3） Could 可以有: 这些需求如果满足会很好
4） Won’t 不会有: 当下可以不去满足，但是将来可以加入
在开始新一轮时间箱前，会有一个新的MUSTS加入。这些可能是新的需求，或者现有需求被调整优先级进而转移成为MUSTs
9633
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
