敏捷开发
简介
敏捷开发以用户的需求进化为核心，采用迭代、循序渐进的方法进行软件开发。在敏捷开发中，软件项目在构建初期被切分成多个子项目，各个子项目的成果都经过测试，具备可视、可集成和可运行使用的特征。换言之，就是把一个大项目分为多个相互联系，但也可独立运行的小项目，并分别完成，在此过程中软件一直处于可使用状态。敏捷开发是针对传统的瀑布开发模式的弊端而产生的一种新的开发模式，目标是提高开发效率和响应能力。
敏捷宣言：
个体和交互
|
胜过 |
过程和工具 |
可以工作的软件 |
胜过 |
面面俱到的文档 |
客户合作 |
胜过 |
合同谈判 |
响应变化 |
胜过 |
遵循计划 |
敏捷开发遵循的原则：
-
我们最优先要做的是通过尽早的、持续的交付有价值的软件来使客户满意。
-
即使到了开发的后期，也欢迎改变需求。敏捷过程利用变化来为客户创造竞争优势。
-
经常性地交付可以工作的软件，交付的间隔可以从几个星期到几个月，交付的时间间隔越短越好。
-
在整个项目开发期间，业务人员和开发人员必须天天都在一起工作。
-
围绕被激励起来的个体来构建项目。给他们提供所需的环境和支持，并且信任他们能够完成工作。
-
在团队内部，最具有效果并富有效率的传递信息的方法，就是面对面的交谈。
-
工作的软件是首要的进度度量标准。
-
敏捷过程提倡可持续的开发速度。责任人、开发者和用户应该能够保持一个长期的、恒定的开发速度。
-
不断地关注优秀的技能和好的设计会增强敏捷能力。
-
简单是最根本的。
-
最好的构架、需求和设计出于自组织团队。
-
每隔一定时间，团队会在如何才能更有效地工作方面进行反省，然后相应地对自己的行为进行调整
概览
1. 编写产品backlog
参与人：po+测试负责人 主要责任人：Product owner
形式：excel
内容：ID,Name,importance,Initial estimate,How to demo,Notes
输出物：输出上述内容的excel，输出原型图、功能说明，复杂流程需要流程图
2. 准备sprint计划
责任人：scrum master
形式：无
内容：确认产品backlog井然有序
输出物：无
3. 制定sprint计划
参与人：all 主持人：scrum master
形式：wiki、邮件、白板等
内容：
1. sprint目标
2. 团队成员名单
3. Sprint backlog
4. Sprint演示时间
5. 确定scrum每日会议的时间地点
日程：
13:00-13:30 po介绍sprint目标，概括产品backlog，定下演示时间
13:30-15:00 估算时间，必要情况下按照索引卡的方式拆分backlog条目成任务
15:00-16:00 团队选择放入sprint中的故事，计算生产率
16:00-17：00 进一步拆分故事
输出物：1.确定演示时间
2.确定sprint目标
3.决定sprint要包含的故事
4.拆分故事成任务，并估算时间
5.确定每日会议的时间地点
相关技术：
1. 产品负责人对sprint计划如何施加影响
2. 本能反应估算
3. 生产率估算
4. 索引卡技术
5. 计划纸牌做估算
优先级排序：
1. Sprint目标和演示日期
2. 经过团队认可、要添加到这个sprint中的故事
3. Sprint中每个故事的估算值
4. Sprint中每个故事的“如何演示”
5. 生产率和资源计算
6. 确定每日会议的时间地点
7. 故事拆分成任务
4. 编写sprint backlog
责任人：scrum master
形式：任务板
内容：Not CHECKED OUT ,CHECKED OUT ,DONE!SPRINT GOAL,BURNDOWN,UNPLANNED ITEMS,NEXT
跟踪任务：邮件等
5. 进行每日例会
责任人：team+scrum master+po，主持人：scrum master
主要内容：
1. 昨日干了什么
2. 今天准备干什么
3. 问题与困难（例会并不解决问题，只抛出问题）
输出物：
更新任务板：更新工时、增加即时贴、修改unplanned items，更新燃尽图（scrum master）
相关技术：
1. 处理迟到的家伙
2. 处理“今天不知道干什么的家伙”
6. 进行sprint演示
参与人：all + po觉得应该参与演示的人 操作人：po
内容：对本次sprint进行演示
演示检查列表：
1. 阐述sprint目标
2. 不要花太多时间准备演示，尤其是不要做花里胡哨的演讲。
把那些玩意儿扔一边去，集中精力演示可以实际工作的代
码
3. 节奏要快，也就是说要把准备的精力放在保持演示的快节
奏上，而不是让它看上去好看
4. 让演示关注于业务层次，不要管技术细节。注意力放在“我
们做了什么”，而不是“我们怎么做的”
5. 可能的话，让观众自己试一下产品
6. 不要演示一大堆细碎的 bug 修复和微不足道的特性。你可
以提到一些，但是不要演示，因为它们通常会花很长时间，
而且会分散大家的注意力，让他们不能关注更加重要的故
事。
处理“无法演示”的工作：
1. 技术报告或其他方式
7. 做sprint回顾
责任人：all 主持人：scrum master
主题：怎样在下一个sprint中做的更好
内容：
1. 根据要讨论的内容范围，设定时间为 1 至 3 个小时。
2. 参与者：产品负责人，整个团队还有我自己。
3. 我们换到一个封闭的房间中，或者舒适的沙发角，或者屋
顶平台等等类似的场所。只要能够在不受干扰的情况下讨
论就好。我们一般不会在团队房间中进行回顾，因为这往往会分散
大家的注意力。
4. 指定某人当秘书。
5. Scrum master 向大家展示 sprint backlog，在团队的帮助下对
sprint 做总结。包括重要事件和决策等。
6. 我们会轮流发言。每个人都有机会在不被人打断的情况下
讲出自己的想法，他认为什么是好的，哪些可以做的更好，
哪些需要在下个 sprint 中改变。
7. 我们对预估生产率和实际生产率进行比较。如果差异比较
大的话，我们会分析原因。
8. 快结束的时候， Scrum master 对具体建议进行总结，得出
下个 sprint 需要改进的地方
输出物：
附：瀑布式开发
简介
瀑布式（WM：Waterfall Model）开发是一种老旧的，正在过时的计算机软件开发方法。最开始的软件行业普遍采用这种方法，但是这种方法套用自传统工业生产，不适应计算机软件开发的具体情况。
大体分为这几个阶段：制定计划、需求分析、软件设计、程序编写、软件测试和运行维护等六个基本活动。
