minjie

 
 
敏捷宣言 
● 个体和互动 高于流程和工具(Individuals and interactions over processes and tools) 
● 工作的软件 高于详尽的文档(Working software over comprehensive documentation) 
● 客户合作 高于合同谈判(Customer collaboration over contract negotiation) 
● 响应变化 高于遵循计划(Responding to change over following a plan) 
 
12条敏捷原则 
1、我们最重要的目标，是通过持续不断地及早交付有价值的软件使客户满意。 
2、欢迎需求变化，即使在开发后期也一样。善于掌控变化，帮助客户获得竞争优势。 
3、经常地交付可工作的软件，相隔几星期或几个月，倾向于采取较短的周期。 
4、业务人员和开发人员必须每天在一起工作。 
5、激发个体的斗志，以他们为核心搭建项目。提供他们所需的环境和支持，相信他们能够达成目标。  
6、在团队内部，传递信息效果最高效的方式是面对面的交谈。  
7、可工作的软件是进度的首要度量标准。  
8、敏捷过程倡导可持续开发。责任人、开发人员和用户要能够共同维持其步调稳定延续。  
9、对技术精益求精，对设计不断完善，将提高敏捷能力。 
10、以简洁为本，极力减少不必要工作量。  
11、最好的架构、需求和设计出自于自组织的团队。 
12、团队定期地反省如何能提高成效，并由此调整团队的行为。 
 
SCRUM 
两个角色 
Scrum Master（不是项目经理，没有分配任务的权力，没有考核的权力，没有下命令的权力） 
●帮助团队铲除一切阻碍，让团队可以顺利完成冲刺目标 
●帮助团队最大化生产力 
●使用技术手段帮助团队变得更加高效，比如：引入自动化脚本，单元测试，持续集成等敏捷实践 
●协助团队和PO更好的进行协作 
●保证Scrum实践的正确推行 
Product owner（PO）产品的负责人，需求负责人，  
●需求决策：哪个需求重要，哪个需求不重要，需求的优先级如何排列，在某次发布中要发布哪些需求是他来拍板的 
 
三个文件 
●Product backlog产品待办列表： 排序的列表，包含所有产品需求，PO决定产品待办列表的内容、可用性和优先级。 
●Sprint Backlog待办事项列表，（相当于WBS），来源于产品待办列表，更具体 
●燃尽图是反映进度状态，也可以预测未来趋势 
 
四个会议 
计划会议（明确目标、细化任务） 
●决定完成哪些任务 
●如何完成 
每日立会（定时、定点、人齐、会短、高效） 
●一个简短的团队会议，由团队的所有成员在每天固定的时间和地点进行 
●查看项目进展，在会议中作计划，协调每日活动，还可以报告和讨论遇到的障碍 
●任务板能够帮助团队聚焦于每日活动之上，要在这个时候更新任务板和燃尽图。 
●会议上每个成员需要回答3个问题： 
1、你昨天做了什么？ 
2、今天计划做什么？ 
3、 是否遇到了障碍，需要其他人的帮助？ 
评审会（展示验收） 
●小组向产品负责人展示和验收迭代工作结果。 
●产品负责人给出评价和反馈。 
●评审会上发现的问题或改进将被累积到产品待开发项，也不会马上或在下一个迭代中开发，而是由优先级排序决定何时开发。（无需提变更请求） 
回顾会议（经验总结，识别改进） 
●回顾团队在流程、人际关系以及工具方面做得如何。 
●团队识别出哪些做得好，哪些做得不好，并找出潜在的改进事项为改进制定计划。 
 
 
敏捷术语和概念 
 
●敏捷项目范围不固定，而时间和成本是固定的 
●敏捷使用自上而下的估计 
●敏捷文档通常勉强够用 
●敏捷有利于适应，而传统的管理方法有利于预期 
产品路线图(Product Roadmap) - 提供功能发布里程碑的高级概述。 
项目章程对于敏捷项目和传统项目都很重要，必须在敏捷项目开始时创建。 
帕累托原则：也称为80-20规则指出，对于敏捷项目，80％的最有用的功能可以在20％的努力中完成，强烈建议关注“20％” 
参与式设计：通过积极让利益相关者参与设计过程来确保结果符合预期的设计方法。 
用户故事 
描述用户渴望得到的功能。 
一个好的用户故事包括三个要素： 
 1、角色：谁要使用这个功能。 
 2、活动：需要完成什么样的功能或目标。 
 3、商业价值：为什么需要这个功能，这个功能带来什么样的价值。 
 
 通常按照如下的格式来表达： 
 英文：As a <Role>, I want to <Activity>, so that <Business Value>. 
 中文：作为一个<角色>, 我想要<活动>, 以便于<商业价值> 
 
3C：卡片(Card)、对话(Conversation)和确认(Confirmation)。 
● 卡片（Card）：用户故事一般在小卡片上写着故事的简短描述，工作量估算等。 
● 交谈（Conversation）：用户故事背后的细节来源于和客户或者产品负责人的交流沟通。 
● 确认（Confirmation）：通过验收测试确认用户故事被正确完成。 
 
用户故事的六个特性- INVEST： 
- I dependent(独立的) 
- N egotiable(便于沟通的) 
- V aluable(有价值的) 
- E stimable(可估计的) 
- S mall(短小) 
- T estable(可测试的)