软件开发之道
- 软件开发是一个逐步认知和明晰的活动
- 软件开发中的变化是实际存在和必然的
软件开发应更关注于交付的价值
- 高质量的交付物是最重要的
- 系统不是一次构建而成，而是迭代演进的
- 基于完整的场景构建计划，并按优先级执行
互联网时代的软件开发
互联网产品的开发特点
- 快鱼吃慢鱼
- 版本发布成本很低
- 追求创新
- 需要快速响应用户的变化
- 需求不确定性高
- 关注用户行为
敏捷开发方法
敏捷开发是一种基于更紧密的团队协作、能够有效应对快速变化需求、快速交付高质量软件的迭代和增量的新型软件开发方法。
- 更关注协作
- 更关注质量
- 更关注可工作的产品
- 更关注全才化的专才
- 基于实践而非基于理论
敏捷方法：适应而非预测
- 需求是不可预测的
- 软件开发应是一个自适应的跟踪过程
敏捷宣言
- 我们的最高目标是，通过尽早和持续地交付有价值的软件来满足客户。
- 欢迎对需求提出变更——即使是在项目开发后期。要善于利用需求变更，帮助客户获得竞争优势。
- 要不断交付可用的软件，周期从几周到几个月不等，且越短越好。
- 项目过程中，业务人员与开发人员必须在一起工作。
- 要善于激励项目人员，给他们以所需要的环境和支持，并相信他们能够完成任务。
- 无论是团队内还是团队间，最有效的沟通方法是面对面的交谈。
- 可用的软件是衡量进度的主要指标。
- 敏捷过程提倡可持续的开发速度，项目方、开发人员和用户应该能够保持恒久稳定的进展速度。
- 坚持不懈地追求技术卓越和良好设计，这将提升敏捷能力。
- 要做到简单，即尽最大可能减少不必要的工作，这是一门艺术。
- 最佳的架构、需求和设计出自于自组织的团队。
- 团队要定期反省如何能够做到更有效，并相应地调整团队的行为。
敏捷开发方法
敏捷开发方法是一组轻量级开发方法的总称，包含很多具体的开发过程和方法，最有影响的两个方法是极限编程（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：
- 以在市场上赢得用户为目的而构建的软件。这也是种种科学发现，技术突破最好的试金石。所有以营利为目的的公司和团队都在为此努力。
