软件开发之道

• 软件开发是一个逐步认知和明晰的活动
• 软件开发中的变化是实际存在和必然的

软件开发应更关注于交付的价值

• 高质量的交付物是最重要的
• 系统不是一次构建而成，而是迭代演进的
• 基于完整的场景构建计划，并按优先级执行

互联网时代的软件开发

互联网产品的开发特点

• 快鱼吃慢鱼
• 版本发布成本很低
• 追求创新
• 需要快速响应用户的变化
• 需求不确定性高
• 关注用户行为

敏捷开发方法

敏捷开发是一种基于更紧密的团队协作、能够有效应对快速变化需求、快速交付高质量软件的迭代和增量的新型软件开发方法。

• 更关注协作
• 更关注质量
• 更关注可工作的产品
• 更关注全才化的专才
• 基于实践而非基于理论

敏捷方法：适应而非预测

• 需求是不可预测的
• 软件开发应是一个自适应的跟踪过程

敏捷宣言

• 我们的最高目标是，通过尽早和持续地交付有价值的软件来满足客户。
• 欢迎对需求提出变更——即使是在项目开发后期。要善于利用需求变更，帮助客户获得竞争优势。
• 要不断交付可用的软件，周期从几周到几个月不等，且越短越好。
• 项目过程中，业务人员与开发人员必须在一起工作。
• 要善于激励项目人员，给他们以所需要的环境和支持，并相信他们能够完成任务。
• 无论是团队内还是团队间，最有效的沟通方法是面对面的交谈。
• 可用的软件是衡量进度的主要指标。
• 敏捷过程提倡可持续的开发速度，项目方、开发人员和用户应该能够保持恒久稳定的进展速度。
• 坚持不懈地追求技术卓越和良好设计，这将提升敏捷能力。
• 要做到简单，即尽最大可能减少不必要的工作，这是一门艺术。
• 最佳的架构、需求和设计出自于自组织的团队。
• 团队要定期反省如何能够做到更有效，并相应地调整团队的行为。

敏捷开发方法

敏捷开发方法是一组轻量级开发方法的总称，包含很多具体的开发过程和方法，最有影响的两个方法是极限编程（XP）和Scrum开发方法。

Scrum迭代开发

迭代开发将整个软件生命周期分成多个小的迭代（一般2~4周），每一次迭代就是一个小的瀑布模型，包括需求分析、设计、实现和测试等活动，结束时都要生成一个稳定和被验证过的软件版本。

迭代开发的关键要点：

• 每一次迭代都建立在稳定的质量基础上，并做为下一轮迭代的基线，整个系统的功能随着迭代稳定地增长和不断完善。
• 每次迭代要邀请用户代表验收，提供需求是否满足的反馈。
• 在一次迭代中，一旦团队作出承诺，就不允许变更交付件和交付日期；如果发生重大变化，产品负责人可以中止当次迭代。
• 在迭代中可能会出现“分解”和“澄清”，但是不允许添加新工作或者对现有的工作进行“实质变更”。
• 对于“分解”和“澄清”，如果存在争议，那么将其认定为变更，放到产品订单中下一次迭代再考虑。

敏捷开发应用

• ISO 9000（09版）标准将在原来八大原则的基础上新增敏捷原则
• 2000年美国军方软件开发标准（DOD 5000.2）推荐迭代为软件开发优选模式
• 2013年发布的新版PMBOK增加迭代及增量生命周期（即对应敏捷模型）

Different types of "Building"

Build To Learn:

• 开发软件，构建系统的目的是做进一步的试验，试图发现客观规律或某个试验方法的优点与缺点。这些项目经常是科研论文的基础工作。

Build To Show：

• 为了突出地展现某个技术的作用，开发一些演示为目的的软件，这些项目很吸引眼球，经常获得新闻报道，但是功能未必全面或实用。

Build To Serve：

• 为了服务一定范围的目标用户而构建的工具等，有时以公开的SDK形式发布，让别的研发人员使用。

Build To Win：

• 以在市场上赢得用户为目的而构建的软件。这也是种种科学发现，技术突破最好的试金石。所有以营利为目的的公司和团队都在为此努力。