Open xingbofeng opened 7 years ago
从知道创宇离职接近一个月的时间了，深知自己还有最后一点学到的东西没有把它浓缩提炼成自己的东西，今天偶然翻开我的笔记本，或许敏捷开发流程，是我在知道创宇实习期间，除了技术和职场经验，另外一个收获最大的方面了。
以下摘自维基百科——敏捷开发：
敏捷软件开发（英语：Agile software development），又称敏捷开发，是一种从1990年代开始逐渐引起广泛关注的一些新型软件开发方法，是一种应对快速变化的需求的一种软件开发能力。它们的具体名称、理念、过程、术语都不尽相同，相对于“非敏捷”，更强调程序员团队与业务专家之间的紧密协作、面对面的沟通（认为比书面的文档更有效）、频繁交付新的软件版本、紧凑而自我组织型的团队、能够很好地适应需求变化的代码编写和团队组织方法，也更注重软件开发过程中人的作用。
传统的软件开发中，我们通常采用瀑布式的开发流程，它严格遵循预先计划的需求、分析、设计、编码、测试的步骤顺序进行。步骤成果作为衡量进度的方法，例如需求规格，设计文档，测试计划和代码审阅等等。
但传统的瀑布式开发流程中，对比与敏捷开发，也就存在巨大的缺陷了，首先，传统的瀑布式开发流程，每个阶段周期长，一旦需求变更，也许会让开发人员感到手忙脚乱、措手不及。它的严格分级导致的自由度降低，项目早期即作出承诺导致对后期需求的变化难以调整，代价高昂。瀑布式方法在需求不明并且在项目进行过程中可能变化的情况下基本是不可行的。
曾经记得之前在做ASMS项目的时候，项目负责人，也就是指导老师（产品经理），在反复提出需求并作出更改的过程中，加大了开发人员的开发难度，最终使得团队的核心成员离开，导致项目的失败。
这也许就算是传统瀑布式开发的缺陷吧！
当时不太理解的我，在接触到了敏捷开发流程之后，从在知道创宇的实习经历，也是让我慢慢明白到了这一点。
以下引用自敏捷开发——互联网时代的软件开发方式： 在互联网时代，一切开发流程的变化实在是太快了，我们必须要保证我们项目推进过程中，不会因为某一次变化而让我们的开发人员大动干戈、措手不及，因而开发过程中我们必须要具备快速试错和拥抱变化的特点。
今年张小龙在WXG大会上提到：
『我们今天可以想一些与众不同的点子，然后我们可以很快就看到效果，因为我们可以很快把它上线了，然后可以去验证，如果不对就下线，如果还有改进余地，下个版本再去改它。这是一个能够持续实现你的想法的过程』
张小龙所说的上线、验证、改进的持续循环流程实际上就是一个快速试错和拥抱变化的过程。 当今的互联网，市场变化日新月异，在不断变化的市场中取得成功就要拥有快速试错的能力。
下面是滴滴打车最新的客户端截图。从图中可以看到，滴滴支持的全部车辆服务已经覆盖到了快车、小巴、出租车、顺风车、专车等多达10种服务，而大众刚刚熟悉滴滴时，滴滴仅有出租车、快车和顺风车三种车型。
试想如果滴滴从一开始就计划设计出10种车型再开始上线推广，那估计现在满街跑的就该是Uber或者快的或者什么滴而不是滴滴了。商机转瞬即逝，正是在一次次的上线中，从车主、用户及市场的反馈中不断调整迭代，才造就了今天的滴滴，而这正是敏捷思想的精髓所在。
Scrum是一种敏捷软件开发的方法学，用于迭代式增量软件开发过程。Scrum在英语是橄榄球运动中争球的意思。 虽然Scrum是为管理软件开发项目而开发的，它同样可以用于运行软件维护团队，或者作为计划管理方法。Scrum之间的合作称为“Scrum of Scrums”。
以下内容参考至scrum中文网：
之所以把 极端编程、持续集成、测试驱动开发、结对编程和Code Review加入到这篇文章，其中一方面的原因是确实在知道创宇实习期间慢慢接触了一些这方面的内容，包括导师也有所讲述和归纳。此外，它们也和敏捷开发流程脱离不开关系。
极限编程（英语：Extreme programming，缩写为XP），是一种软件工程方法学，是敏捷软件开发中最富有成效的几种方法学之一。如同其他敏捷方法学，极限编程和传统方法学的本质不同在于它更强调可适应性而不是可预测性。极限编程的支持者认为软件需求的不断变化是很自然的现象，是软件项目开发中不可避免的、也是应该欣然接受的现象；他们相信，和传统的在项目起始阶段定义好所有需求再费尽心思的控制变化的方法相比，有能力在项目周期的任何阶段去适应变化，将是更加现实更加有效的方法。 极限编程为管理人员和开发人员开出了一剂指导日常实践的良方；这个实践意味着接受并鼓励某些特别的有价值的方法。支持者相信，这些在传统的软件工程中看来是“极端的”实践，将会使开发过程比传统方法更加好的响应用户需求，因此更加敏捷，更好的构建出高质量软件。
此外，每个迭代周期的开发前、开发中、已完成状态是极端编程的三个极端。
持续集成（英语：Continuous integration，缩写为 CI），一种软件工程流程，将所有工程师对于软件的工作复本，每天集成数次到共用主线（mainline）上。这个名称最早由葛来迪·布区（Grady Booch）在他的布区方法中提出，但是他并没有提到要每天集成数次。之后成为极限编程（extreme programming，缩写为XP）的一部分。在测试驱动开发（TDD）的作法中，通常还会搭配自动单元测试。持续集成的提出，主要是为了解决软件进行系统集成时面临的各项问题，极限编程称这些问题为集成地狱（integration hell）。
测试驱动开发（英语：Test-driven development，缩写为TDD）是一种软件开发过程中的应用方法，由极限编程中倡导，以其倡导先写测试程序，然后编码实现其功能得名。测试驱动开发始于20世纪90年代。测试驱动开发的目的是取得快速反馈并使用“illustrate the main line”方法来构建程序。
测试驱动开发是戴两顶帽子思考的开发方式：先戴上实现功能的帽子，在测试的辅助下，快速实现其功能；再戴上重构的帽子，在测试的保护下，通过去除冗余的代码，提高代码质量。测试驱动着整个开发过程：首先，驱动代码的设计和功能的实现；其后，驱动代码的再设计和重构。
测试驱动开发可以有效的避免过度设计带来的浪费。但是也有人强调在开发前需要有完整的设计再实施可以有效的避免重构带来的浪费。此外，可以让开发者在开发中拥有更全面的视角。
结对编程（英语：Pair programming）是一种敏捷软件开发的方法，两个程序员在一个计算机上共同工作。一个人输入代码，而另一个人审查他输入的每一行代码。输入代码的人称作驾驶员，审查代码的人称作观察员（或导航员）。两个程序员经常互换角色。 在结对编程中，观察员同时考虑工作的战略性方向，提出改进的意见，或将来可能出现的问题以便处理。这样使得驾驶者可以集中全部注意力在完成当前任务的“战术”方面。观察员当作安全网和指南。结对编程对开发程序有很多好处。比如增加纪律性，写出更好的代码等。
代码审查（英语：Code review）是指对计算机源代码系统化地审查，常用软件同行评审的方式进行，其目的是在找出及修正在软件开发初期未发现的错误，提升软件质量及开发者的技术。代码审查常以不同的形式进行，例如结对编程、非正式的看过整个代码，或是正式的软件检查。 Code Review要做到以下三点内容：
虽然极端编程、持续集成、测试驱动开发、结对编程和Code Review都会使得开发效率有所变慢，但是从长远来开，代码质量的提升和维护成本的下降是不可估量的。
从知道创宇离职接近一个月的时间了，深知自己还有最后一点学到的东西没有把它浓缩提炼成自己的东西，今天偶然翻开我的笔记本，或许敏捷开发流程，是我在知道创宇实习期间，除了技术和职场经验，另外一个收获最大的方面了。
什么是敏捷开发？
以下摘自维基百科——敏捷开发：
敏捷软件开发（英语：Agile software development），又称敏捷开发，是一种从1990年代开始逐渐引起广泛关注的一些新型软件开发方法，是一种应对快速变化的需求的一种软件开发能力。它们的具体名称、理念、过程、术语都不尽相同，相对于“非敏捷”，更强调程序员团队与业务专家之间的紧密协作、面对面的沟通（认为比书面的文档更有效）、频繁交付新的软件版本、紧凑而自我组织型的团队、能够很好地适应需求变化的代码编写和团队组织方法，也更注重软件开发过程中人的作用。
为什么需要敏捷开发？
传统的软件开发中，我们通常采用瀑布式的开发流程，它严格遵循预先计划的需求、分析、设计、编码、测试的步骤顺序进行。步骤成果作为衡量进度的方法，例如需求规格，设计文档，测试计划和代码审阅等等。
但传统的瀑布式开发流程中，对比与敏捷开发，也就存在巨大的缺陷了，首先，传统的瀑布式开发流程，每个阶段周期长，一旦需求变更，也许会让开发人员感到手忙脚乱、措手不及。它的严格分级导致的自由度降低，项目早期即作出承诺导致对后期需求的变化难以调整，代价高昂。瀑布式方法在需求不明并且在项目进行过程中可能变化的情况下基本是不可行的。
曾经记得之前在做ASMS项目的时候，项目负责人，也就是指导老师（产品经理），在反复提出需求并作出更改的过程中，加大了开发人员的开发难度，最终使得团队的核心成员离开，导致项目的失败。
这也许就算是传统瀑布式开发的缺陷吧！
当时不太理解的我，在接触到了敏捷开发流程之后，从在知道创宇的实习经历，也是让我慢慢明白到了这一点。
以下引用自敏捷开发——互联网时代的软件开发方式： 在互联网时代，一切开发流程的变化实在是太快了，我们必须要保证我们项目推进过程中，不会因为某一次变化而让我们的开发人员大动干戈、措手不及，因而开发过程中我们必须要具备快速试错和拥抱变化的特点。
今年张小龙在WXG大会上提到：
『我们今天可以想一些与众不同的点子，然后我们可以很快就看到效果，因为我们可以很快把它上线了，然后可以去验证，如果不对就下线，如果还有改进余地，下个版本再去改它。这是一个能够持续实现你的想法的过程』
张小龙所说的上线、验证、改进的持续循环流程实际上就是一个快速试错和拥抱变化的过程。 当今的互联网，市场变化日新月异，在不断变化的市场中取得成功就要拥有快速试错的能力。
下面是滴滴打车最新的客户端截图。从图中可以看到，滴滴支持的全部车辆服务已经覆盖到了快车、小巴、出租车、顺风车、专车等多达10种服务，而大众刚刚熟悉滴滴时，滴滴仅有出租车、快车和顺风车三种车型。
试想如果滴滴从一开始就计划设计出10种车型再开始上线推广，那估计现在满街跑的就该是Uber或者快的或者什么滴而不是滴滴了。商机转瞬即逝，正是在一次次的上线中，从车主、用户及市场的反馈中不断调整迭代，才造就了今天的滴滴，而这正是敏捷思想的精髓所在。
敏捷开发方法：Scrum
什么是Scrum？
Scrum是一种敏捷软件开发的方法学，用于迭代式增量软件开发过程。Scrum在英语是橄榄球运动中争球的意思。 虽然Scrum是为管理软件开发项目而开发的，它同样可以用于运行软件维护团队，或者作为计划管理方法。Scrum之间的合作称为“Scrum of Scrums”。
Scrum的3+3+5+5原则
以下内容参考至scrum中文网：
极端编程、持续集成、测试驱动开发、结对编程和Code Review
之所以把 极端编程、持续集成、测试驱动开发、结对编程和Code Review加入到这篇文章，其中一方面的原因是确实在知道创宇实习期间慢慢接触了一些这方面的内容，包括导师也有所讲述和归纳。此外，它们也和敏捷开发流程脱离不开关系。
极端编程
极限编程（英语：Extreme programming，缩写为XP），是一种软件工程方法学，是敏捷软件开发中最富有成效的几种方法学之一。如同其他敏捷方法学，极限编程和传统方法学的本质不同在于它更强调可适应性而不是可预测性。极限编程的支持者认为软件需求的不断变化是很自然的现象，是软件项目开发中不可避免的、也是应该欣然接受的现象；他们相信，和传统的在项目起始阶段定义好所有需求再费尽心思的控制变化的方法相比，有能力在项目周期的任何阶段去适应变化，将是更加现实更加有效的方法。 极限编程为管理人员和开发人员开出了一剂指导日常实践的良方；这个实践意味着接受并鼓励某些特别的有价值的方法。支持者相信，这些在传统的软件工程中看来是“极端的”实践，将会使开发过程比传统方法更加好的响应用户需求，因此更加敏捷，更好的构建出高质量软件。
此外，每个迭代周期的开发前、开发中、已完成状态是极端编程的三个极端。
持续集成
持续集成（英语：Continuous integration，缩写为 CI），一种软件工程流程，将所有工程师对于软件的工作复本，每天集成数次到共用主线（mainline）上。这个名称最早由葛来迪·布区（Grady Booch）在他的布区方法中提出，但是他并没有提到要每天集成数次。之后成为极限编程（extreme programming，缩写为XP）的一部分。在测试驱动开发（TDD）的作法中，通常还会搭配自动单元测试。持续集成的提出，主要是为了解决软件进行系统集成时面临的各项问题，极限编程称这些问题为集成地狱（integration hell）。
测试驱动开发
测试驱动开发（英语：Test-driven development，缩写为TDD）是一种软件开发过程中的应用方法，由极限编程中倡导，以其倡导先写测试程序，然后编码实现其功能得名。测试驱动开发始于20世纪90年代。测试驱动开发的目的是取得快速反馈并使用“illustrate the main line”方法来构建程序。
测试驱动开发是戴两顶帽子思考的开发方式：先戴上实现功能的帽子，在测试的辅助下，快速实现其功能；再戴上重构的帽子，在测试的保护下，通过去除冗余的代码，提高代码质量。测试驱动着整个开发过程：首先，驱动代码的设计和功能的实现；其后，驱动代码的再设计和重构。
测试驱动开发可以有效的避免过度设计带来的浪费。但是也有人强调在开发前需要有完整的设计再实施可以有效的避免重构带来的浪费。此外，可以让开发者在开发中拥有更全面的视角。
结对编程
结对编程（英语：Pair programming）是一种敏捷软件开发的方法，两个程序员在一个计算机上共同工作。一个人输入代码，而另一个人审查他输入的每一行代码。输入代码的人称作驾驶员，审查代码的人称作观察员（或导航员）。两个程序员经常互换角色。 在结对编程中，观察员同时考虑工作的战略性方向，提出改进的意见，或将来可能出现的问题以便处理。这样使得驾驶者可以集中全部注意力在完成当前任务的“战术”方面。观察员当作安全网和指南。结对编程对开发程序有很多好处。比如增加纪律性，写出更好的代码等。
Code Review
代码审查（英语：Code review）是指对计算机源代码系统化地审查，常用软件同行评审的方式进行，其目的是在找出及修正在软件开发初期未发现的错误，提升软件质量及开发者的技术。代码审查常以不同的形式进行，例如结对编程、非正式的看过整个代码，或是正式的软件检查。 Code Review要做到以下三点内容：
总结
虽然极端编程、持续集成、测试驱动开发、结对编程和Code Review都会使得开发效率有所变慢，但是从长远来开，代码质量的提升和维护成本的下降是不可估量的。
参考资料