敏捷开发之 12条敏捷原则
1、我们最重要的目标，是通过持续不断地及早交付有价值的软件使客户满意。
2、欣然面对需求变化，即使在开发后期也一样。为了客户的竞争优势，敏捷过程掌握变化。
3、经常地交付可以工作的软件，相隔几星期或一两个月，倾向于采取较短的周期。
4、业务人员和开发人员必须相互合作，项目中的每一天都不例外。
5、激发个体的斗志，以他们为核心搭建项目。提供所需的环境和支援，辅以信任，从而达成目标。
6、不论团队内外，传递信息效果最好效率也最高的方式是面对面的交流。
7、可工作的软件是进度的首要度量标准。
8、敏捷过程倡导可持续开发。责任人、开发人员和用户要能够共同维持其步调稳定延续。
9、坚持不懈地追求技术卓越和良好设计，敏捷能力由此增强。
10、以简洁为本，它是极力减少不必要工作量的艺术。
11、最好的构架、需求和设计出自与自组织团队。
12、团队定期地反思如何能提供成效，并依次调整自身的举止表现。
在敏捷开发中，软件项目在构建初期被切分成多个子项目，各个子项目的成果都经过测试，具备可视、可集成和可运行使用的特征。换言之，就是把一个大项目分为多个相互联系，但也可独立运行的小项目，并分别完成，在此过程中软件一直处于可使用状态。
传统的开发模式和敏捷开发模式的对比
瀑布模型：
优点：
1. 为项目提供了按阶段划分的检查点。
2. 当前一阶段完成后，您只需要去关注后续阶段.
3. 它提供了一个模板，这个模板使得分析、设计、编码、测试和支持的方法可以在该模板下有一个共同的指导。
缺点：
1. 各个阶段的划分完全固定，阶段之间产生大量的文档，极大地增加了工作量。
2. 由于开发模型是线性的，用户只有等到整个过程的末期才能见到开发成果，从而增加了开发风险。
3. 通过过多的强制完成日期和里程碑来跟踪各个项目阶段。
4. 瀑布模型的突出缺点是不适应用户需求的变化。
敏捷模型：
优点：
敏捷开发的高适应性，以人为本的特性。
更加的灵活并且更加充分的利用了每个开发者的优势，调动了每个人的工作热情。
缺点：
由于其项目周期很长，所以很难保证开发的人员不更换，而没有文档就会造成在交接的过程中出现很大的困难。
敏捷开发scrum的实施
Scrum的英文意思是橄榄球运动的一个专业术语，表示“争球”的动作；把一个开发流程的名字取名为Scrum，相当于大家像打橄榄球一样迅速、富有战斗激情。而Scrum就是这样的一个开发流程。
Scrum开发流程中的三大角色
– 产品负责人（Product Owner）
主要负责确定产品的功能和达到要求的标准，指定软件的发布日期和交付的内容，同时有权力接受或拒绝开发团队的工作成果。
– 流程管理员（Scrum Master）
主要负责整个Scrum流程在项目中的顺利实施和进行，以及清除挡在客户和开发工作之间的沟通障碍，使得客户可以直接驱动开发。
–开发团队（Scrum Team）
主要负责软件产品在Scrum规定流程下进行开发工作，人数控制在5~10人左右，每个成员可能负责不同的技术方面，但要求每成员必须要有很强的自我管理能力，同时具有一定的表达能力；成员可以采用任何工作方式，只要能达到Sprint的目标。
scrum开发流程图
1、我们首先需要确定一个Product Backlog（产品需求列表），这个是由PO负责的（如图（一））；
2、有了Product Backlog列表，我们需要通过 Sprint Planning Meeting（Sprint计划会议） 来从中挑选出一个Story作为本次迭代完成的目标，这个目标的时间周期是1~4个星期，然后把这个Story进行细化，形成一个Sprint Backlog；
3、Sprint Backlog是由Scrum Team去完成的，每个成员根据Sprint Backlog再细化成更小的任务（细到每个任务的工作量在2天内能完成）；
4、在Scrum Team完成计划会议上选出的Sprint Backlog过程中，需要进行 Daily Scrum Meeting（每日站立会议），每次会议控制在15分钟左右，每个人都必须发言，并且要向所有成员当面汇报你昨天完成了什么，并且向所有成员承诺你今天要完成什么，同时遇到不能解决的问题也可以提出，每个人回答完成后，要走到黑板前更新自己的 Sprint burn down（Sprint燃尽图）（如图（二）和如图（三））；
5、做到每日集成，也就是每天都要有一个可以成功编译、并且可以演示的版本。
6、当一个Story完成，也就是Sprint Backlog被完成，也就表示一次Sprint完成，这时，我们要进行 Srpint Review Meeting（演示会议），也称为评审会议，产品负责人和客户都要参加（最好本公司老板也参加），每一个Scrum Team的成员都要向他们演示自己完成的软件产品。
7、最后就是 Sprint Retrospective Meeting（回顾会议），也称为总结会议，以轮流发言方式进行，每个人都要发言，总结并讨论改进的地方，放入下一轮Sprint的产品需求中；
敏捷开发管理工具：teambition
teambition
scrum开发流程
Product Owner在项目开始时将任务放进Product backlog，由于需求是增量式获取的，因此这个过程也是增量式的向Product backlog中添加任务。
在每次sprint开始时，进行sprint plan meeting，会议上由product owner确定product backloug中任务的优先级，scrum团队决定本次sprint要完成的任务，将任务分解成工作项并进行工期估算，同时将任务从product backlog转移到sprint backlog。冲刺阶段每日进行sprint daily meeting，每次在15分钟左右。两个主题：昨天完成了什么，今天计划做什么。有困难提出但会后和相关干系人讨论，不占用会上时间。冲刺结束时进行冲刺评审，对本次冲刺完成的任务进行演示。检查完成情况。冲刺评审之后进行冲刺回顾，回顾过去的冲刺存在的问题，提出改进方案。重复以上过程，直到完成所有任务。
几种中国式的敏捷：
极限编程：每天只工作8小时，还没有达到极限，工作不饱和。来来来多给你分配点任务。
拥抱变化：产品、需求频繁变更，朝令夕改，昨天说好的今天又变卦。
迭代式开发：做完了赶紧上线，出了问题再修复一版更新上去。
持续集成：每天提交几百行代码，不用编译不用自测不用测试用例。
测试驱动：点了两下没发现问题就可以发布了。
迭代回顾：新版本刚上线肯定有很多问题，这两天辛苦一下。24小时待命。
sprint冲刺：明天版本上线，大家辛苦通宵冲刺一下。
结对编程：开玩笑，一个人的任务两个人轮流干，每人只领一半工资行不行。
5种工件
Sprint:冲刺,一个固定的时间周期（通常为2w-4w）,团队要尽可能在这个周期内交付可以工作的软件给客户
sprint planning meeting:冲刺开始的时候，PO会和团队一起从PB中选择本次要做的任务/故事，并且会对团队提出的疑问进行解释和澄清。同时团队会估算故事并分解成任务，最后会形成本次的Sprint Backlog.
daily standupo meeting:每日站会，scrum为了加强团队沟通，每天团队都要选择一个时间站在一起，互相交流彼此的进展和问题,以便及时解决出现的问题，同时也能让团队随时了解我们离冲刺目标还有多远。
sprint review:在sprint周期最后，需要进行一次评审会议，让团队向产品负责人和利益相关者展示已完成的功能。sprint审核的大部分实践用于团队成员展示功能、回答利益相关者对展示的疑问并记录所期望的更改。评审会议可以吸引相关利益者的关注，让其他人了解团队在做些什么，并得到重要反馈。做演示也会迫使开发团队真正完成一些工作。
retrospective meeting:回顾会议，通常在reivew会议之后开始，有团队成员在冲刺结束之后对上个迭代进行总结，同时提出一些改进方案，这是一个持续改进的过程。
SCRUM的其他一些要素：
user story:用户故事，因为敏捷要求每个特性都是对客户有价值的，所以以用户故事的方式来设计特性，通常是作为客户，我要实现A功能，以至于我可以达到什么目的的结构。
task:每个迭代中为了开发一个user story,将其分解为一些task,比如说我要开发一个协议，其中需要几个task,包括搭建服务器，找一些开源代码，搭建自动化测试框架，编码，测试任务，便于更小粒度的track每个迭代的进展。
release planning:在某些大型组织，可能更关注release级别的产品交付，所以每个release之前要进行整个release的plan,决定这个release的PB。
points:故事点数，代表用户故事的大小，要记住，这里的大小不代表开发时间，只是一个相对的用户故事的复杂度，工作量大小。因为很难理解，所以scrum team要建立一个基准的user story，作为一个points，然后其他的user story和它进行相对比较。这个points大部分时间用来作为评估team的交付能力。
SCRUM各个角色之间的关系和作用：
PO和team的关系：一个人拿到了客户的一个项目，开发一个产品，他就是ＰＯ，他想找一个团队开做这个产品，但是现在有Ａ团队和Ｂ团队，Ａ团队跟PO说，ok,交给我吧，3个月后你过来，我们把产品给你.而B团队说，我们每个月都可以让你看一下我们的产品，但是可能一开始功能不完善，但是可以工作的，然后你可以把我们的产品给客户看，如果运气好的话客户可能先给你点钱呢。
如果你作为PO，你会选择哪个团队呢？对了，A就是传统的开发团队，而B则是我们的scrum team.
scrum master和team还有PO的关系：
个人给SM有以下几个定义：
Team Coach: 不仅在在流程上辅导团队，还要帮助大家接受敏捷开发理念，推动团队按照敏捷价值观和原则所倡导的方法来做出决策。
Servant Leader：Scrum Master服务于团队，帮助团队解决工作中的困难，引导团队自组织的高效完成每日工作，但是并不是团队的管理者。
Team Protector: 作为团队保护者，SM7要敢于说不，尽量保证团队在每个冲刺中不被打扰，如果发现有影响团队工作的临时任务，一定要站出来保护团队。