mod

极客时间专栏/软件工程之美/基础理论/01 | 到底应该怎样理解软件工程？.md

@@ -0,0 +1,129 @@
+<audio id="audio" title="01 | 到底应该怎样理解软件工程？" controls="" preload="none"><source id="mp3" src="https://static001.geekbang.org/resource/audio/ae/d7/ae41f11ef249a3a63ea7315bad3334d7.mp3"></audio>
+
+**你好，我是宝玉，我今天分享的主题是：什么是软件工程？**
+
+当有人问你什么是软件工程，你会想到什么？
+
+也许你会想到软件，会想到建筑工程，也许对此还没有什么概念。不要紧，在回答这个问题前，我们先来看看软件工程和我们的日常生活有哪些关系。
+
+作为一个程序员，你的日常大致是这样的：早上被手机的闹钟叫醒，然后坐地铁去上班。在路上你会打开微信和朋友闲聊几句，刷刷微博，还会用Youtube看看视频充充电；上班的时候，你打开Mac电脑，用VS Code写程序，用Chrome看网页，下班后再玩几局守望先锋游戏。
+
+你发现了没？在这一天的日常生活里面，软件无处不在。手机操作系统软件、闹钟App、微信、微博、Youtube、Mac OS、VS Code、Chrome、守望先锋，这些都是软件，你的日常生活已经和这些软件密不可分。
+
+## 软件是怎么被创造出来的？
+
+那么你有没有想过，这些软件是怎么来的呢？
+
+首先，它们的诞生都是有人想要造一个东西。这其中的很多故事你都耳熟能详：张小龙创造微信、乔布斯创造iOS、暴雪想做一款不一样的射击游戏……他们首先有着这样的意图，然后，他们立项做这样的产品。
+
+每一款软件项目背后，都有很多人在参与。你无法想象微信这样复杂的App靠张小龙自己可以开发出来；你也不会相信iOS是乔布斯一个人设计出来的；像守望先锋这种游戏的背后，有成百上千的游戏策划、美术设计、程序开发人员。
+
+从立项到第一个版本的发布，每个成功的软件都需要有计划、有步骤地进行，什么时候发布第一个版本、第一个版本有什么样的功能、什么时候发布第二个版本、第二个版本有哪些地方要改进，这些都是研发过程中需要考虑的问题。
+
+比如，守望先锋是在2013年立项，他们计划做一个基于职业的 MMO 游戏，他们先花了几个月的时间做了第一个Demo演示，只有四个英雄和一个张地图。
+
+<img src="https://static001.geekbang.org/resource/image/a0/9e/a04f39349e6f3de9c10781f8da8f779e.jpeg" alt="" title="图片来源：The treasures of the Overwatch Archives panel at Blizzcon">
+
+然后，他们要在 2014 年的“暴雪嘉年华”发布这个游戏的试玩版，包含12个英雄和4张地图。
+
+<img src="https://static001.geekbang.org/resource/image/ae/e1/ae4a7ceadb1163240508a5d125a092e1.jpeg" alt="" title="图片来源：The treasures of the Overwatch Archives panel at Blizzcon">
+
+最终这个游戏在2016年5月正式发布了。这样从立项一步步到最终发布，历时三年，中间经过了诸多环节。
+
+类似的例子还有微信，2010年11月20日立项，2011年1月21日第一版上线，当时的功能还非常简陋，只能发送文本消息和照片。之后才是一个个版本的迭代，直到你现在看到的微信。
+
+**像这种有人参与、有计划、有步骤地造一件产品，我们通常称为“工程”。**
+
+所有工程的本质，就是要做出有用的产品，比如造房子的建筑工程、造火箭的航天工程。像网红“手工耿”一样专搞无用发明的情况，我们是不能称为“工程”的。
+
+在软件领域，对应的就是“软件工程”，这些我们日常使用的软件背后，都是基于软件工程的方法在开发、运行和维护的。
+
+## 如何摆脱“软件危机”？
+
+也许有人会认为，不用软件工程，我一样可以开发软件出来。这确实没有错，因为如果一个人没有学过建筑工程，他也是可以造一个房子出来，只是造出来大概会是这个样子：
+
+<img src="https://static001.geekbang.org/resource/image/57/52/57222a73010237e5ab069351b535df52.jpg" alt="">
+
+我们知道，不按照建筑工程造房子，是会出事故甚至死人的。而在软件工程的历史上，也是真的有造成过很大损失、甚至还有人为之丧命的事件存在。
+
+OS/360操作系统是上世纪60年代最复杂的软件系统之一，也是第一个超大型的软件项目，一共有1000名左右的程序员参与了项目的研发，花费了5000个人年，最终无法运行。项目负责人佛瑞德·布鲁克斯后来写了一本软件工程的经典书籍《人月神话》，承认在他管理这个项目的时候，犯了很多错误，造成了价值数百万美元的损失。
+
+如果是说OS/360还只是造成了经济损失的话，Therac-25事件就是真的导致了人员死亡。Therac-25是加拿大原子能有限公司（AECL）所生产的放射线疗法机器，在1985年到1987年之间，在美国及加拿大，至少有六起和Therac-25相关的医疗事故是因为程序bug，导致部分病患受到比正常剂量高一百倍的辐射，因而造成患者重伤甚至死亡。
+
+发生这些惨痛的事，原因却并不难理解。
+
+在计算机刚发明出来的时候，计算机的能力非常有限，只能接收简单的指令和运算，不需要软件工程也可以开发出简单的软件。
+
+但是，当软件的规模越来越大，复杂度不断增加，软件项目开发维护过程中的问题就逐步暴露出来：**软件产品质量低劣、软件维护工作量大、成本不断上升、进度不可控、程序人员无限度地增加。**所以在60年代，“软件危机”的概念被提出来。
+
+为了摆脱软件危机，1968年秋季，北大西洋公约组织的科技委员会召集了近50名一流的编程人员、计算机科学家和工业界巨头，讨论和制定对策。在那次会议上第一次提出了“软件工程”（software engineering）这个概念。
+
+从此诞生了一门新兴的工程学科：**软件工程，它是为研究和克服软件危机而生。**
+
+在这次会议上，同时也提出了“软件工程”的定义：
+
+> 
+<p>为了经济地获得在真实机器上可靠工作的软件而制定和使用的合理工程原则。<br>
+（Software engineering is the establishment and use of sound engineering principles in order to obtain economically software that is reliable and works efficiently on real machines.）</p>
+
+
+1993年，电气电子工程师学会（IEEE）给出了一个更加综合的定义：
+
+> 
+<p>将系统化的、规范的、可度量的方法用于软件的开发、运行和维护的过程，即将工程化应用于软件开发中。<br>
+（Software Engineering: (1) The application of a systematic, disciplined, quantifiable approach to the development, operation, and maintenance of software; that is, the application of engineering to software. (2) The study of approaches as in (1).）</p>
+
+
+如果你去搜索一下“软件工程定义”，你还能找到很多其他定义，这里就不一一列举。我们没必要花太多时间在这些字面解释上，关键是要抓住这些定义的本质：**就是要用工程化方法去规范软件开发，让项目可以按时完成、成本可控、质量有保证。**
+
+## 软件工程的演化史
+
+对比传统的工程学科，和软件工程最接近的就是建筑工程了。设想一下建一座房子：首先要先立项、设定预算，然后画设计图，再是施工，施工完成后，由专业人士进行质量检查，质检合格后入住。
+
+**开发软件本质上也是像盖房子一样，是从无到有创造的过程。工程化的方式，就是你分步骤（过程），采用科学的方法，借助工具来做产品。**
+
+于是参考建筑工程，整个软件开发过程也被分成了几个阶段：需求定义与分析、设计、实现、测试、交付和维护，这也就是我们常说的软件项目生命周期。
+
+当然，各个阶段都会有人的参与，于是产生了软件项目里的各种角色：项目经理、产品经理、架构师、程序员、测试工程师、运维工程师。而对这整个过程的管理，我们通常称之为“项目管理”。
+
+同时，也很自然就衍生出一套最基础的过程模型：瀑布模型。
+
+<img src="https://static001.geekbang.org/resource/image/88/d4/88e84f12bc09d3d2a0f5c25e22c50ed4.jpg" alt="">
+
+瀑布模型的诞生，在当时是有非常重大的意义的，让软件开发从无序到有序，让大家更好的分工协作，同时每个阶段又衍生出各自的方法学和工具，例如需求分析、软件测试等等。
+
+然而瀑布的特性决定了它只能从上往下流，而且从上到下走完整个周期很长，所以一旦出现了需求的变更，将会非常痛苦，很多事情需要重头再来。
+
+于是基于瀑布模型，又衍生出V模型、原型设计、增量模型、螺旋模型等模型，试图改善瀑布模型存在的一些缺陷。这些改进模型的发展趋势上就是缩短项目周期，快速迭代。
+
+这样到了90年代，各种轻量级开发方法例如Scrum、极限编程等也不断被提出。到了2001年，这些轻量级开发方法一起组成了敏捷联盟，其后敏捷开发如同星星之火，逐渐形成燎原之势。
+
+<img src="https://static001.geekbang.org/resource/image/3b/3f/3b66yy913ee9d30676f9b81145b65a3f.jpg" alt="">
+
+近些年，云计算、微服务这些新技术的产生，也对软件工程产生了影响。云服务让分工更细，很多企业可以将运维、服务器维护、DBA、甚至某些独立服务交给云服务商；微服务让大团队变成小团队，每个小团队可以更专注于细分领域，减少相互之间的依赖。 ​
+
+## 一个公式
+
+当你大致了解整个软件工程的演变发展史，你会发现，软件工程的知识，都是建立在软件项目的过程，或者说软件项目生命周期之上的。
+
+**基于软件过程，我们有了角色分工，有了对过程的管理和工具，对过程中每个阶段细分的方法学和工具。**
+
+现在，如果再回头看看我们的问题“什么是软件工程？”其实可以总结为：软件工程就是用工程化的方法来开发维护软件。也可以说软件工程就是用一定的过程，采用科学的方法，借助工具来开发软件。
+
+如果用一个简单的公式表达，那就是：**软件工程 = 过程 + 方法 + 工具。**
+
+## 总结
+
+今天，我和你一起追溯了一下软件工程的起源，你知道了软件工程学科的产生，就是为了解决软件危机。也见证了整个软件工程的演变历史，从瀑布模型到敏捷开发。
+
+从1968年提出软件工程到现在，正好是50年。在2002年，我最开始学软件工程专业的时候，还只有瀑布模型、需求分析、系统设计等这些传统软件工程内容，但是经过十几年的发展，在软件项目中，敏捷开发、持续集成、微服务等这些新兴内容已经开始在软件项目中占据越来越重要的位置。
+
+可以预见，未来软件工程领域还会有新的概念、新的知识诞生。但是万变不离其宗，只要你抓住软件工程的本质，无论将来如何变化，你总能很快掌握新的知识内容。
+
+**而软件工程的核心，就是围绕软件项目开发，对开发过程的组织，对方法的运用，对工具的使用。**
+
+## 课后思考
+
+当然，每个人对于软件工程的理解也是不同的，你理解的软件工程是什么样子的呢？欢迎在留言区留言讨论。
+
+感谢阅读，如果你觉得这篇文章对你有一些启发，也欢迎把它分享给你的朋友。

极客时间专栏/软件工程之美/基础理论/02 | 工程思维：把每件事都当作一个项目来推进.md

@@ -0,0 +1,112 @@
+<audio id="audio" title="02 | 工程思维：把每件事都当作一个项目来推进" controls="" preload="none"><source id="mp3" src="https://static001.geekbang.org/resource/audio/7c/06/7c175d9ca88bbf50663bdc9d3d89df06.mp3"></audio>
+
+你好，我是宝玉。我今天分享的主题是：掌握工程思维，把每件事都当作一个工程项目来推进。
+
+我大学学的是软件工程专业，毕业十多年后再回顾当年学的专业课，好多专业概念已经记忆模糊，唯有对一位老师的教诲记忆深刻，对我毕业后的职业生涯影响深远：
+
+> 
+软件工程是一门用工程化方法解决软件项目问题的学科，其本质也是一门工程学科，这门课的知识在学完后，不仅可以应用在软件项目中，还可以应用于日常生活中遇到的一些问题，Everything is a project。
+
+
+这句话对我影响很大。我真的开始在日常生活中尝试应用“Everything is a project”的概念，小到做作业，大到完成工作中的复杂项目。
+
+解决这些问题的方式，就是参考软件生命周期和瀑布模型，把一件事情分成几个阶段：**分析、设计、实施、测试、完成**，然后制定相应的计划。这种方法不仅非常有效，让我的做事效率大幅提高，而且让我在看待事情上，能够更全面地、站在更高的角度去思考。
+
+2010年在上海的时候，我机缘巧合参加了一个关于产品设计与用户体验的线下活动，我可能是与会人员中，为数不多的非专业产品设计的同学。
+
+在活动中组织者安排了一个游戏环节，每5个或6个人分成一个小组，来设计一个给老年人使用的手机，限时30分钟。完成后，每组选一个人上台花5分钟展示作品，最后投票选出做得最好的一组。
+
+我的第一反应就是把它当作一个项目，于是快速地拟定了如下计划。
+
+1. 0~10分钟（分析）：头脑风暴，收集想法。
+1. 11~15分钟（设计）：根据头脑风暴结果，确定最终设计。
+1. 16~25分钟（开发）：将想法画在纸上。
+1. 26~30分钟（发布）：完善结果，准备展示。
+
+这个计划小组成员都很认可，于是我们严格按照这个计划进行手机的设计。同时我观察了一下其他组的情况，大家都在热火朝天地讨论各种想法，似乎没有意识到时间其实是有限的。
+
+轮到演示的时候，我们组毫无争议地拿到了第一，因为我们不仅准备充分，而且设计的手机功能完整，而其他很多组甚至还没来得及把想法完整地画下来。
+
+## 什么是工程方法？
+
+后来我才了解到，这种**有目的、有计划、有步骤地解决问题的方法就是工程方法。**工程方法不是软件工程独有的，几乎所有工程类别都可能会应用，例如建筑工程、电子工程等，只不过步骤可能略有不同。
+
+[<img src="https://static001.geekbang.org/resource/image/c4/4e/c45b734291f8a36d4c3d7ed87e384e4e.jpg" alt="" title="图片参考：Engineering Method">](http://sites.tufts.edu/eeseniordesignhandbook/2013/engineering-method/)
+
+工程方法通常会分成六个阶段：想法、概念、计划、设计、开发和发布。
+
+- **想法：**想法阶段通常是想要解决问题。最开始问题通常是模糊的，所以需要清晰地定义好问题，研究其可行性，检查是否有可行的解决方案。
+- **概念：**概念阶段就是用图纸、草图、模型等方式，提出一些概念性的解决方案。这些方案可能有多个，最终会确定一个解决方案。
+- **计划：**计划阶段是关于如何实施的计划，通常会包含人员、任务、任务持续时间、任务的依赖关系，以及完成项目所需要的预算。
+- **设计：**设计阶段就是要针对产品需求，将解决方案进一步细化，设计整体架构和划分功能模块，作为分工合作和开发实施的一个依据和参考。
+- **开发：**开发阶段就是根据设计方案，将解决方案构建实施。开发阶段通常是一个迭代的过程，这个阶段通常会有构建、测试、调试和重新设计的迭代。
+- **发布：**将最终结果包括文档发布。
+
+如果你用这六个或者其中几个阶段对照日常工作和生活中遇到的问题，会发现绝大部分问题都可以看成一个项目，并且拆分成几个阶段，按照计划一步步完成。
+
+## 站在整体而非局部去看问题
+
+可能会有人说：“我不用这种工程方法去做事，一样可以做成呀，并没有什么区别。”确实，做一件事有很多种方式，但用工程方法去处理事情，有两点好处：
+
+1. **有一个被有效论证过的方法论指导你，可以帮助你提高成功概率，也可以提高效率。**
+1. **当你用工程方法去思考的时候，你会更多的站在整体而非局部去思考，更有大局观。**
+
+前面提到的“设计一个老年机”的游戏就是个很好的例子，后来我在不同场合、不同人群中都组织过这个游戏，无论我如何强调时间限制（30分钟）和产出（必须要演示结果），绝大部分人还是会把时间和注意力放在各种稀奇古怪的想法上，并沉浸其中。等到时间快到了，他们才发现还来不及把方案画到纸上，甚至还没确定该选哪个方案。
+
+这种现象其实很常见，我们在日常处理事务时，天然地会选择自己感兴趣的、擅长的那部分，而容易无视整体和其他部分。
+
+**所以问题的核心并不在于是不是用工程方法，而是有没有把这件事当作一个项目，是不是能看到这件事的全貌，而不是只看到局部。**
+
+在工作分工越来越细致的今天，一个项目里面有产品设计、开发、测试、运维等诸多岗位，每个岗位都有自己的价值追求，测试人员关注找出更多Bug、开发人员关注技术和高效开发功能、运维关心系统稳定。
+
+分工带来的好处，就是复杂的任务可以分给不同的人来做，这也有助于技能的专业化，提高工作效率。但如果只站在自己的立场去考虑问题，没有人关注整体价值，就容易相互误解，产生矛盾、增加成本。
+
+以下这些工作场景，估计你不会陌生。
+
+- 产品经理提出一些天马行空、不切实际的需求，而技术上不可行或者实现成本很高，导致最后返工，造成资源浪费和进度延迟；
+- 架构师为了满足开发上的成就感，更愿意自己“造轮子”，而不愿意采用现有开源程序或者购买合适的组件；
+- 开发工程师喜欢在代码中使用各种设计模式或者最新技术，导致项目进度延迟，代码难以维护；
+- 测试工程师不愿意学习自动化测试技术，导致测试周期较长，且容易出现疏漏；
+- 除非产品经理特别注明，开发工程师和测试工程师不会注意用户体验上的细节。
+
+这样的场景问题还有很多，为什么会出现这种情况呢？事实上，这在很大程度上都归因于大家只是站在自己岗位的角度来看问题，没有站在项目的整体角度来看。
+
+如果能站在项目整体来看问题，你就会去关注**项目的质量、项目的进度、项目的成本、项目的最终用户**，那么上面这些场景将变成：
+
+- 为了项目整体的效率和避免返工浪费，产品经理会及早和开发人员确认技术可行性，并对产品设计先行验证；
+- 为了节约项目开发成本，提高开发效率，架构师选择成熟的架构，合理购买商业组件和使用开源程序；
+- 为了提升开发效率，不影响项目开发进度，开发工程师尽可能采用成熟的技术，高效简洁地落实项目；
+- 为了项目质量和效率，测试工程师学习自动化测试技术，将大部分测试变成自动化运行，极大地提高了测试效率和质量；
+- 为了让用户有好的体验，不仅产品经理，每个人都会仔细体验用户界面，对于不合理的地方提出改进意见。
+
+看起来很理想化对不对？但如果大家真能从自己做起，这样的结果并不是太难达到。
+
+肯定有人会想，我又不是项目经理，干嘛要操这心呀？在这个问题上，我的看法是：**每个项目成员，如果能多站在项目的角度去考虑，那么这样不仅对项目有利，更对自己有好处。**
+
+项目做成了，大家脸上都有光，也得到了更多的锻炼；项目没做成，不仅脸上无光，甚至可能面临丢工作的危险。很多人都有技术升管理的理想，能多站在项目整体角度去考虑的人，在日常工作中，也一定会有更多的锻炼机会，自然会多一些提升的空间。
+
+我把这种思维方式称为“工程思维”。如果给一个定义的话，**工程思维，本质上是一种思考问题的方式，在解决日常遇到的问题时，尝试从一个项目的角度去看待问题、尝试用工程方法去解决问题、站在一个整体而不是局部的角度去看问题。**
+
+在我的职业生涯中，一直习惯于用“工程思维”去思考问题，遇到问题，会尽可能把它当成一个项目，用工程方法有计划、有步骤地去解决它，这让我积累了不少的工程方法实践经验。
+
+同时，我也更多站在整体的角度思考，这让我在项目中能更好地和其他同事合作，有更多的晋升机会。我还记得，我第一次开始管项目的时候，并没有慌张，而是把项目任务按阶段一拆分，然后按阶段制定好计划，再按照计划一点点执行、调整，很快就上手了项目管理的工作。
+
+## 总结
+
+**改变，最有效的是方式是改变思想，这往往也是最难的部分。**
+
+当你开始学习这个软件工程专栏，我希望你不仅仅学到软件工程的理论知识，更希望你能用“工程思维”来思考你遇到的各类问题。
+
+**你不需要现在是一个项目经理或者管理者，也一样可以在日常生活中应用“工程思维”。**比如学习这个专栏，你会制定一个什么样的计划？每个阶段达到一个什么样的成果？比如你今年有没有去旅行的计划？你会怎么制定你的旅行计划？
+
+如果有兴趣的话，你还可以看看我以前写过的一篇文章“[记录下两个孩子在MineCraft里面还原公寓的经历](http://zhuanlan.zhihu.com/p/21314651)”。
+
+这也是一个很有意思的工程思维实践，帮助孩子们在游戏里面还原公寓。这本质上也是一个项目，需要制定计划，需要设计、实现。我希望他们从小就有工程思维，能在未来有目的、有计划、有步骤地去解决日常生活的问题。
+
+## 课后思考
+
+最后，我希望你思考一下，你在日常生活中，会不会习惯上把一些事情看作项目？或者你看完这篇文章后，有没有觉得有一些事情可以看作项目？你会怎么应用工程方法来实践？
+
+此外，在你参与的项目里面，你会站在项目整体的角度来考虑一些问题吗？你觉得如果站在项目整体的角度看，是不是可以对你的工作方式有所调整？欢迎你在留言区分享讨论。
+
+感谢阅读，如果你觉得这篇文章对你有一些启发，欢迎把它分享给你的朋友。

极客时间专栏/软件工程之美/基础理论/03 | 瀑布模型：像工厂流水线一样把软件开发分层化.md

@@ -0,0 +1,220 @@
+<audio id="audio" title="03 | 瀑布模型：像工厂流水线一样把软件开发分层化" controls="" preload="none"><source id="mp3" src="https://static001.geekbang.org/resource/audio/02/09/0296303bf71da28cb1f1fd895a22fd09.mp3"></audio>
+
+你好，我是宝玉，我今天分享的主题是：瀑布模型，像工厂流水线一样把软件开发分层化。
+
+可以这么说：**瀑布模型算是现代软件工程的起源，软件工程的发展，很大部分都是构建于瀑布模型的基础之上的。**我们后面所学的软件工程的很多内容，都是源自瀑布模型的衍生，或者其中某个阶段的细分。
+
+我在上大学期间，还并不懂软件工程瀑布模型这些知识。当时我自学了点编程知识，然后开始在外面接点做网站的小活，开发模式非常简单，接到活直接写代码，有问题就改。这样下来居然也做了不少小网站，但是大一点的网站项目就搞不定了，甚至手头的小网站项目，找个同学帮忙都不知道大家该怎么分工。
+
+所以当时我也很好奇，大的软件系统是如何开发出来的？那么多人一起开发一个软件，系统是如何分工协作的？
+
+后来到大三的时候，开始系统学习软件工程课程，我才开始了解到一些理论知识，包括我做小网站的这种开发模式，都有一个专业术语，叫边写边改（Code And Fix）模型。
+
+这不是我的发明。在1960年初，软件开发刚开始起步，这时的软件开发是混沌无序的，那时候编程语言还是汇编语言为主，开发模式就是边写边改模型。如果程序员水平高，功能简单，还是可行的。
+
+后来软件开发需求越来越多，功能越来越复杂，从事软件开发的人员水平也参差不齐，这种落后的软件生产方式已经无法满足迅速增长的计算机软件需求，从而导致软件开发与维护过程中出现一系列严重问题，这个现象也被称之为“软件危机”。
+
+像这种边写边改的开发模式，为什么说不能满足复杂软件项目的需要呢？主要是有几方面的原因：
+
+- 整个开发过程不可控，想基于这种开发模式做项目计划太难；
+- 项目的人数多了后，无法有效分工协作；
+- 项目开始的时候对需求几乎没有进行有效分析，对需求的理解容易出现偏差，后期导致很多返工；
+- 项目编码完成后，没有有效测试，运行时Bug非常多。
+
+## 瀑布模型的诞生
+
+为了解决软件危机中的这些问题，在1970年，Winston Royce博士借鉴了其他工程领域的思想，比如建筑工程，提出了瀑布开发模型，指出软件开发应有完整之周期，并将软件开发过程分成了若干阶段。像瀑布一样，从上往下，完成一个阶段继续下一个阶段。
+
+<img src="https://static001.geekbang.org/resource/image/04/0f/043ec1b87258d3b414b4fa2c5572f20f.jpg" alt=""><br>
+瀑布模型把整个项目过程分成了六个主要阶段：
+
+一、问题的定义及规划<br>
+这个阶段是需求方和开发方共同确定软件开发目标，同时还要做可行性研究，以确定项目可行。这个阶段会产生需求文档和可行性研究报告。
+
+二、需求分析<br>
+对需求方提出的所有需求，进行详细的分析。这个阶段一般需要和客户反复确认，以保证能充分理解客户需求。最终会形成需求分析文档。
+
+三、软件设计<br>
+根据需求分析的结果，对整个软件系统进行抽象和设计，如系统框架设计，数据库设计等等。最后会形成架构设计文档。
+
+四、程序编码<br>
+将架构设计和界面设计的结果转换成计算机能运行的程序代码。
+
+五、软件测试<br>
+在编码完成后，对可运行的结果对照需求分析文档进行严密的测试。如果测试发现问题，需要修复。最终测试完成后，形成测试报告。
+
+六、运行维护<br>
+软件开发完成，正式运行投入使用。后续需要继续维护，修复错误和增加功能。交付时需要提供使用说明文档。
+
+瀑布模型在提出后，因为其简单可行，切实有效，马上就在很多软件项目中应用起来，一直到2000年前后，都是最主流的软件开发模型，即使到现在，你也能在很多软件项目中看到它的影子。
+
+**也是从那时开始，有了“软件生命周期”(Software Life Cycle,SLC)的概念。 **
+
+> 
+软件生命周期是软件的产生直到报废或停止使用的生命周期。而像瀑布模型这样，通过把整个软件生命周期划分为若干阶段来管理软件开发过程的方法，叫软件生命周期模型。
+
+
+虽然现在瀑布模型已经不是最主流的开发模式，那为什么我们现在还要学习瀑布模型呢？
+
+**因为不管什么软件项目，不管采用什么开发模式，有四种活动是必不可少的，那就是需求、设计、编码和测试。而这四项活动，都是起源自瀑布模型，也是瀑布模型中核心的部分。**
+
+学好瀑布模型，才可以帮助你更好的理解这些内容。
+
+## 如何用瀑布模型开发项目？
+
+如果单纯看这些阶段的概念介绍，还是有点难以直观地理解整个软件开发过程，在这里拿我经历过的一个网站开发项目作为案例，来看一下如何使用瀑布模型来开发一个软件项目。
+
+- **问题的定义及规划的阶段**
+
+大概在2009年的时候，Web2.0还正火，公司老板打算做一个游戏领域的社交网站。
+
+问题很明确，就是要做一个社交网站，并且用户能按照游戏来交友。至于可行性分析嘛，按照当时Web2.0的热度，这个似乎是可行的。那么就立项了。
+
+然后老板问项目经理，这么样一个网站，你大概得多久做出来？项目经理一看，这么复杂一个网站，怎么也得半年才能做出来一个版本，于是说半年。老板说半年太久了，给你三个月吧，项目经理心中叫苦，最后讨价还价，决定四个月上线。
+
+于是，项目经理按照四个月开始倒推项目计划：
+
+> 
+<p>需求分析——2周；<br>
+软件设计——4周；<br>
+程序编码——6周；<br>
+软件测试——4周。</p>
+
+
+- **需求分析的阶段**
+
+在项目立项后，产品经理首先和老板充分的沟通，了解老板的想法是什么，要做一个什么样的网站。在了解老板的想法后，产品经理对市场上同类的社交网站进行了调研，然后用原型工具设计了网站的原型。原型虽然很简陋，但是从原型可以看出来，项目要做成什么样子，便于确认需求。
+
+原型拿给老板看后，老板再根据自己的想法提一些反馈，这样反复沟通确认，在原型设计确认清楚后，产品经理开始撰写产品设计文档，将原型设计落实到文档，将整个网站划分成不同的功能模块，例如用户注册、登录、添加好友等，确定每个功能模块需要哪些功能。
+
+这个阶段产品经理是最忙的，那这时候其他人在干嘛呢？其他人都还挺轻松的，架构师研究网上流行的社交网站都采用什么架构，程序员、测试看看技术文档。
+
+虽然最终确定了产品设计文档，但是因为中间反复确认的时间过长，原定2周能完成的需求分析，最后拖到了3周。项目经理一看，最终上线时间点没办法延后，那就只好压缩编码时间了，不行加加班！
+
+项目计划变成了：
+
+> 
+<p>需求分析——3周；<br>
+软件设计——4周；<br>
+程序编码——5周；<br>
+软件测试——4周；</p>
+
+
+- **软件设计**
+
+产品经理的产品设计文档确定后，架构师开始做架构设计，UI设计师开始设计UI，测试经理开始针对产品设计文档写测试用例，产品经理还要进一步设计交互。
+
+由于前期原型设计工作做的好，所以UI设计还是很顺利的，主风格定下来以后，各个界面就是细节的确认了。
+
+因为产品设计文档写的详细，输入输出很清楚，测试用例也进展顺利。
+
+至于架构设计这边，架构师很有经验，先把整体架构确定，写了个技术方案文档，和大家一起开会讨论，几次后确认了整体技术方案。按照功能模块一拆分，把其中一个功能模块做了一个样板，然后把各个子模块分给开发人员，大家一起协助做详细设计，然后再分别确认。
+
+大家都如火如荼地忙起来了。如果一切顺利的话，软件设计4周应该能完成，可以进入编码阶段了。但是软件设计进行到第3周的时候，老板的想法发生了一些变化。
+
+因为市场上已经有了游戏社交的网站，而且运营结果不算太好，而网页游戏正流行，如果我们的平台能接入网页游戏，这会是个不错的机会。
+
+于是需求变更了，我们要能和其他网页游戏的用户系统对接，这个需求最开始是没有提出来，也没有考虑的。
+
+项目经理考虑再三，决定还是接受这个需求变更，但是希望能多一些时间，老板没同意，认为时间点很重要，哪怕砍一点功能，牺牲一点质量也要如期上线。但就算这时候砍功能，设计工作还是少不了多少。
+
+于是产品经理重新修改相应原型，再确认，再重新修改产品设计文档。变更完后，UI设计的相关页面重新修改设计、测试人员修改测试用例，最苦的是架构师，当初没有考虑到要和其他用户系统对接，现在用户系统的设计都要重新考虑了。
+
+于是为了赶进度，项目组开始加班，即使如此，软件设计阶段也推迟到了第5周才勉强完成。
+
+项目计划又变了：
+
+> 
+<p>需求分析——3周；<br>
+软件设计——5周；<br>
+程序编码——5周；<br>
+软件测试——3周。</p>
+
+
+- **程序编码**
+
+终于进入编码阶段了，为了保证进度，加班还在继续，哪怕前期做了大量的设计，真到编码的时候还是有好多没有考虑到的，同时各个模块之间还存在相互依赖，有时候虽然自己功能开发完成，还需要等待其他人的功能完成才能调试，所以5周时间很快就过去了，而程序还不能完整地跑起来。
+
+其实中间还有个小插曲，老板觉得还要加上支付的功能，但是项目经理觉得这个阶段改需求已经不可能了，以辞职为威胁总算顶回去了，打算放在下个版本加上。
+
+终于到第6周的时候，有了一个勉强可以测试的版本。
+
+项目计划现在变成了：
+
+> 
+<p>需求分析——3周<br>
+软件设计——5周<br>
+程序编码——6周<br>
+软件测试——2周</p>
+
+
+- **软件测试**
+
+留给测试的时间只有两周了，但是前期实在bug太多，两周测试时间过去，软件质量还是很糟糕，完全无法正常使用，于是项目不得不延期，一直延期了4周后，才算具备上线条件。
+
+所以最终的项目计划差不多是：
+
+> 
+<p>需求分析——3周<br>
+软件设计——5周<br>
+程序编码——6周<br>
+软件测试——6周<br>
+和原定计划已经延迟了4周。</p>
+
+
+- **运行维护**
+
+网站上线后，好在前期并没有多少用户，但是线上Bug还是不少，需要继续修复线上发现的Bug。
+
+## 瀑布模型的优缺点
+
+以上案例是我参与过的、用瀑布模型开发的软件项目的一个缩影，你会发现瀑布模型其实跟我们传统的建筑建造方式非常类似。我们拿盖房子的过程来看看瀑布模型。
+
+- 客户想要盖一栋房子（**初步的想法**）。
+- 客户一开始可能没想清楚想要什么样子的房子。（**客户对需求还不清楚**）
+- 施工方开始找客户确认：用途是什么，要个几层的房子，什么建筑风格，希望什么时间完工，预算多少。（**问题定义**）
+- 施工方根据客户提的需求，对比工期和预算，评估是不是值得做。（**可行性研究**）
+- 施工方评估后觉得可行，于是和客户签订合同，约定价钱和工期。（**立项，制定项目计划**）
+- 施工方开始跟客户沟通确认需求，例如每层户型如何，将来的装修风格等。（**需求分析**）
+- 确认完需求后，施工方开始出建筑施工图，还画了漂亮的建筑效果图。（**系统设计和UI设计**）
+- 施工方按照设计图开始施工。（**程序编码**）
+- 这期间如果客户去参观施工情况，客户只能看到毛胚，只有最后施工完成才能看到最终样子。（**在中间客户看不到结果，只有最后能看到结果**）
+- 原定二层是两个卧室，在房子施工过程中，突然客户说两个卧室不够，要改成三个卧室。这意味着施工方要对施工图重新设计，很多已经建好的房间要拆掉重建。（**瀑布模型是很难响应需求变更的，而且越到后期代价越大**）
+- 工程质量检查人员对施工结果进行质量检测，如果不满足质量要求，需要修改。（**测试**）
+- 最后验收通过后，客户入住。（**上线**）
+
+所以你看，用瀑布模型开发软件，就像建筑工程里，盖房子一样简单和自然。每个阶段都有侧重的事情，就像需求阶段专注于搞清楚需求，编码阶段专注于实现。
+
+最重要的是，这种编码前先设计、编码后测试、整个过程重视文档的方式，开发出来的产品，质量相对是有保障的。
+
+但用瀑布模式开发，也存在一些问题。
+
+**最大的问题就是不能及时响应需求变更，越到后期变更代价越大。**另外，通常要到最后阶段才能看到结果是什么样子。
+
+我以前参与过的用瀑布模型方式开发的项目中，在开发和测试阶段加班是常态，原因就在于需求分析和系统设计可能会有延误，从而延迟了编码阶段的开始时间，压缩了编码实现的时间。
+
+而在编码阶段，通常会发现很多设计时没有考虑清楚的问题，或者遇到需求变更，导致编码阶段即使加班加点也会大大延期，最后留给测试阶段的时间就不够多了。
+
+鉴于瀑布模型存在的这些问题，后来又有很多人提出了其他的软件生命周期模型，比如快速原型开发模型、增量模型、迭代模型，以期保留瀑布模型的这些优点，克服瀑布模型中存在的问题。我们将会在后面的章节中，详细介绍瀑布模型衍生出的其他开发模型。
+
+<img src="https://static001.geekbang.org/resource/image/88/5c/881b21fa452df38da1604f5a6b55d65c.jpg" alt="">
+
+## 总结
+
+从瀑布模型提出至今，将近50年过去了，虽然现在大家一提起瀑布模型，似乎已经成了落后的代名词，但在当时是有划时代意义的。如果类比一下，我觉得瀑布模型的价值相当于工业界第一次提出流水线作业。
+
+> 
+1769年，英国人乔赛亚·韦奇伍德开办埃特鲁利亚陶瓷工厂。以前制作陶瓷只有“制陶工”一个工种，一个人从挖泥、制胚到最后烧制，要求很高。但是乔赛亚把原本的制陶流程从开始到结束分成了若干阶段，每个阶段可以由不同的人完成，从单一的制陶工分成了挖泥工、运泥工、拌土工、制坯工等，这样就大大提高了生产效率，也降低对工人的要求。
+
+
+同理，瀑布模型的出现，也解决了软件项目开发中的几个重要问题。
+
+- **让软件开发过程有序可控。**瀑布模型的每个阶段都有明确的任务，每个阶段都有明确的交付产物，都有相应的里程碑。这些让整个过程更可控，而且能及早发现问题。
+- **让分工协作变成可能。**瀑布模型的六个阶段，也让软件开发产生相应的基础分工：项目经理、产品经理、架构师、软件工程师、测试工程师、运维工程师。
+- **质量有保障。**瀑布模型每个阶段都需要交付相应的文档，而文档的撰写和评审，可以帮助在动手之前把问题沟通清楚，想清楚。瀑布模型在编码结束后，会有严密的测试，只有测试验收通过后，才能上线发布。这些措施都让软件的质量更有保障。
+
+## 课后思考
+
+通过今天的学习，你可以对照一下，你工作中的软件项目开发是不是采用的瀑布模型？和瀑布模型有哪些不同？你认为瀑布模型有哪些好或不好的地方？欢迎你在留言区留言，和我分享讨论。
+
+感谢阅读，如果你觉得这篇文章对你有一些启发，也欢迎把它分享给你的朋友。

极客时间专栏/软件工程之美/基础理论/04 | 瀑布模型之外，还有哪些开发模型？.md

@@ -0,0 +1,191 @@
+<audio id="audio" title="04 | 瀑布模型之外，还有哪些开发模型？" controls="" preload="none"><source id="mp3" src="https://static001.geekbang.org/resource/audio/75/41/754ed75fe63c1313c869a0f66cc00c41.mp3"></audio>
+
+你好，我是宝玉，我今天分享的主题是：瀑布模型的衍生模型都有哪些，你该如何选择？
+
+在上一篇文章中，我重点介绍了瀑布模型。你现在知道了，瀑布模型简单易行，对于软件质量是有比较高保障的。但是瀑布模型对于前期需求不明确的项目，很难开展需求分析，后续如果有需求变更，瀑布模型便很难响应。
+
+而且，每个软件项目的情况各不相同，都有自己的特点。比如说：
+
+- 有的项目风险很高，客户可能随时不给你钱了，得要做好准备，随时止损；
+- 有的项目客户自己没想清楚要想的是什么，做出来后再提各种修改意见，必须得想办法降低变更成本；
+- 有的项目客户希望能很快就能上线。
+
+如果选用瀑布模型做这些项目，就会导致成本过高或者周期过长等问题出现。所以，并不是所有的项目都适合使用瀑布开发模型，你需要针对不同的情况做一些调整。
+
+实际上，为了应对瀑布模型的不足，已经衍生出了很多其他的开发模型。今天，我将为你分享一些有代表性的瀑布模型的衍生模型，你可以了解到这些衍生模型的本质，在接手不同类型的项目时，可以灵活地进行选择。
+
+## 快速开发快速改
+
+- **快速原型模型**
+
+我刚毕业时参加了一个项目的开发，项目经理跟我说，这个项目怎么快就怎么写，不要在意代码质量、架构、性能这些，当时我表示很不能理解，哪有这样做项目的？
+
+我还偷摸着花了很多时间想把代码写好，结果发现，这个快速做好的简单版本，主要目的就是为了给客户演示，跟客户确认需求，然后把客户的反馈记录下来，再去优化。这样几个小版本下来，基本上就把需求确定了，而我当时写的好多代码根本就用不上。
+
+后来我才知道，这就是快速原型模型。
+
+**快速原型模型，就是为了要解决客户的需求不明确和需求多变的问题。**
+
+先迅速建造一个可以运行的软件原型，然后收集用户反馈，再反复修改确认，使开发出的软件能真正反映用户需求，这种开发模型就叫快速原型模型，也叫原型模型。
+
+这就好比客户想要盖房子，但是他没想好要盖成什么样子，于是施工方就先搭了一栋彩钢房（就像工地里面搭的临时房子），让客户先用起来，然后再给反馈调整。
+
+因为彩钢房搭建简单快速，改起来也相对容易。等到客户确定好需求，再在已经搭好的彩钢房的基础上完善，或者直接重新按照确定好的需求造房子。
+
+不过，这样做也有一个问题，用彩钢房这种方式盖房子虽然快，但是房子质量不会太好，住的不算舒服，想有点个性化的风格也难。
+
+同样的道理，也适用于软件项目。彩钢房就像是软件原型，重点是反映软件核心功能和交互，功能可以是不完整的，可靠性和性能要求不高，但开发速度可以很快。
+
+**原型模型因为能快速修改，所以能快速对用户的反馈和变更作出响应，同时原型模型注重和客户的沟通，所以最终开发出来的软件能够真正反映用户的需求。**
+
+**但这种快速原型开发往往是以牺牲质量为代价的。**
+
+在原型开发过程中，没有经过严谨的系统设计和规划，可靠性和性能都难以保障。所以在实际的软件项目中，针对原型模型的这种快速、低质量的特点，通常有两种处理策略：**抛弃策略和附加策略。**
+
+抛弃策略是将原型只应用于需求分析阶段，在确认完需求后，原型会被抛弃，实际开发时，将重新开发所有功能。类似于用彩钢房盖房子，确认完客户需求后，拆掉重新建。
+
+附加策略则是将原型应用于整个开发过程，原型一直在完善，不断增加新功能新需求，直到满足客户所有需求，最终将原型变成交付客户的软件。类似于用彩钢房盖房子，最后还要做一番精装修，交付客户。
+
+采用哪种策略来应用原型模型，还是要看项目特点，包括所采用原型开发工具和技术的成熟度。举例来说，如果客户对可靠性、性能要求高，那么就最好是抛弃策略，如果客户对质量要求不高，有简单功能就够了，那么可以试试附加策略。
+
+快速原型模型即使到现在还一直有在用，用于低成本快速的确认需求。如果你将来遇到这种项目，就没必要花太长时间在代码质量上，赶紧做出来才是王道。
+
+另外，原型制作并不一定要像传统代码一样进行设计编码，有很多原型工具，像Axure、墨刀等，简单的拖拽就可以实现简单的界面和交互，同样可以达到确认需求的目的。现在原型设计已经成为产品经理确认需求的一个非常重要手段。
+
+## 大瀑布拆小瀑布
+
+**瀑布模型的很多问题，根源都是周期太长。**周期长所以中间难以响应变更，周期长所以客户很久才能看到结果，周期太长所以风险不好控制。如果能将周期变短，那么很多问题就迎刃而解了。
+
+基于这种思路，产生了很多开发模型，比较典型的主要是：**增量模型** 和 **迭代模型。**
+
+- **增量模型——按模块分批次交付**
+
+增量模型是把待开发的软件系统模块化，然后在每个小模块的开发过程中，应用一个小瀑布模型，对这个模块进行需求分析、设计、编码和测试。相对瀑布模型而言，增量模型周期更短，不需要一次性把整个软件产品交付给客户，而是分批次交付。
+
+**如果拿盖房子来比喻的话，就是先盖卫生间，然后盖厨房，再是卧室。**
+
+盖卫生间的时候，也要先分析需求，然后设计，再实施，最后验收。有时候也可以多模块并行，例如同时盖卫生间和厨房，前提是模块之间不能有依赖关系，比如，你不可能先盖二楼再盖一楼。
+
+你会发现，增量模型将整个系统进行模块化处理，所以你可以分批次交付软件产品，使用户及时了解软件项目进展。如果一个模块有问题，或者需要做需求变更，对整体影响也有限。在开发的时候，也可以灵活地按照模块来分工，多个模块并行开发提升效率。
+
+<img src="https://static001.geekbang.org/resource/image/20/9b/20d7896e4a52e8043defff6eedb9869b.jpg" alt="">
+
+因为增量模型的根基是模块化，所以，**如果系统不能模块化，那么将很难采用增量模型的模式来开发。**另外，对模块的划分很抽象，这本身对于系统架构的水平是要求很高的。
+
+基于这样的特点，增量模型主要适用于：**需求比较清楚，能模块化的软件系统，并且可以按模块分批次交付。**
+
+- **迭代模型——每次迭代都有一个可用的版本**
+
+迭代模型每次只设计和实现产品的一部分，然后逐步完成更多功能。每次设计和实现一个阶段叫做一个迭代。
+
+我们还是继续拿盖房子来举例：如果用迭代模型的方式盖房子，第一个迭代要先盖一个茅草屋，快速满足客户对房子的核心需求；第二个迭代再盖一个小木屋，比茅草房更大更舒适；第三个迭代再盖成一个豪华别墅，满足客户所有需求。
+
+你要注意，无论是造小木屋还是大别墅，整个过程都会像一个完整的项目一样，包括需求分析、设计、实现与测试验收。
+
+<img src="https://static001.geekbang.org/resource/image/97/70/97a05f1bba8344f5d9e8b8734a025e70.png" alt="">
+
+在迭代模型中，整个项目被拆分成一系列小的迭代。通常一个迭代的时间都是固定的，不会太长，例如2～4周。每次迭代只实现一部分功能，做能在这个周期内完成的功能。
+
+在一个迭代中都会包括需求分析、设计、实现和测试，类似于一个小瀑布模型。**迭代结束时要完成一个可以运行的交付版本。**
+
+<img src="https://static001.geekbang.org/resource/image/9a/10/9abe6230baeb7a92a95b65dd7c383d10.jpg" alt="">
+
+迭代模型和增量模型很容易混淆，因为都是把大瀑布拆成小瀑布。这两种模型的主要差别在于如何拆分项目功能上。
+
+**增量模型是按照功能模块来拆分；而迭代模型则是按照时间来拆分，看单位时间内能完成多少功能。**
+
+还是用盖房子来理解，增量模型则是先盖厨房，再是卧室，这样一个个模块来完成。而迭代模型则是先盖一个简单的茅草房，有简易的土灶和土床，然后再升级成小木屋，有更好的灶和更好的卧室，这样一步步迭代成最终的房子。
+
+我原来参与过的瀑布模型开发的项目，因为要很长时间才能看到最终结果，而且结果通常跟最初描述的结果相差较多，客户看到后多少会有些心理落差。
+
+而后来改用迭代模型后，因为每次迭代完成后都有可以运行的版本，这样客户可以直观感受软件的进展，及时调整心理预期。尤其是当客户见证了一个软件从简陋到完善的过程，往往满意度是比较高的。
+
+**迭代模型最难的部分，在于规划每次迭代的内容和要达到的目标。**多了可能完不成，少了可能造成每次迭代工作量不饱和，这需要在实践中去摸索，一个迭代一个迭代的去调整。
+
+迭代模型由于在初始迭代时，只清楚当前迭代的需求，而不知道后续需求，设计可能会考虑不周全。这样的话，迭代一多，系统会有不少冗余，一段时间后就需要对系统进行重构。
+
+另外每次迭代，用户可能会增加新的需求和对现有需求进行更改，因此开发时间上可能会比预期要长。如果你做的是小项目的话，并不建议使用迭代模型来开发。
+
+## 我该选择什么过程模型？
+
+除了上面提到的这几种模型，还有很多其他开发模型，要记住所有的开发模型很难。你搞透了瀑布模型，搞清楚了其阶段划分，结合一些应用场景，你就可以举一反三，了解绝大部分衍生模型。
+
+我在这里给你列举几个常见的项目场景，我们可以一起来分析下，看看用什么模型适合。
+
+**场景一：外包项目，需要阶段验收**
+
+假如你现在是一家外包公司，你可以采用瀑布模型开发，但是甲方需要对你项目的每个阶段进行验收测试，以确认你是不是达到要求。
+
+针对从需求定义一直到编码阶段，每个阶段都有对应的测试验收。如果画成图，就是下面这个样子的。
+
+<img src="https://static001.geekbang.org/resource/image/c0/b1/c015252d6ae984b667499ee5b8c76ab1.jpg" alt="">
+
+这个模型就是V模型，本质上它还是瀑布模型，只不过它是更重视对每个阶段验收测试的过程模型。
+
+**场景二：项目风险高，随时可能会中断**
+
+如果你现在要做一个风险很高的项目，客户可能随时不给你钱了。这种情况下，如果采用传统瀑布模型，无疑风险很高，可能做完的时候才发现客户给不了钱，损失就很大了！
+
+这种情况，基于增量模型或者迭代模型进行开发，就可以有效降低风险。你需要注意的是，在每次交付的时候，要同时做一个风险评估，如果风险过大就不继续后续开发了，及时止损。
+
+[<img src="https://static001.geekbang.org/resource/image/5c/cc/5c1f2444754f3ce5ce68e0a790da2bcc.png" alt="" title="图片来源：WikiPedia">](http://zh.wikipedia.org/wiki/%E8%9E%BA%E6%97%8B%E6%A8%A1%E5%9E%8B)
+
+这种强调风险，以风险驱动的方式完善项目的开发模型就是螺旋模型。
+
+**场景三：山寨一款软件产品，希望能快速上线发布**
+
+其实软件行业山寨的案例不少，山寨项目的特点是，项目需求是明确的，不会有什么变化，这时候就可以选择增量模型，划分好模块，先实现核心模块，发布可运行版本，再增量发布其他模块。多模块可以同步开发。
+
+**场景四：客户都没想清楚想要什么，但是个大单子**
+
+很多项目，客户一开始都没想清楚想要的是什么，需要花很长时间去分析定义需求，但是单子很大，值得认真去做好。
+
+那么这样的项目，你可以考虑拆分成四个阶段：
+
+1.初始阶段
+
+主要是确定需求边界和主要风险，几乎没有什么开发工作。
+
+2.细化阶段
+
+这个阶段主要是确定需求，可以采用快速原型模型开发，和客户对需求反复确认，需要辅助一定量的开发和测试工作。对代码质量可以要求比较低，重点是确认需求。可能需要一个或多个版本迭代。
+
+3.构造阶段
+
+在需求确认清楚后，现在可以使用迭代模型来开发，逐步交付产品。这个阶段的重点是开发和测试。如果迭代中，有新的需求加入或者需求变更，也可以在新的迭代中加入。
+
+4.交付阶段
+
+在开发和测试完成后，产品可以交付客户，根据线上运行情况还需要修复一些Bug。这个阶段重点是测试和部署。也会有多个迭代。
+
+整个过程看起来就像下图这样。
+
+<img src="https://static001.geekbang.org/resource/image/b0/fc/b0091341a7fa31cd26d8a02e7d63e2fc.png" alt="" title="图片来源：《构建之法》">
+
+上面这种开发方式来源自统一软件开发过程（Rational Unified Process，RUP），适用于复杂和需求不明确的软件系统。
+
+**场景五：我的产品已经上线，但是需要持续更新维护**
+
+很多产品在上线后，还在保持不停的更新维护，修复Bug、增加新功能，每个月甚至每周更新。
+
+在这种情况下，迭代模型是比较合适的。固定时间周期，在固定的周期内选择适合的需求开发任务和Bug修复任务去完成，按时发布。
+
+另外还可以尝试敏捷开发，也是基于迭代的开发模型，它也强调快速交付，每次交付系统的部分功能，来保证客户满意度。在敏捷开发中，系统交付的周期称之为冲刺（Sprint）。
+
+严格来说，敏捷开发并不算是一种开发模型，更像是框架或指南。有各种开发模型来实现敏捷开发，比如说极限编程（Extreme programming），看板（Kanban）和Scrum。有关敏捷开发，我将在下一篇中向你详细讲解。
+
+## 总结
+
+现在的软件项目，各种类型都有，根据项目特点，选择好合适的开发模型，可以让你事半功倍，降低项目风险，提高项目开发效率，控制项目成本。比如说：
+
+- 一个以确认需求为主要目的的项目，就可以不用花太多时间在代码质量上面，低成本、高效做出来才是最重要的；
+- 一个高风险的项目，则可以采用螺旋模型，出现问题及时止损；
+- 一个很长时间加班加点，却一直没法上线，导致士气低落的项目，可以改成增量模型，先上线一个小模块，让大家看到成绩提升士气，然后再迭代，逐步上线其他模块。
+
+同时，你也不必拘泥于这几种开发模型，还可以借鉴其他模型做的好的地方，甚至创造自己的开发模型，比如说你觉得敏捷的“站立会议”适合你的项目，那也可以借鉴过来。
+
+## 课后思考
+
+如果一个项目，需求不明确，后期可能会有比较大的变化，你觉得应该采用哪种开发模式或者哪几种开发模式组合比较好？你现在所参与的项目开发中，是采用的什么开发模式？欢迎在留言区与我分享讨论。
+
+感谢阅读，如果你觉得这篇文章对你有一些启发，也欢迎把它分享给你的朋友。

极客时间专栏/软件工程之美/基础理论/05 | 敏捷开发到底是想解决什么问题？.md

@@ -0,0 +1,220 @@
+<audio id="audio" title="05 | 敏捷开发到底是想解决什么问题？" controls="" preload="none"><source id="mp3" src="https://static001.geekbang.org/resource/audio/17/da/17e7d58ae38fb557794a8ad1dee309da.mp3"></audio>
+
+你好，我是宝玉，我今天想跟你聊聊“敏捷开发”。
+
+关于敏捷开发的实际应用，现在无外乎有以下几种常见的情形：
+
+- 很多团队想敏捷开发，但不知道该怎么上手；
+- 有的团队已经应用了一些敏捷开发的实践，然而效果不理想，不知道是敏捷开发的问题，还是自己实践方式不得当；
+- 有的团队听说了敏捷开发，但是并不知道它是什么。
+
+为什么会这样呢？今天我们就围绕敏捷开发来谈一谈，看看敏捷开发是什么，能帮助我们解决哪些问题，要不要实施敏捷开发，以及怎么能应用好敏捷开发。
+
+## 什么是敏捷开发？
+
+那什么是敏捷开发呢？有人认为：
+
+- 敏捷开发就是Scrum、极限编程；
+- 敏捷开发就是每天站立会议、每两周一个Sprint（字面意思是冲刺，可以理解为迭代）；
+- 敏捷开发就是把需求变成故事，把故事写在便签上贴到白板，然后根据状态移动到不同的列；
+- 敏捷开发就是用看板软件来管理项目。
+
+然而，这些是敏捷开发的真正含义吗？
+
+要理解敏捷开发，我们先要了解其诞生背景。在2001年那会，瀑布模型还是主流，我们知道，瀑布模型是一种“重型”的开发模式，整个流程走完通常周期很长，少则数月，多则数年。长周期导致风险增加、难以响应变化。
+
+于是由瀑布模型衍生出很多模型，试图去改善瀑布模型存在的问题，我已经在上一篇文章中给你介绍了一些。不过除了介绍的那些以外，在当时还有一些不怎么有名，而现在却如雷贯耳的轻量级开发方法，例如极限编程（Extreme Programming，XP）、Scrum等。
+
+2001年初，17位代表上述各种轻量级软件开发过程流派的领军人物聚集在一起，讨论替代瀑布模型这种重量级软件开发过程的新方法。
+
+但是没能达成一致，所以退而求其次，把大家都认同的理念整理出来，也就是后来的敏捷宣言。这些人还一起成立了敏捷联盟。
+
+[<img src="https://static001.geekbang.org/resource/image/d5/ea/d5f757c6b60a51dfe3dab3bde8a736ea.png" alt="" title="图片来源：敏捷开发宣言">](http://agilemanifesto.org/iso/zhchs/manifesto.html)
+
+我们再回头来看前面大家对敏捷的定义，其实都是在从方法论、工具等方面解释敏捷开发。而敏捷宣言指出：
+
+> 
+敏捷不是一种方法论，也不是一种软件开发的具体方法，更不是一个框架或过程，而是一套价值观和原则。
+
+
+现实中关于敏捷的讨论，更多的是在讨论各种方法论和工具。不可否认，这些方法论和工具，能帮助团队“敏捷”起来，但它们和敏捷开发之间的关系，更像是“术”和“道”的关系。
+
+> 
+各种敏捷框架、方法论和工具，就像是“术”，告诉你敏捷开发的方式，而敏捷则是“道”，是一套价值观和原则，指导你在软件项目开发中做决策。
+
+
+这么说还是比较抽象，我给你举个例子。
+
+敏捷开发中流行的站立会议，主要目的是为了保证团队成员充分的沟通，遇到困难可以及时寻求帮助。但是如果每天的站立会议流于形式，并不能起到有效的目的，则应该减少频度，甚至取消换成其他方式。
+
+要不要在你的项目开发中使用站立会议，判断的依据就在于这样做是不是符合敏捷的价值观和原则。
+
+**也就是说，当你开发做决策的时候，遵守了敏捷开发的价值观和原则，不管你是不是用Scrum或者极限编程，那么都可以算是敏捷开发。**
+
+## 敏捷开发想解决什么问题？
+
+如果你仔细读了敏捷宣言，你会发现，宣言中右边的内容其实都是瀑布模型核心的内容：流程和工具、详尽的文档、合同谈判、遵循计划。
+
+虽然敏捷开发并未对瀑布模型的价值进行否定，但也表明了瀑布模型做的还不够好，同时提出了一套自己的价值观。
+
+比如说，我们开始做一个新项目，需要从客户那里收集整理需求，如果按照传统的软件开发模式，我们需要在开发前获得所有需求，然后和客户签订合同，在发布前都不会轻易修改需求。
+
+但是如果我们采用敏捷开发模式来开发项目，那这样做显然违背敏捷的价值观：“客户合作高于合同谈判”。
+
+所以如果是敏捷开发，在每个迭代后，都应该向客户收集反馈，然后在后面的迭代中，酌情加入客户反馈修改的内容。
+
+结合敏捷开发提出的背景，你其实不难发现，敏捷开发就是想解决瀑布模型这样的重型软件开发方法存在的问题，用一种轻量的、敏捷的方法来改善甚至是替代它。
+
+这些年敏捷开发也是一直这么做的。**瀑布模型的典型问题就是周期长、发布烦、变更难，敏捷开发就是快速迭代、持续集成、拥抱变化。**
+
+## 如果用敏捷的方式盖房子
+
+在讲瀑布模型的时候，我拿盖房子举了个例子，如果改成用敏捷开发的模式盖房子，则会是这样子的：
+
+<li>
+客户想要盖一栋房子（**初步的想法**）。
+</li>
+<li>
+产品经理和客户进行了初步的沟通，把用户的需求写成了一个个用户故事（**用简单的用户故事代替繁重的需求文档**），例如：
+</li>
+
+> 
+<p>作为一个上班族，我想要一个卧室，以便于休息；<br>
+作为一个家庭主妇，我想要一个厨房，以便于做饭。</p>
+
+
+- 施工人员根据用户故事和客户进一步沟通（**客户合作高于合同谈判**），然后对用户故事进行设计和实现；
+- 每个用户故事开发时，还要给一个测试机器人编写测试脚本，让机器人可以自动测试（**大量采用自动化测试**），并且做好的用户故事可以随时被测试验收（**随时发布，持续集成**）；
+- 每个Sprint四个星期时间（**时间盒子，迭代时间固定**）；
+- 第一个Sprint搭了个草棚，一张床就是卧室，厕所就挖了一个坑，厨房还来不及搭建（**每个Sprint会选择高优先级的用户故事**），屋顶还在漏水（**每个Sprint会定期发布，客户可以随时看到可用版本，即使还不完整**）；
+- 第二个Sprint有了简易厨房，同时修复了屋顶漏水的毛病（**每个Sprint不仅完成用户故事，还会修复Bug**）；
+- 第三个Sprint升级成了小木屋，但是忘记加上窗户（**敏捷推崇自动化测试，但可能会测试不完备**）；
+- 第四个Sprint升级成了砖瓦房，窗户也开好了，客户可以入住。但是这时候客户发现一家三口的话，完全不够用，需要扩建到3个卧室。于是决定下个迭代改成3个卧室（**响应变化高于遵循计划**）；
+- 第五个Sprint，升级成了3个卧室，升级过程中把厨房下水道弄坏了（**迭代过程中可能会导致质量不稳定**）；
+- 第六个Sprint，修复了下水道的问题，房子也装修好了（**迭代中不断完善**）；
+- 客户验收使用（**上线**）。
+
+用敏捷开发的方式，不再像瀑布模型那样有严格的阶段划分，会在迭代中不断完善；不再写很多文档，而是和客户一起紧密合作；不再抵制需求变更，而是即时响应变更；不再等到测试阶段才发布，而是随时发布，客户随时可以看到东西。
+
+当然，采用敏捷开发的模式也存在一些问题，例如全程需要客户参与，由于测试相对少一些 ，问题也会相应多一些。
+
+## 敏捷开发和瀑布模型的差异
+
+由于我大学时学软件工程，那时学的就是瀑布模型，毕业后很多年的项目开发都是以瀑布模型为主的，所以我在刚开始去看敏捷开发，总会以瀑布模型的方式类比敏捷开发，实践的时候也难以摆脱瀑布模型的影响。
+
+直到近些年，我完整的在日常项目中反复实践敏捷开发，才逐步领会到瀑布模型和敏捷开发的一些差别。
+
+这些年敏捷开发，已经逐步发展出一套 “Scrum + 极限编程 + 看板” 的最佳实践，Scrum主要用来管理项目过程，极限编程重点在工程实践，而看板将工作流可视化。
+
+我将基于Scrum和极限编程的实践，来对比一下敏捷开发模型和瀑布模型的差异。
+
+**1.敏捷开发是怎么做需求分析的？**
+
+瀑布模型的一个重要阶段就是需求分析，要有严谨的需求分析，产生详尽的需求分析文档。而敏捷开发的需求，主要是来源于一个个小的用户故事，用户故事通常是写在卡片上的一句话，在Sprint的开发中，再去确认需求的细节。
+
+比如一个用户登录网站的需求，在用户故事里面就是一句话：
+
+> 
+作为用户，我想登录网站，这样可以方便浏览。
+
+
+好处是减少了大量需求文档的撰写，可以早些进入开发。但这个对开发人员在需求理解和沟通的能力上要求更高了。
+
+**2.敏捷开发是怎么做架构设计的？**
+
+瀑布模型在需求分析完了以后，就需要根据需求做架构设计。而在敏捷开发中，并不是基于完整的用户需求开发，每个Sprint只做一部分需求，所以是一种渐进式的架构设计，当前Sprint只做适合当前需求的架构设计。
+
+这种渐进式的架构设计，迭代次数一多，就会出现架构满足不了需求的现象，产生不少冗余代码，通常我们叫它技术债务，需要定期对系统架构进行重构。
+
+**3.敏捷开发怎么保证项目质量？**
+
+瀑布模型在编码完成后，会有专门的阶段进行测试，以保证质量。在敏捷开发的Sprint中，并没有专门的测试阶段，这就依赖于开发功能的同时，要编写单元测试和集成测试代码，用自动化的方式辅助完成测试。
+
+相对来说，这种以自动化测试为主的方式，质量确实是要有些影响的。
+
+微软的Windows就是个很好的例子，在Windows 10之前，Windows的开发模式是传统的类瀑布模型，有很长一段测试的时间，质量有很好的保障，Windows 10开始，采用的是敏捷开发的模式，每月发布更新，稳定性要稍微差一些。
+
+**4.敏捷开发是怎么发布部署的？**
+
+瀑布模型通常在编码结束后，开始部署测试环境，然后在测试阶段定期部署测试环境。测试验收通过后，发布部署到生产环境。
+
+在敏捷开发中，这种持续构建、持续发布的概念叫持续集成，因为整个过程都是全自动化的，每次完成一个任务，提交代码后都可以触发一次构建部署操作，脚本会拿最新的代码做一次全新的构建，然后运行所有的单元测试和集成测试代码，测试通过后部署到测试环境。
+
+持续集成是一个非常好的实践，极大的缩短和简化了部署的流程，而且自动化测试的加入也很好的保证了部署产品的质量。前期搭建整个持续集成环境需要一定技术要求。
+
+**5.敏捷开发的Sprint和迭代模型的迭代有什么区别？**
+
+在上一章我介绍了增量模型和迭代模型，这两种也是一种快速迭代的方式，那么敏捷开发和迭代模型的区别是什么呢？
+
+我们假设有两个团队，都要实现一个简单的用户系统，一个团队用迭代模型，一个团队用敏捷开发（Scrum），一个迭代/Sprint的时间周期都是2周（10个工作日）。
+
+迭代模型所在的团队，产品经理会先花2天时间去分析需求，写成需求分析文档，架构师会花3天时间来做设计，程序员会花3天时间编码，测试再花2天时间去测试，最后上线用户系统。
+
+再看敏捷开发的团队，Product Owner（类似于产品经理）会把需求拆分成了几个简单的用户故事：用户登录、用户注册、找回密码、修改资料，然后放到当前Sprint的Backlog（任务清单），Team（开发团队）成员开始从Backlog选择用户故事。
+
+程序员A选了“用户登录”这个用户故事，他会去找Product Owner确认需求细节，之后动手实现这个用户故事。
+
+功能完成后，同时程序员A还写了单元测试代码和集成测试代码，对登录的功能写了自动化测试。完成后，通过持续集成工具测试和部署到测试环境。部署完成后，用户登录功能就可以进行使用了。
+
+这个过程，程序员A可能花了4天时间，做完“用户登录”这个用户故事之后，他又开始继续选取“找回密码”的用户故事来做，4天时间也完成了。
+
+其他程序员也和程序员A一样，他们也会从Backlog选择一些用户故事来做。
+
+当团队中第1个用户故事部署完之后，测试人员就开始帮助测试，发现的Bug都提交到了Backlog，程序员们在完成用户故事后，开始着手修复这些Bug，正好在最后2天都修复完成。
+
+从上面的例子，你可以看出，迭代模型本质上是一个小瀑布模型，所以在一个迭代里面，需要完整的经历从需求分析，到设计、编码、测试这几个完整的阶段。
+
+所以像瀑布模型一样，刚开始测试的时候是不稳定的，到测试后期才逐步稳定下来，一般迭代前期也会相对轻松一点，而后期测试阶段可能会时间很紧张。
+
+敏捷开发的Sprint中，没有像瀑布模型那样严格的开发阶段划分，而是一个个循环迭代的Sprint。举例来说，一个瀑布模型的项目，可能会按照阶段分成：2周需求分析，2周设计，4周编码，2周测试，然后上线发布，一共10周。如果用敏捷开发的方式来进行，那么可能会是每2周一个Sprint，每个Sprint结束后，都会发布上线，每次发布的可能只是完整功能的一部分，但是每次发布的都是一个可用的版本，通过多个Sprint的迭代，最终完成项目开发。
+
+具体到每一个Sprint的开发周期中，在一个Sprint中会有多个小的开发任务，这些开发任务主要是新功能的开发和Bug的修复。由于每个Sprint周期很短，所以不能像瀑布模型那样有充足的时间去做需求分析、设计和测试，那么敏捷开发中怎么保证质量呢？
+
+在敏捷开发中，通常用“用户故事”这样的方式来代替传统的需求分析，也就是以用户故事的形式，对一个需求进行简单的描述，配合关键的测试用例，并且和需求方的紧密沟通，让开发人员可以理清楚需求；通过“只做刚刚好的设计”来节约设计上的时间；通过“自动化测试”、“持续集成”来提升测试效率。
+
+相对来说，敏捷开发中，整个Sprint的节奏是比较恒定，产品也是相对稳定的，即使用户故事没有完成，也不影响版本的发布。
+
+因此，敏捷开发更注重软件开发中人的作用，需要团队成员以及客户之间的紧密协作。
+
+## 该不该选择敏捷开发？
+
+该不该选择敏捷开发，是很多团队纠结的问题。毕竟关于敏捷，有很多在中国落地失败的例子，是不是这种方法在国内水土不服？
+
+其实，敏捷开发无论国内还是国外，大厂还是小厂，都已经有无数成功案例。这些年，软件工程中一些好的实践，像持续集成、测试驱动开发、结对编程、看板等都来自于敏捷开发。可以肯定，敏捷开发是一种非常好的软件开发模式。
+
+但在应用上，也确实需要满足一些条件才能用好，例如：
+
+- 团队要小，人数超过一定规模就要分拆；
+- 团队成员之间要紧密协作，客户也要自始至终深度配合；
+- 领导们的支持。敏捷需要扁平化的组织结构，更少的控制，更多的发挥项目组成员的主动性；
+- 写代码时要有一定比例的自动化测试代码，要花时间搭建好源码管理和持续集成环境。
+
+所以在选择敏捷开发这个问题上，你先要参考上面这些条件。
+
+因为敏捷开发对项目成员综合素质要求更高，做计划要相对难一些。如果团队大、客户不配合、领导不支持，再好的敏捷方法也很难有效实践起来。
+
+如果你要实践敏捷开发，建议先找个小项目进行试点，能证明可行了，再进一步推广。有条件的话，可以和一些顾问公司合作，请人做专门的培训和指导。
+
+如果不具备条件，应该考虑先把其中一些好的实践用起来，比如说持续集成、每日站会、自动化测试等。
+
+## 总结
+
+我们今天一起学习了什么是敏捷开发，也就是敏捷开发是一套价值观和原则。也对比了瀑布模型和敏捷开发，其中的差异还是很大的。
+
+瀑布模型面向的是过程，而敏捷开发面向的是人。敏捷开发要解决的，恰恰是瀑布模型中存在的一些问题。
+
+最后，在要不要用敏捷开发这个问题上，不用过于纠结，看好敏捷开发，那就放心去用，觉得时机还不成熟、还不够了解，就先试点或者只是先借鉴其好的实践。
+
+软件开发，最核心的是人，而不是用什么方法，以前没有敏捷开发只有瀑布模型的时候，也一样诞生了大量伟大的软件，像Windows、Office。现在有敏捷开发，更多的是让我们多了一些选择。
+
+在下一篇文章，还会再从大厂如何应用敏捷开发的角度，继续讲一讲敏捷开发的应用。
+
+另外，敏捷开发涉及内容还是比较多，如果想有更多了解，可以阅读一些书籍作为专栏的补充。
+
+除了[“学习攻略”](http://time.geekbang.org/column/article/82697)中推荐的一些书，还有像《用户故事与敏捷方法》《敏捷武士︰看敏捷高手交付卓越软件》等这些敏捷实践的书籍也可以辅助看看。
+
+## 课后思考
+
+实施敏捷开发能给你的项目带来哪些好处？如果要实施，你打算从什么地方入手？如果已经实施了敏捷开发，你觉得用法对吗？有哪些做的好的或者不好的地方？欢迎在留言区与我分享讨论。
+
+感谢阅读，如果你觉得这篇文章对你有一些启发，也欢迎把它分享给你的朋友。

极客时间专栏/软件工程之美/基础理论/06 | 大厂都在用哪些敏捷方法？（上）.md

@@ -0,0 +1,199 @@
+<audio id="audio" title="06 | 大厂都在用哪些敏捷方法？（上）" controls="" preload="none"><source id="mp3" src="https://static001.geekbang.org/resource/audio/ef/26/efe66303ec6fc93bc32f7357b42a5126.mp3"></audio>
+
+你好，我是宝玉，我今天分享的主题是：大厂都在用哪些敏捷方法？我将分为上下两篇，来与你一起讨论这个话题。
+
+在我还是一个野路子程序员，到处接私活做网站时，就开始好奇：大厂都是怎么开发软件项目的？直到毕业后，我前前后后加入了若干大中小型企业，包括这些年在美国高校、公司的一些经历，对大厂的项目开发有了比较多的了解。
+
+其实大厂做项目也没有什么特别的，无非就是工程中常见的“分而治之”的策略：**大项目拆成小项目，大服务拆成小服务，大团队拆成小团队。**
+
+服务之间通过商定好的标准协议进行通信，架构上将大的服务拆分隔离成微服务，大团队按照业务或者服务拆分成小组，按照一定的流程规范保障协作。最终，各个小组要负责的内容其实就不多了。
+
+就像淘宝这种网站，不需要一个庞大的项目组，通过逐级分拆，一个小组可能就只需要负责一个页面中的一个小模块。
+
+所以，也要归功于现在微服务、容器等新技术，可以将复杂的业务逐级拆分，让很多公司能真正敏捷起来。
+
+在上一篇文章中，我有提到，团队要实施敏捷，不仅要小，还要组织扁平化。相对来说，美国的互联网大企业做的还是很不错的，组织架构都很扁平，工程师地位很高。
+
+这些年，国内工程师地位应该也有很大提升，组织也在向扁平化发展。前些天我也看到阿里工程师写的一篇文章《[敏捷开发的根本矛盾是什么？从业十余年的工程师在思考](https://zhuanlan.zhihu.com/p/34024621)》，对这个问题有精彩的论述。
+
+下面，我就带你一起看看，大厂具体是怎么应用敏捷方法的。
+
+## 和敏捷开发相关的主要流程规范
+
+大厂里流程规范很多，最开始你会不喜欢它们，后来会离不开它们。
+
+> 
+这些墙很有趣。刚入狱的时候，你痛恨周围的高墙；慢慢地，你习惯了生活在其中；最终你会发现自己不得不依靠它而生存。这就叫体制化。——《肖申克的救赎》
+
+
+这里，我简单将其中和敏捷开发相关的流程介绍一下。
+
+### 一切工作任务围绕Ticket开展
+
+早些年的项目开发，都是围绕着项目计划开展的，把甘特图打印贴在墙上，方便团队成员看项目进展到什么地步了。自从敏捷化后，开始变成了看板。
+
+所谓的看板，就是把白板分成几个栏，每一栏为一类，分别写着“To Do（待选取）”、“In Progress（进行中）”、“Done（完成）”等，再把工作任务变成一个个五颜六色的即时贴，根据状态贴在不同的栏下面。
+
+<img src="https://static001.geekbang.org/resource/image/33/a9/33752b50f5363233581263e882e19aa9.jpg" alt="">
+
+慢慢的物理的看板变成了电子看板，通过各种项目管理软件来管理跟踪这些任务，即时贴也变成了Ticket（也有叫Issue的）。逐渐的，所有与开发相关的任务也都和Ticket挂钩了：
+
+- 报一个Bug，提交一个Ticket ；
+- 提一条需求，提交一个Ticket ；
+- 要重构一下代码，提交一个Ticket 。
+
+看板这种基于Ticket来管理跟踪任务的方式，看起来繁琐，但确实是很高效的一种方式。
+
+- 每一个任务的状态都可以被跟踪起来：什么时候开始做的，谁在做，做完没有。
+- 整个团队在做什么一目了然。
+- Ticket和敏捷开发中的Backlog（任务清单）正好结合起来，通过Ticket可以收集管理整个项目的Backlog和当前Sprint（迭代）的Backlog。
+
+有了看板后，大家每天上班第一件事就是打开看板，看看当前Sprint还有哪些Ticket没有完成，哪些已经完成，哪些正在进行中，非常直观。
+
+作为项目成员来说，做完手头的事情也不用去问项目经理该干什么事情了，直接从To Do栏选一条Ticket做就是了；对于项目经理，看看To Do栏还有多少没有被选取，就知道还剩多少Ticket没完成，看看In Progress栏就知道哪些Ticket正在进行中。
+
+如果有Ticket在这一栏待太久或者这一栏Ticket太多，那可能就有风险了，就可以及时介入。
+
+对于项目管理软件和Ticket，我在后面章节中还会有进一步介绍。
+
+### 基于Git和CI的开发流程
+
+如果你的团队应用瀑布模型来开发，大概会有两大烦恼：**代码不稳定和部署太麻烦。**
+
+早些年虽然也用源代码管理，但是大家都是在master（主干）上开发的，所以 master 的代码特别不稳定，一不小心就可能被人签入了不稳定的代码。所以在上线前，有一段时间叫“代码冻结期”，意思就是这期间，除非是紧急修复，否则谁都不能往上面提交代码。
+
+还有，测试环境的部署也是个老大难问题，尤其是在服务较多时，编译要注意各种依赖和环境的配置。所以更新测试环境是个大工程，以至于当年我在飞信的时候，专门有人负责部署测试环境。
+
+上面的“代码冻结”和“专人部署”方案，可一点都不敏捷。所以团队想要敏捷起来，一定要解决代码不稳定和部署太麻烦这两个大问题。
+
+好在基于Git的开发流程结合CI的自动测试部署，很完美的解决了这两大问题。
+
+Git本来只是源代码管理工具，但是其强大的分支管理和灵活的权限控制，结合一定的开发流程，却可以帮助你很好的控制代码质量。
+
+我们假设现在 master 的代码是稳定的，那么怎么保证新加入的代码也稳定呢？
+
+答案就是代码审查（Code Review）和自动化测试。如果代码有严格的审查，并且所有自动化测试代码都能测试通过，那么可以认为代码质量是可靠的。当然前提是自动化测试代码要有一定的覆盖比率。
+
+关于这点，对于大厂来说倒不是什么问题，正规的项目组对于代码审查和自动测试代码的覆盖率都有严格的要求。现在还有一个问题，就是如何在合并到 master 之前把代码审查和自动化测试做好呢？
+
+简单来说，就是每次要往 master 添加内容，不是直接提交代码到 master，而是先基于当前稳定的 master，克隆一个branch（分支）出来，基于 branch 去开发，开发完成后提交一个PR（Pull Request，合并请求）。
+
+<img src="https://static001.geekbang.org/resource/image/dc/f8/dc610641d65152e561fcc704e8797af8.png" alt="" title="图片来源：VSCode项目PR">
+
+PR提交后，就可以清楚的看出来代码做了哪些改动，其他人就可以针对每一行代码写评论提出修改意见。如果确认代码没问题了，就可以通过代码审查。
+
+接下来还剩下自动化测试的问题。这时候该CI （持续集成）出场了。
+
+如果你不了解CI是什么，可以把它想象成一个机器人，每次你提交一个PR（严格来说是Commit，这里略作简化）到源代码服务器，这个机器人马上就知道了。
+
+然后它创建一个干净的运行环境，把你提交的代码下载下来，再下载安装所有依赖项，然后运行你的所有测试代码，运行完后，把测试结果报告给你。测试结果直观的反馈在PR上，绿色表示通过，红色表示不通过。
+
+<img src="https://static001.geekbang.org/resource/image/50/b9/50b61f8062a99658b26c86e1b42fe3b9.png" alt="" title="图片来源：Video-React项目PR">
+
+关于Git和CI，我在之后的文章中会展开讲解，这里只是为了展现敏捷开发方法的流程。另外，阮一峰老师写过两篇文章，《[Git 工作流程](http://www.ruanyifeng.com/blog/2015/12/git-workflow.html)》《[持续集成是什么？](http://www.ruanyifeng.com/blog/2015/09/continuous-integration.html)》，你也可以先行阅读了解。
+
+至此，代码审查和自动测试的问题都解决了。当一个PR代码审查通过，以及CI通过了所有自动化测试，就可以合并到master了，而且我们也可以认为合并到master后的代码也是稳定的。
+
+至于自动部署测试环境，反倒是简单，就是CI这个机器人，在你代码合并到master的时候，再次运行自动化测试代码，测试通过后直接运行自动部署的脚本，把master代码部署到开发环境或测试环境上。
+
+<img src="https://static001.geekbang.org/resource/image/be/12/be26482df2715220b0dc2f90f034bd12.jpg" alt="">
+
+在这里以一个开发任务为例，大致讲解一下应用敏捷开发方法的基本开发流程：
+
+- 把要开发的Ticket从“To Do”栏移动到“In Progress”栏；
+- 从主干（master）创建一个分支（branch），基于分支去开发功能或修复Bug；
+- 编写实现代码和测试代码（单元测试和集成测试），是不是测试驱动不重要，看个人偏好或团队要求；
+- 持续提交代码更新到分支，直到完成；
+- 创建PR（Pull Request，合并请求），邀请其他人帮忙Review代码，根据Review的结果，可能还需要更新几次；
+<li>CI在每一次提交代码到代码库后都会自动运行，运行后主要做这些工作：<br>
+– 检查代码格式是不是符合规范；<br>
+– 运行单元测试代码；<br>
+– 运行集成测试。</li>
+- 最终这些检查都完成后，CI会把执行结果显示在PR上。通常绿色表示通过，红色表示失败；
+- PR能合并需要满足两个条件：CI变绿+代码Review通过；
+- PR合并后，CI会自动构建Docker Image，将Image部署到开发环境；
+- 将相应的Ticket从看板上的“In Progress”栏移动到“Done”栏。
+
+<img src="https://static001.geekbang.org/resource/image/96/78/963f6a02614892e09ef936ac54dc8178.png" alt="" title="图片来源：Jira">
+
+正常来讲，你是需要严格遵守开发流程的，但偶尔肯定也有紧急任务，来不及写测试代码，这种情况下，一定要再创建一条Ticket跟踪，以确保后续完成测试代码。
+
+### 部署上线流程
+
+最早的时候，程序员都是自己管服务器，但是由于这样过于随意，就会导致很多问题出现。
+
+于是后来有专门的运维团队，将开发好的程序，编译好，数据生成脚本写好，然后写成部署文档，交给运维去手动部署。这个过程无比繁琐、无比慎重，通常几周才部署一次，遇上打补丁才隔几天部署。
+
+这些年随着容器化、微服务、DevOps这些技术或概念的兴起，部署已经变得越来越高效，大厂已经开始在部署流程上融合这些理念。
+
+以前是运维人员按照文档部署，现在已经变成了DevOps写自动化部署工具，然后开发人员自己去部署生产环境。
+
+现在大厂的部署也都实现了自动化，但是流程上还是有一些控制。
+
+- 首先，部署的不再是程序代码，而是Docker的Image，每次代码合并后CI都会自动生成新的Image，测试也是基于Image测试。
+- 部署生产环境之前，先在内部的测试环境充分测试。
+- 部署生产环境前，需要审批确认，有Ticket跟踪。
+- 部署时，先部署一部分，监测正常后再全量部署。
+- 整个过程都有监控报警，出现问题及时回滚。
+
+如果一切顺利的话，整个生产环境的服务部署过程通常几分钟就完成了，这在以前简直是不敢想象的事。
+
+## 每日站立会议
+
+在敏捷开发中，每日站会是非常有名的。在大厂，但凡实施敏捷开发的小组，上班第一件事，就是一起开一个站会，沟通一下项目的基本情况，这也导致会议室越发紧张起来。
+
+虽然站立会议什么时间开都可以，但是早上无疑是最好的时机，一天工作的开始，开完会全身心去干活。
+
+**是不是站着开会其实不重要，重点是要高效沟通反馈。**开会时间控制在半小时以内，半小时内不能完成的应该另外组织会议。
+
+谁来主持站立会议呢？在敏捷的Scrum中，有一个角色叫Scrum Master（敏捷教练、敏捷大师），主要任务就是保证各种敏捷流程的。
+
+所以通常是由Scrum Master主持会议，也可以采用轮班制，每个星期换一名团队成员主持。负责主持会议的人，主要职责是组织会议，一个一个环节开展，控制好会议节奏。
+
+开会都干什么呢？主要有三个话题：
+
+**1. 成员轮流发言**
+
+每个人轮流介绍一下，昨天干了什么事情，今天计划做什么事情，工作上有没有障碍无法推进。
+
+一个成员的发言可能是这样的：“昨天我实现了用户登录模块的前端输入框，今天打算完成后端API调用，在实现后端的时候需要API组的支持，昨天发现他们文档有问题，不知道该找谁。”
+
+要注意的是，这过程中很容易偏离主题，比如突然有人提了一句：“我们好久没团建了，是不是该出去玩玩了。”很可能大家都很high的讨论起来了，这时候会议主持者要及时打断，记录到“问题停车场”，让下一个人继续，先保证大家能高效完成这一环节。
+
+> 
+问题停车场（Parking lot question），把需要进一步讨论的问题暂时放到这里，一会儿再讨论。
+
+
+通过这样的形式，项目成员可以相互了解任务进展，有困难也可以互相支援，及时发现问题和风险。还有一个重要因素，就是每个人对于自己提出的目标，也会信守承诺，努力完成。
+
+**2. 检查最新的Ticket**
+
+前面提到所有日常工作都是基于Ticket来开展的，这些Ticket可能是测试报出的Bug，也可能是产品经理提交的需求，也可能是其他。
+
+所以每天例会都需要检查一下新增的Ticket，并且要甄别一下优先级，然后决定是放到当前Sprint，还是放到Backlog（任务清单）。
+
+这个阶段同样要注意不能发散，不要针对Ticket的细节展开过多讨论，有需要讨论的同样可以先收集到“问题停车场”，会议组织者需要做好控制。
+
+**3. 停车场问题**
+
+在这个环节，大家可以针对之前来不及讨论的问题进行讨论，能在会议时间内解决的问题，就马上解决，不能解决的会后再私下讨论或者再组织会议。
+
+当然，大厂的流程规范还有很多，在这里我仅列出与敏捷相关的主要开发流程。
+
+## 总结
+
+我们知道，在敏捷开发中有很多概念，像Backlog、持续交付、每日站会等，这些概念最终要变成实践的话，就必须要通过一定的流程规范来保障这些概念的实施。
+
+这就是为什么很多公司写代码要求你写自动化测试代码，为什么要用一些像Jira、禅道这样的项目管理软件来管理任务，为什么要每天开站立会议，为什么要有代码审查。这些都不过是为了保障敏捷的实施。
+
+如果你在实施敏捷开发的项目工作，就可以多去观察平时工作中这些和敏捷有关的流程规范，再结合敏捷开发中的知识点，就能很好的帮助你理解敏捷开发，理解这些流程规范背后的理论依据。
+
+如果你工作中不是用的敏捷开发，也可以参考本文中提到的一些实践，尝试着试用起来。
+
+在下一篇里，我还会以一个具体的项目小组对敏捷的应用为例，继续给你讲讲大厂都在用的那些敏捷方法。
+
+## 课后思考
+
+你的项目中，有哪些跟敏捷开发相关的实践？你觉得哪些做的好的地方，哪些做的不够好的？或者哪些是你疑惑的地方，都可以留言讨论。另外，你可以再思考一个问题：一个每周一个Sprint的敏捷项目，怎么保证每周都有交付，还能保证产品质量？欢迎在留言区与我分享讨论。
+
+感谢阅读，如果你觉得这篇文章对你有一些启发，也欢迎把它分享给你的朋友。

极客时间专栏/软件工程之美/基础理论/07 | 大厂都在用哪些敏捷方法？（下）.md

@@ -0,0 +1,196 @@
+<audio id="audio" title="07 | 大厂都在用哪些敏捷方法？（下）" controls="" preload="none"><source id="mp3" src="https://static001.geekbang.org/resource/audio/b4/cb/b4f3bdfb5fc59bd9047b98aaad7916cb.mp3"></audio>
+
+你好，我是宝玉，我今天继续与你分享大厂的敏捷方法应用。
+
+在上一篇文章中，我们一起看了一下大厂和敏捷相关的一些流程规范，同时也为你留了一道思考题：
+
+> 
+如果每周一个Sprint，怎么保证每周都有交付，还能保证产品质量？
+
+
+所以在这一篇中，我们就以每周一个Sprint的小项目组为例，看看它的日常是怎么应用敏捷开发的。
+
+## 一个应用敏捷开发的小组日常
+
+这个小组是做网站开发的，基于微服务负责网站的某一个小模块。标准配置7人左右，4个程序员（至少有一个资深程序员，有架构能力），1个产品经理（Scrum里面叫Product Owner），1个测试，1个项目经理（Scrum里面叫Scrum Master）。主要负责网站某模块的日常维护。
+
+在分工上：
+
+- 产品经理：写需求设计文档，将需求整理成Ticket，随时和项目成员沟通确认需求；
+- 开发人员：每天从看板上按照优先级从高到低领取Ticket，完成日常开发任务；
+- 测试人员：测试已经部署到测试环境的程序，如果发现Bug，提交Ticket；
+- 项目经理：保障日常工作流程正常执行，让团队成员可以专注工作，提供必要的帮助，解决问题。
+
+在敏捷开发框架下，已经形成了一些很好的敏捷实践，这个小组也是基于Scrum方法做过程管理，基于极限编程做工程实践，看板可视化。每周一个Sprint。
+
+- **如何完成需求和修复Bug？**
+
+这个小组的日常工作，也是围绕Ticket来开展的。所有的需求、Bug、任务都作为Ticket提交到项目的Backlog，每个Sprint的任务都以看板的形式展现出来。
+
+每个人手头事情忙完后，就可以去看板上的“To Do”栏，按照优先级从高到低选取新的Ticket。选取后移动到“In Progress”栏。
+
+- **每周一部署生产环境**
+
+没有人愿意星期五部署，那意味着如果部署后发现故障，可能周末都没法好好休息了。所以即使程序早已经测试好了，除非特别紧急，否则都会留在下一周再部署。所以部署放在上半周，这样后面遇到问题还有足够的时间去应对。
+
+部署很简单，按照流程执行几个命令就可以完成生产环境部署。部署完成后，需要对线上监控的图表进行观察，如果有问题需要及时甄别，必要的话对部署进行回滚操作。**但轻易不会打补丁马上重新上线，因为仓促之间的修复可能会导致更大的问题。**
+
+像敏捷开发这样一周一个Sprint的好处之一就是，即使这一周的部署回滚了，下周再一起部署也不会有太大影响。
+
+- **每周二开迭代回顾会议，总结上个Sprint**
+
+每周二的早上，这个小组一般还会预留一个小时的时间，因为常规的站会完成后，还有一个**迭代回顾会议(Sprint Retrospective)**会议，目的是回顾一下在迭代中，团队有哪些做的好的地方，有哪些做的不好的地方。
+
+对于需要后续改进的，需要创建相应的Ticket，加入到Backlog中，在后续迭代中改进完善。
+
+例如会议上，测试人员反馈说，上一个Sprint，开发人员上线前几个小时还往预部署的分支里面更新代码，导致测试需要重新做回归测试，但因为时间不够了，没来得及测试完整，导致上线后不稳定，建议以后不要随意在上线前，在部署分支更新代码。
+
+对于这样的问题，可能不止一次发生，说明流程上还是存在问题。所以最后大家商定，以后如果不是紧急的修复，就不要在预部署的分支上更新，确实要加，需要和测试先确认。
+
+如果会议中要形成涉及项目的决策，最好是通过集体表决的方式决策，尽可能避免独裁式决策。因为敏捷的原则之一是要**善于激励项目人员，给他们以所需要的环境和支持，并相信他们能够完成任务。**
+
+- **每周四迭代规划会，计划下周工作**
+
+每周四早上，也需要一个小时来组织会议。因为常规站会完成后，还有一个**迭代规划会（Sprint Planning Meeting）**。这个会议是要大家一起讨论下一个Sprint 的内容。
+
+在开会之前，产品经理和项目经理会商量好Ticket的优先级，会议上，大家一起按优先级从高到低的顺序，从Backlog中选出下个Sprint的内容。
+
+团队每个成员都要对候选的下个Sprint Backlog中的Ticket从1-5分进行打分，1分表示容易1天以内可以完成的工作量，2分表示2天内可以完成的工作，5分表示非常复杂，需要5天以上的工作量。
+
+这里需要注意，打分时，要大家一起亮分，而不是挨个表态，不然结果很容易被前面亮分的人影响。
+
+**评估每条Ticket工作量的大概流程如下：**
+
+1. 会议组织者阅读一条Ticket，可能是用户故事，可能是Bug，可能是优化任务。同时会询问大家对内容有没有疑问。
+1. 大家一起讨论这个Ticket，确保充分理解这个Ticket。
+1. 每个团队成员在心中对Ticket进行工作量估算。
+1. 会议组织者确认大家是否都已经确定估算结果，确认后，开始倒数：“3，2，1”，大家一起伸出一只手，亮出代表分数的手指头。
+1. 如果估算结果存在分歧，出分最高的和最低的各自说明理由，讨论后达成一致。
+
+这种估算工作量的方法有个名字叫估算扑克，因为亮分时用扑克牌亮分而得名，但并非一定要用扑克牌。
+
+**用这种方式评估工作量有几点很明显的好处：**
+
+1. **大家积极参与，详细了解需求。**相比以前，可能只有当某个功能模块分配到自己头上的时候，才会去详细了解那部分需求，而其他开发人员可能都不了解这部分需求。
+1. **工作量是由实际参与开发的成员作出评估，往往更准确也更容易被接受。**以前项目经理代为估算的模式，很容易不准确，或者让开发人员抵触。
+1. **促进成员的交流和经验分享。**我们知道一般经验浅的新手估算工作量都会偏乐观，而经验丰富的老手则会更准确，通过这种方式，新手可以向老手学习到很多工作量估算甚至技术实现的经验。
+
+所以，在经过几个Sprint的磨合后，一般一个团队在每个Sprint的产出是比较稳定的。比如说这样一个7人的小团队，一个Sprint预计可以完成20-30分的Ticket。
+
+- **每周五分支切割**
+
+周五标志着一周的工作要结束了，所以下班之前（4点左右），要做branch cut（分支切割），也就是要把当前主干上的代码，克隆到一个分支（branch）上。
+
+为什么要做分支切割这一步操作呢？
+
+经过一周的开发，master （主干）已经合并了不少新的PR（Pull Request，合并请求），但是如果你直接把master的代码部署到生产环境，肯定还是不放心，毕竟自动化测试还是不能完全代替专业测试人员的测试。
+
+所以我们需要把master上的代码部署到测试环境进行测试，并且对测试出来的Bug进行修复，直到稳定下来为止。由于master还需要一直合并新的功能，所以最好的方式就是每次Sprint结束，从master创建一个分支版本出来，然后基于这个分支部署和修复Bug。
+
+所以需要基于主干做一个branch cut，创建一个预部署的分支，将预部署分支的代码部署到测试环境，这样在下周，测试人员就可以测试新的版本。测试验收通过后，预部署分支的代码会部署到生产环境。
+
+<img src="https://static001.geekbang.org/resource/image/a1/67/a1ff4dc93ffa7d68ab5d757317623167.png" alt="">
+
+- **每周轮值**
+
+小组里面除了日常开发工作以外，其实还有不少琐碎的事情，比如每周部署生产环境，每天部署测试环境，每周的branch cut（分支切割），回答其他小组的问题，主持每日会议（不一定需要项目经理），这些事情如果都是一个人做难免会有些枯燥。
+
+在敏捷开发中，鼓励发挥每个成员的主动性，所以每周轮值是一个不错的方式，可以让每个人都有机会去体验一下，帮助团队完成这些事情，更有集体荣誉感和责任感。
+
+## 一些问题解答
+
+上面只是选取的一个项目小组的日常，所以估计你看完还会有些疑问，在这里我把可能的问题列一下，先行解答一下。
+
+**1. 基于这种敏捷开发的方式加班多吗？**
+
+其实加不加班，绝大部分时候和是不是敏捷开发没关系的，还是看项目组的情况。
+
+通常来说，基于敏捷开发一个Sprint、一个Sprint迭代，节奏还是比较稳定的，这个Sprint做不完的任务也可以顺延到下个Sprint，不影响发布。不像瀑布模型那样前松后紧，后期加班可能性大一些。
+
+**2. 一周一个迭代怎么保证质量？**
+
+以前我在使用迭代模型开发时，一般是4周左右的迭代周期，2周就是极限了，所以最开始看敏捷开发用1周的迭代周期，心中也有疑惑，1周时间又要开发又要测试，怎么保证质量？
+
+实际实践下来，发现1周一个Sprint确实可行，而且质量也可以有保障，这里面有几个因素：
+
+（a） 有足够比例的自动化测试代码，可以很好地保证质量。当用户的主要功能都通过自动化测试覆盖时，基本可以保证主要功能流程不会出问题。
+
+（b） 一个Sprint开发完成后，并不马上部署生产环境，而是先部署到测试环境，会有1周时间测试。
+
+（c） 有专业的测试人员进行测试，并非完全依赖自动化测试。有时候一些大的功能更新，甚至会组织全组成员一起测试，以弥补测试人员不足的情况。
+
+在一个Sprint开发结束后，并不马上部署生产环境，而是先部署测试环境测试。
+
+<img src="https://static001.geekbang.org/resource/image/30/c5/30f2a81130d5adc74921c88a0f7464c5.png" alt="">
+
+也就是说，虽然是1周的Sprint，但是其实还有1周的时间进行测试。每个Sprint不仅开发新功能，还要同步修复以前版本的Bug。
+
+这样基本上可以保证有好的质量。而且这种1周的迭代，可以保持每周都有内容更新，还有个好处就是每周更新的内容不多，出现问题的话，很容易就定位到是什么地方导致的问题。
+
+**3. 基于敏捷开发如何做计划？**
+
+大厂里面通常会在上一年底确定第二年整年的大的开发计划，并确定上线的时间范围，每个季度再根据情况做一些调整。
+
+这些大的计划最终会变成具体的开发任务，一个大的开发任务，会分拆到各个部门，各部门再将任务分拆到各个项目组。基于敏捷开发的话，主要就是看把这些开发任务放到哪几个Sprint去做，并且确保在规定的时间范围内完成。
+
+至于工期的估算，在迭代规划会上会对每个Ticket进行打分，根据分数可以预估有多少工作量，要花多少时间。
+
+**4. 如何沟通协作？**
+
+组和组之间的沟通协作，主要通过邮件、会议、内部沟通工具，最终任务会以Ticket的形式体现。
+
+团队内部的话，因为都在一起，所以沟通起来很方便，每天站立会议都是很好的沟通方式。
+
+在敏捷开发中，有一种实践叫结对编程，就是两个程序员在一台电脑上一起工作。这个一直争议比较大，但是如果用来两人一起排查一些问题，或者是资深程序员带新手程序员，则是一种非常好的协作方式。
+
+**5. 上面介绍的实践案例和标准Scrum有什么不同？**
+
+我上面介绍的内容，确实和标准的Scrum有不少不一样的地方。
+
+首先是角色名称不一样，在Scrum里面是分Product Owner、Scrum Master和Team三种角色，而在这个案例中是产品经理、项目经理和团队成员，但其实只是名字叫法不一样。
+
+还有要注意一点，就是传统的项目经理，会是偏控制型角色，Scrum Master则更多是一种服务型的角色，主要职责是保障敏捷流程的执行，以及提供必要的帮助，很多团队的决策就是采用集体决策的方式。
+
+另外，Scrum有四种会议，除了前面介绍的三种：每日站会（Daily Scrum）、Sprint计划会（Sprint Planning）和Sprint回顾会议（Sprint Retrospective），其实还有一种会议是Sprint评审会（Sprint Review）。
+
+Sprint评审会的作用是让客户审查Sprint的完成结果。因为上面这个小组并没有直接的客户，都是完成产品经理提交的需求，而且沟通紧密，所以没有安排专门会议。
+
+这个小组的站立会议并不是“标准”的站立会议，Scrum的站立会议通常只有15分钟，并且只有轮流发言环节。
+
+这里增加的每天审查Ticket环节，主要是为了将优先级高的Bug修复之类的Ticket放到当前Sprint，及时响应，及时处理。有的项目组没有这个环节，是由测试人员或者Scrum Master直接将Ticket放到看板。
+
+这个小组并没有使用用户故事来开发需求，而是由产品经理事先写好需求文档。在上一篇文章里面，提到了Scrum采用用户故事的方式，分拆需求，减少繁重的需求文档，在实现的过程中再沟通确认需求。
+
+这是Scrum推荐的一种方式，也是一种高效的方式，但并不代表这是唯一的方式。如果有产品经理，可以提前几个Sprint就将需求文档写详细，一样可以达到高效的理解需求的效果。
+
+那么这样还算敏捷开发么？
+
+其实在[《05 | 敏捷开发到底是想解决什么问题？》](http://time.geekbang.org/column/article/84351)就有讲过，是不是敏捷开发，核心并不是应用了哪个方法，而是应用的时候，是否遵循了敏捷开发的价值观和原则。
+
+比如说非标准的站立会议效率更优，那么就应该采用非标准的站立会议；如果有专业产品经理事先做好需求分析，可以达到解释清楚需求的效果，就没必要一定要用用户故事来理解需求。
+
+## 总结
+
+上一篇文章我们讲了大厂里和敏捷相关的一些流程规范，这一篇又讲了一个小组是怎么应用敏捷开发来开发项目的。
+
+现在看上一篇文章中我留的思考题：如果每周一个Sprint，怎么保证每周都有交付，还能保证产品质量？想必你已经有了答案。
+
+要保障质量，还是离不开充分的测试，不仅要有自动化测试，还要辅助一定量的人工测试。敏捷开发虽然求快，但是不代表应该牺牲质量。
+
+其实，大厂的敏捷实践并不神秘，关键是分而治之，最终团队小，项目小，所以才可以敏捷起来。大厂会注重流程和工具的应用，通过Ticket的方式来管理和跟踪开发任务，通过自动化的方式来部署。
+
+大厂的敏捷实践，一般是基于Scrum、极限编程和看板，针对各自项目组的特点，会有所侧重有所调整，在遵循敏捷的价值观和原则的前提下，做到高效使用。
+
+希望上面介绍的敏捷应用，能对你理解敏捷开发有所启发，帮助你优化改进日常项目流程。还有要注意的一点就是，没有万能的开发模式，只有适合项目的开发模式，最重要的还是要摸索出一套适合你自己项目特色的开发模式。
+
+限于篇幅，对于Scrum、极限编程和看板，我并没有展开细讲，还需要大家自己辅助看看书，我在[《学习攻略 | 怎样学好软件工程？》](http://time.geekbang.org/column/article/82697)和[《05 | 敏捷开发到底是想解决什么问题？》](http://time.geekbang.org/column/article/84351)文章中也列了一些参考书籍。
+
+留言区有同学推荐的文章[《天下武功，唯快不破—新时代敏捷项目管理之道》](http://mp.weixin.qq.com/s/puMNz91hiQgio4wSCIrTgQ)对敏捷开发也有很不错的讲解，推荐阅读。
+
+## 课后思考
+
+看完本篇内容，你可以将上面介绍的开发模式和你现在的项目开发模式对比，你觉得有哪些好的地方可以借鉴？你觉得有哪些做的不够好，可以改进的地方？
+
+另外，你也思考一下，为什么文章中，这个项目没有在一个Sprint里面同时完成开发和测试，而是把测试放在下一个Sprint，这样做有什么优缺点？欢迎在留言区与我分享讨论。
+
+感谢阅读，如果你觉得这篇文章对你有一些启发，也欢迎把它分享给你的朋友。

极客时间专栏/软件工程之美/基础理论/08 | 怎样平衡软件质量与时间成本范围的关系？.md

@@ -0,0 +1,175 @@
+<audio id="audio" title="08 | 怎样平衡软件质量与时间成本范围的关系？" controls="" preload="none"><source id="mp3" src="https://static001.geekbang.org/resource/audio/d8/16/d835ffc3ea4ed705b920a9a3cfe55816.mp3"></audio>
+
+你好，我是宝玉，我今天与你分享的主题是：怎样平衡软件质量与时间、成本、范围的关系。
+
+在[《从软件工程的角度解读任正非的新年公开信》](http://time.geekbang.org/column/article/82255)这篇文章中，我已经提到了“软件项目管理金三角”的概念。由于这个内容对于软件工程来说，非常之重要，所以我今天特别展开再讲一下。
+
+你会发现，在实际的软件项目中不乏这样的例子：
+
+- 一个项目，正常估算，要三个月才能完成，但是老板或客户要压缩到一个月完成，而你不知道如何说服他们；
+- 项目开发一半，产品经理告诉你，有一个非常紧急的功能，要增加到这个版本中，你不知道该不该拒绝，或者如何拒绝；
+- 听说迭代模型很好，你也尝试使用迭代模型，但是每次迭代时间到了还是完不成，只能把迭代时间延长，最后又做回传统的瀑布模型了；
+- 你们组用瀑布模型开发，一到项目后期总免不了加班加点赶进度，为什么他们用敏捷开发的加班要少一些？
+
+其实，这些日常项目中涉及**时间、成本和范围**的问题，都离不开“**软件项目管理金三角**”的概念。
+
+掌握好这个知识点，学会平衡软件质量与时间成本范围的关系，可以帮助你更好的驾驭项目中的各种问题，也可以帮助你更好地理解软件工程中各个模型，尤其是瀑布模型和敏捷开发。
+
+## 什么是软件项目管理金三角？
+
+在现实生活中，我们都知道，做产品想“多、快、好、省”都占着，是不可能的，最多只能选两样。
+
+想要便宜和质量好，就要花时间等；想要快还要质量好，那就得多花钱；想要又便宜又快，那就得接受难用、质量差。
+
+<img src="https://static001.geekbang.org/resource/image/f5/cf/f5bb522b7fd25d6d7738642e4c922ccf.jpg" alt=""><br>
+而在软件项目中，也有一个类似的平衡关系，就是软件质量（产品的质量，客户的满意度）与范围（需要实现多少功能）、时间（多久可以完成）、成本（花多少钱）四个要素之间的平衡。
+
+<img src="https://static001.geekbang.org/resource/image/7f/f7/7fa5c8351b4590a2bc8a482955c133f7.jpg" alt="">
+
+上面这个图就是著名的项目管理金三角（以下简称“金三角”），三条边分别是时间、成本和范围，中间是质量。
+
+为什么四个要素，是“质量”放在三角形的中间？
+
+因为**软件工程的目标就是要构建和维护高质量的软件**，所以项目的质量是高于一切的。也就是说，“质量”这个因素一般不会妥协，因此把“质量”放在三角形中间，然后在时间、成本、范围这三条边之间寻求平衡。
+
+质量往往也是其他三个因素平衡后结果的体现，想要做的快、成本低、功能多，最后一定是个质量很差的产品。
+
+## 如何应用“管理金三角”做决策？
+
+我在专栏中常用“道术器”来比喻软件工程中的各个知识点，“金三角”无疑就是“道”级别的。
+
+**项目管理其实就是项目中一系列问题的平衡和妥协**，而“金三角”理论则为我们的平衡提供了理论指导，了解这三个因素分别对项目其他方面产生的影响，可以帮助你在做决策时进行权衡取舍。
+
+当你接手一个项目，项目的进度、成本和范围指标很容易可以跟踪到。有了这些信息，你就可以及时发现问题，调整“金三角”的边，及时解决，以防止这些小问题发展成大问题。
+
+我来举两个例子，看看“金三角”是如何应用的。
+
+- **老板要压缩项目时间怎么办？**
+
+当项目经理，常遇到的问题之一就是时间被压缩，比如文章中开头举的例子，老板问我一个项目多久能完成，我按照经验，觉得要三个月，老板觉得三个月太久了，要砍到一个月就上线。
+
+最开始的时候，我就是据理力争，说这不科学，肯定不行呀。老板说时间点很重要，必须要一个月上线。结果就是大家吵得不欢而散，最后还得加班加点做，质量也不好。
+
+后来我学乖了，先用“金三角”知识分析了一下：老板希望时间是1个月，也就是说时间这条边被缩短了，那么结果就是会影响到另两条边：范围和成本，如果另外两条边可以调整，也不是不可以。
+
+于是再遇到这种问题，我就换了一种方式跟老板沟通：“一个月也不是不行，就是我们的需求调整一下，第一个版本只能做一些核心功能，剩下的后面版本再加上（**调整范围**）。另外还得给我加两人，不然真做不完！（**增加成本**）”
+
+这样的方案一提出来，就好沟通多了，最后重点就变成了砍多少功能和加多少人的事情了。
+
+- **产品经理要临时加需求怎么办？**
+
+在文章开篇我提到一种情况，项目开发一半，产品经理告诉你，有一个非常紧急的功能，要增加到这个版本中，怎么办？我们拿“金三角”知识先套用一下。
+
+增加需求，也就是范围这条边要增加，那就必然对成本和时间这两条边造成影响，要么延期，要么增加成本。
+
+面对这种临时加需求的情况，我们也不需要直接说不能加，而是清楚的让产品经理认识到这样做的后果：进度延期，需要更多的成本。如果这个功能真的太重要，可以接受延期，也不是不可以接受，那就重新制定新的项目计划好了。
+
+所以你看，如果我们能应用好“金三角”的知识，很多软件项目中问题，一下子就多了很多方案可以选择了。
+
+## 瀑布模型和敏捷开发如何平衡时间成本范围的关系？
+
+除了可以将“金三角”的知识应用在软件项目中，还可以应用它来理解和应用软件工程中的开发模式，尤其是瀑布模型和敏捷开发这两种典型的开发模式。
+
+瀑布模型有严格的阶段划分，有需求分析、系统设计、开发和测试等阶段，通常在开发过程中不接受需求变更，也就是说，我们可以认为**瀑布模型的范围是固定的，其他两条边时间和成本是变量。**
+
+所以使用瀑布模型开发，如果中间发现不能如期完成进度，通常选择的方案就是延期（加班），或者往项目中加人。
+
+<img src="https://static001.geekbang.org/resource/image/27/a0/27e916733d013fa85b2964a2b1051ea0.jpg" alt=""><br>
+我们再来看敏捷开发，敏捷开发中，是采用固定时间周期的开发模式，例如每两周一个Sprint，团队人数也比较少。所以，**在敏捷开发中，时间和成本两条边是固定，就只有范围这条边是变量。**
+
+这就是为什么在敏捷开发中，每个Sprint开始前都要开Sprint计划会，大家一起选择下个Sprint能做完的任务，甚至于在Sprint结束时，没能完成的任务会放到下个Sprint再做。
+
+<img src="https://static001.geekbang.org/resource/image/1y/73/1yy45e28893d0b4652e780d47f0a2873.jpg" alt=""><br>
+这时候再想想文章开头我们提到的问题：
+
+> 
+听说迭代模型很好，你也尝试使用迭代模型，但是每次迭代时间到了还是完不成，只能把迭代时间延长，最后又做回传统的瀑布模型了。
+
+
+你现在是不是就明白了：如果不能固定“时间”这条边，就会导致时间也成了变量，迭代自然无法正常推进。
+
+## 如何平衡好软件质量与时间成本范围的关系？
+
+那么怎么样才能平衡好软件质量与时间成本范围的关系呢？
+
+前面我们说日常生活中“多、快、好、省”最多只能选两样，其实如何平衡好软件质量与时间成本范围的关系也是一样的道理，我们只能最多选择两样，然后在另一边或者另两条边去寻找平衡。
+
+所以第一件事就是：**从时间、成本和范围这三条边中找出来固定的一条或者两条边，再去调整另一条边。**
+
+下面，我来分析一些案例，帮助你更好地理解。
+
+**1. 淘宝网站第一个版本是怎么做到一个月上线的？**
+
+这个故事其实我是从极客时间《从0开始学架构》专栏看来的，李运华老师在《架构设计原则案例》一文中举了淘宝网站的例子：
+
+> 
+2003年4月7日马云提出成立淘宝，2003年5月10日淘宝就上线了，中间只用了一个月时间。
+
+
+好，如果你是当时的淘宝网站负责人，马云要你一个月上线淘宝网站，功能还不能少，你怎么办？
+
+第一件事当然是先应用“金三角”分析一下：时间这条边被固定了，只能一个月；功能也不能少，范围这条边也限制住了，那就只能在成本上想办法了。要么一下子雇很多牛人，要么直接买一个现成的电子商务网站，然后修改。
+
+显然，直接买一个网站，再雇一堆牛人的方案最好，所以淘宝网站就这样在一个买来的网站基础上，由一堆牛人快速搭建起来了。归功于淘宝网站的快速上线，刚推出后，正好赶上“非典”，网购需求增大，淘宝网一下子就火爆起来了。
+
+从成本角度我们还有可以去做的，比如说有同学在看完[《06 | 大厂都在用哪些敏捷方法？（上）》](http://time.geekbang.org/column/article/84652)这篇文章后，也想在团队里面推行代码审查和CI，但是苦于搭建这一套git+CI的系统没有经验，不知道该如何下手，怎么办呢？
+
+我的建议就是刚开始就没必要自己去折腾了，买一套GitHub的企业版，加上支持GitHub的商业CI系统，花不了多少钱，而且可以节约大量搭建这种系统的时间。
+
+**2. 极限编程是怎么做到“极限”的？**
+
+前面在介绍敏捷开发的时候，也提到了极限编程（eXtreme Programming，XP），是目前敏捷开发主流的工程实践方法，极限编程的“极限”（Extreme），意思就是如果某个实践好，就将其做到极限。比如：
+
+- 如果做测试好，就让每个开发人员都做测试;
+- 如果集成测试重要，就每天都做几次测试和集成;
+- 如果简单的就是好，那么我们就尽可能的选择简单的方法实现系统功能;
+- ……
+
+极限编程的“极限”理念，产生了很多优秀的实践方法，例如持续集成、自动化测试、重构等。
+
+这些实践帮助我们可以在短时间的迭代中，产生高质量的代码。我们用“金三角”的理论来分析一下极限编程在Sprint中的应用。
+
+在一个Sprint中，计划好了当前Sprint要做的工作内容后，那么极限编程怎么帮助我们提高代码质量呢？
+
+一个Sprint要做的内容是确定的，相当于成本和范围这两条边都固定了，时间这条边就成为变量了。要么通过加班延长工作时间，要么通过提升效率、减少浪费帮助我们提升时间利用率。
+
+极限编程，就是通过帮助我们提升效率和减少浪费这方面来做的。比如说：
+
+- 持续集成，通过自动化的方式帮助我们部署，节约了大量需要人去手动部署的时间；
+- 自动化测试，通过自动化测试，节约测试时间，另外，有了自动化测试，可以避免后面修改代码产生Bug，减少了大量的浪费；
+- 只做刚好的设计，避免设计时考虑了太多不必要的可能，造成浪费。
+
+其实我们在项目中也有很多地方可以借鉴这种思路，比如说写代码的时候，少自己造轮子，多使用成熟的开源或者商业组件，可以提升效率；比如把需求想清楚搞清楚再去开发，可以减少很多返工的时间成本！
+
+**3. MVP模式是怎么诞生的？**<br>
+这些年流行的MVP（minimum viable product，最小化的可行性产品）模式，是一种快速推出产品的模式：一开始只推出最核心的功能，满足用户最核心的需求，然后在用户的使用过程中收集反馈，进一步升级迭代。
+
+这种模式怎么诞生的呢？还是应用“金三角”理论，要快速推出产品，还想成本不用太高，那就意味着时间和成本这两条边是固定的，剩下范围这个变量。
+
+所以最简单有效的办法就是砍掉一些重要性不那么高的功能需求，只保留最核心的需求。通过缩小范围的方式，达到快速推出高质量产品的效果。
+
+类似的道理，我们程序员，在遇到很多功能忙不过来的时候，可以主动的去和项目经理协商，砍掉一些不那么重要的需求，把精力放在核心需求上，保证项目可以如期上线。
+
+## 总结
+
+其实，要平衡好软件质量与时间成本范围的关系并不难，你只需要记住，最重要的是根据“金三角”的三条边，找出来固定的一条或两条边，然后去调整剩下的边，达到平衡。
+
+软件项目的“金三角”很多人都知道，主要是不知道如何应用到实际的项目中，希望这篇文章能为你提供一些思路，帮助你在项目中真正应用好这个非常实用的知识。
+
+## 课后思考
+
+关于今天的内容，邹欣老师在《构建之法》书中，提出了一个很好的问题。我也在这里列出来，希望你可以思考一下。
+
+<img src="https://static001.geekbang.org/resource/image/28/8c/2805340682c1b5068a744c6f9414b98c.jpg" alt="">
+
+顾客对于要交付的软件和服务，都是有很多美好的需求的， 用户希望软件开发的又快， 又便宜 （人工便宜），质量又好， 最好是免费的。  那么，如果只满足部分的需求， 我们会得到什么样的软件呢？
+
+例如，上图的 ① 说明， 如果希望软件做得又快，又低成本（人工便宜）， 不考虑其他要求， 那么，我们会得到大致什么样的软件呢？
+
+例如，上图的 ⑤ 说明， 如果希望软件是免费的，而且要很快交付，越快越好， 那么，这样的软件有什么特点呢？
+
+请把 ① 到 ⑦ 的需求组合会导致什么样的软件， 会出现什么样的问题， 都列出来。
+
+另外，对于质量和时间成本范围的平衡，你有没有什么应用的案例？你对你当前项目的时间、范围和成本都清晰吗？有没有什么可以做的更好的地方？欢迎在留言区与我分享讨论。
+
+感谢阅读，如果你觉得这篇文章对你有一些启发，也欢迎把它分享给你的朋友。

极客时间专栏/软件工程之美/基础理论/“一问一答”第1期 | 30个软件开发常见问题解决策略.md

@@ -0,0 +1,472 @@
+<audio id="audio" title="“一问一答”第1期 | 30个软件开发常见问题解决策略" controls="" preload="none"><source id="mp3" src="https://static001.geekbang.org/resource/audio/0f/d1/0f76d613f4df4809f1db600622a476d1.mp3"></audio>
+
+你好，我是宝玉。专栏已经上线更新一段时间，看到同学们对软件工程有了更深刻的理解和思考，我很受感触。
+
+有些人说走了很多弯路，日常搬砖，增删改查；也有的同学跟我一样“野路子”程序员出身，非常困惑希望建立自信；还有的同学发表上千字的学习心得，可以说非常用心。
+
+编码的最终目的还是为了实现一整个软件的开发，在程序员的晋升之路上，总有单独挑大梁负责项目的时候。你会发现软件开发中的很多问题，都是可以通过软件工程的知识来解决的。
+
+在已经更新的文章中，同学们经过思考，结合自己的工作实践场景，提出了非常好的问题。我们专栏的留言内容成为了专栏最好的补充。于是我就将留言板中的答疑和精彩留言进行汇总，方便你更好的查阅和理解专栏内容。
+
+## 一问一答
+
+No.1<br>
+**hua168**：学这个专栏需要哪些基础知识为前提的？开发都要学哪些基础东西？
+
+**宝玉**：学习这个专栏，不需要你有特别的基础，当然有一些项目经验可以帮助你更好的理解。至于要学什么基础的东西，其实你可以从另一个角度思考一下：**开发的价值是体现在哪的？**
+
+开发的价值是通过在项目中创造价值体现的，所以你要考虑学什么能帮助到你更好的在项目中创造价值。比如说除了具体的编程技能外，还可以从这些方面思考：
+
+1. 提升对需求分析和理解的能力，这样你就知道要做的是什么，减少返工；
+1. 提升架构和抽象的能力，能把需求抽象成架构设计，能把复杂的问题通过架构分解成简单的问题；
+1. 高效率的编码，完成需求，等等。
+
+No.2<br>
+**hua168**：软件工程在游戏项目上，是不是也一样呢？<br>
+**zhxilin℃**：对游戏行业的过程模型有什么理解？
+
+**宝玉**：万变不离其宗。游戏项目一样离不开软件工程，游戏开发本身也是软件开发，只是有些名字换了，比如产品经理变成了游戏策划，产品设计变成了游戏策划案。游戏开发一样要有需求分析、架构设计、编码、测试等关键活动。只是游戏项目的需求变更频繁、节奏快，用增量或者迭代要好很多！另外也可以试试敏捷开发。
+
+No.3<br>
+**于欣磊**：现在已经进入云计算时代，基本上大中小企业都在上云，复杂逻辑都在云端处理，真的还需要软件工程里讲的开发要搞这么多流程么？
+
+**宝玉**：是的，云计算的兴起可以减少很多劳动，但不代表你就什么都不用做了，还是要做需求分析，再去做架构设计，做完架构设计你才能清楚哪些可以用云计算，那些需要自己去实现。最后编码完了，一样还要测试的。
+
+No.4<br>
+**hua168**：现在运维的前景怎么样？感觉竞争很激烈，很多小公司都不招，开发兼职了运维，各大云出了一些维护监控工具，对他们来说够用了，感觉发展空间变小了，运维开发招也少了……也有人提到运维职业会消失，难道要转开发？那运维开发能力也争不过真正的开发啊。
+
+**宝玉**：你这个问题很有代表性，现在云服务兴起后，传统运维的职位在减少，所以DevOps在兴起。DevOps和运维的主要差别就是DevOps不仅有运维能力，还有开发能力，可以站在运维和开发更高的角度去看问题，帮助自动化的，稳定的交付部署产品。你不用完全转开发，但是应该要学习一些开发知识，尤其是自动化脚本相关的。
+
+No.5<br>
+**行者无疆**：传统瀑布模型前期进行了完整的需求评估，在技术选型，系统架构，实施路径上可以做好全面的规划，虽然周期长，不必要的反复工作会少很多，目标也更容易控制。
+
+那敏捷模型的迭代方式并不会把需求都考虑全面，未来的迭代可能会造成前面的技术架构或者实施细节等都不能满足新需求的要求。所有工作都要重来的问题，会存在大量的重复工作和资源浪费。 敏捷模型是如何有效地规避这些问题的呢？
+
+**宝玉**：你说的问题确实存在，导致常说的技术债务问题，所以需要定期去重构，改进这些问题。迭代过程中的重复工作确实存在，但是软件开发中的浪费其实主要不是在于迭代过程中的重复工作，而是在于需求不明确和需求变更导致的返工或失败。
+
+敏捷开发持续发布稳定版本的理念还是利大于弊。有一些项目其实是瀑布模型和敏捷开发的结合，需求分析和系统设计的时候用瀑布模型，开发和测试阶段用敏捷，也是个不错的选择。
+
+No.6<br>
+**Geek_85f782**：如果说软件工程=过程+方法+工具，其中过程是否就是具体指软件的生命周期？方法是指选用的生命周期模型，比如瀑布、螺旋、迭代、敏捷？
+
+**宝玉**：我认为过程应该包含过程模型采用的方法。而方法是指基于过程模型之下的方法。因为过程模型决定了软件开发过程是什么样的，进而决定了采用什么开发方法。
+
+比如你选择了瀑布模型，整个软件开发过程就是按照瀑布模型的分阶段来进行，对应的方法就是瀑布模型中的方法，例如需求分析、架构设计；如果你选择了敏捷开发，则整个开发过程就是一种敏捷迭代方式，后面的方法对应的就是敏捷开发的一套方法体系，例如Scrum、用户故事、持续集成等。
+
+No.7<br>
+**hua168**：中小公司，开发人员流失严重，如果像工厂流水线那样，即使核心开发人员全部走了，新招的开发在没有人带的情况下，能继续接上开发……除了制定规范，开发文档之外还有哪些措施？
+
+**宝玉**：软件开发，核心就是人，如果没有人，规范和文档都没意义的。要留住人，一个是得舍得给钱，另一个得有个好的环境，还有就是要有梯队，能把新人培养上去。饭店里只有一个大厨，大厨当然敢乱提要求，如果大厨多几个，就不担心了。还是得要舍得下本钱招优秀的人。
+
+No.8<br>
+**白发青年**：如果是外包项目，作为项目的乙方，如果采用敏捷开发，最初的工作量就很难完整估计，不利于双方的合同签订。不知老师是否有好的建议？
+
+**宝玉**：这个问题通常有两种解决方案供参考：
+
+1. 你按照瀑布模型的方式去估算工作量，然后签订合同。开发的时候你需求分析和架构设计还是用瀑布模型的方式，但是编码和测试用敏捷开发。这是一种不错的折中方案；
+1. 你把所有需求拆分成用户故事，对用户故事进行打分（了解下计划扑克之类的打分方案），然后可以算出来一个总分数。另外按照你以前敏捷开发的经验，可以知道每个Sprint大概能完成多少分，这样你就能大致推算出来工期。
+
+No.9<br>
+**Charles**：瀑布模型非常考验人的能力，会造成互相扯皮推卸责任，上线以后有什么问题，还会互相推锅背，这种情况下管理者有啥好的方式去解决？
+
+**宝玉**：虽然我觉得甩锅不是什么好事，但是如果你真要甩锅，最简单有效就是设置流程去划分责任。上线后有问题其实很正常的，重要的是要有合理的机制：
+
+1. 及时发现问题，监控报警、用户投诉反馈等；
+1. 马上解决问题，对线上版本有专门的代码分支，可以随时打补丁修复，测试上线；
+1. 避免后续再犯同样的错误。要分析原因，看什么导致问题，然后改进流程。
+
+No.10<br>
+**Linuxer**：小公司有很多项目就是一两个人，没有那么多角色，怎么做到按这种流程去开发项目呢?比如常常在代码编写过程中发现很多问题都没考虑全面又感觉在交流需求的时候根本就没想到，要怎么在之后的项目中不再犯这种问题呢？
+
+**宝玉**：即使只有一个人，建议也要做简单的需求分析和设计，做完后，形成简单的文档，找人评审一下，提一些意见。因为你写文档的过程，给别人讲的过程，其实是在帮助你思考，帮助你梳理清楚逻辑，避免在实现的时候发现好多问题没想清楚。
+
+还有一个思路就是快一点迭代，每一个迭代解决优先级最高的问题，然后下一个迭代中改进上一个迭代的问题。项目中犯错误其实很正常的，重要的时候要总结，看看通过什么方式能改进，避免犯类似的错误。
+
+No.11<br>
+**bearlu**：是不是每种模型，有其应用场景，不能只追求最新，要适用才行？
+
+**宝玉**：你说的太对了！举个例子来说，敏捷开发肯定又新又好，但是如果成员没一个懂敏捷开发，强行照葫芦画瓢，可能结果还不如用瀑布模型。
+
+No.12<br>
+**clever_P**：瀑布模型难以快速响应需求变化，那有没有可能通过对业务领域的深入研究，对业务的发展和变化做出一些前瞻性预测，在软件设计的时候将这些预测考虑进去，以此来减小后期需求变化对整个项目的影响呢？
+
+**宝玉**：你说的是一个方向，但是要预测其实是很难的，结果很可能是过度设计，设计了很多可能最终完全用不上的架构，反倒不如快速迭代快速响应来得实际。
+
+No.13<br>
+**一年**：开发一款测试市场反应的产品，使用快速原型模型是不是好点呢？
+
+**宝玉**：恐怕不行，因为快速原型模型是牺牲质量的。质量差的软件，去测试市场，你不知道是因为质量问题不行还是需求没抓住不行。这种情况，可以考虑用迭代模型，先开发核心需求，然后再逐步迭代。
+
+No.14<br>
+**凯纳软件**：感觉自己之前做任何事情都没有章法，觉得只要做了就可以。通篇学完之后，知道自己哪里欠缺，应该怎样去学习及工作。
+
+**宝玉**：谋定而后动。还有一点经验就是：如果你想更有章法，更有大局观，做一件事情前先做个计划，可以帮助你更好的思考，也更容易执行。
+
+No.15<br>
+**Joey**：我们公司是比较大的国企（多个业务部门对一个开发部门），对质量要求较高，现在业务条线也比较多，业务部门基本都嫌我们开发部门效率低，对于我们研发部门，组织架构还是按照瀑布模型设计的，开发模型基本是迭代+增量，如果想推行敏捷，肯定需要调整组织架构，一旦调整，就会触发一些利益关系，在这种背景下，有没有什么好的招数，既可以提高研发效率，又可以保证质量？
+
+**宝玉**：如果你想推行敏捷，可以先找个小项目，组个小团队试点，成了可以作为一个参考，领导可以去邀功，以后可以更大规模尝试；失败了也损失不大，领导也不用担责任。
+
+不管用不用敏捷开发，你都可以学习其中好的实践，例如持续集成用起来，帮助你高效的集成部署；自动化测试代码写起来，帮助你提高项目质量；迭代快起来，以前3个月变成1个月，以前1个月的变2周。有些事情即使只是程序员都是可控范围内的，做着做着其实你就“敏捷”起来了。
+
+No.16<br>
+**一步**：最小可行性产品MVP应该就是迭代开发了？
+
+**宝玉**：MVP更多的是需求定义上的概念，和开发模型并没有关系。但是你使用迭代开发或者敏捷开发，必然要优先选择最核心最重要的功能需求先开发。所以通常MVP的方式选择核心需求，用迭代模型或敏捷开发开发需求。
+
+No.17<br>
+**龙哥**：有依赖交叉的用户故事应该怎么做，比如用户系统的数据库该由谁搭建。毕竟注册、登录、修改这些都可能基于一个数据表。表字段这些需要统一，不能一个程序员改一次字段名吧
+
+**宝玉**：敏捷开发中有一个迭代0，也就是第一个迭代，就是做这些准备工作、基础架构搭建的。敏捷团队小，有个好处就在于遇到你说的这种情况，在做之前，大家都在一起开个小会一商量就可以定下来了。
+
+No.18<br>
+**阿神**：敏捷开发里开发也要写集成测试用例吗，那么测试人员主要做手工测试？
+
+**宝玉**：对，开发不仅要写单元测试，还要写集成测试。但开发都是用模拟数据，假的API。而测试的自动化测试会用真实的数据，调用真实的API，而且也要做一部分手动测试。至于比例多少，还得看项目特点。
+
+No.19<br>
+**holylin**：如果合同金额一开始就是根据商务阶段了解的情况评估的工作量而确定的，那么在合同执行过程中，如果按敏捷开发的思路，客户不断改需求我们不断地响应，然后工作量甚至已经超过了原先合同的金额，这个时候要如何处理？
+
+**宝玉**：这是个好问题，我对这个问题上没有什么经验，但我可以试着帮你分析一下。
+
+你的合同是按照当时的需求签订的，如果后期客户变更需求或者增加新需求，那相当于需要重新签订变更这部分的补充合同。
+
+应用敏捷开发的时候，你也可以让产品经理或者项目经理充当客户的角色，这样他们会更偏重产品需求的解读，而不是重新提出新的需求。还有一点，合同执行的时候，这时候你不需要太过于纠结是不是用敏捷还是迭代还是瀑布，而是哪一种开发模式，可以让你高质量高效率的完成，那就是最好的最适合你的开发模式。
+
+No.20<br>
+**长眉_张永**：作为一个电商ERP服务商，既要关注产品的研发进度，又要对产品做维护。人员一旦离职，发现没有较为详细的文档，就需要去猜测，之前的业务了。敏捷后上线，留下的技术债务应该归谁负责呢？
+
+**宝玉**：敏捷还是要写必要的文档，只是会简化。尤其是这种涉及交接的、维护的，文档不能省。技术债务应该团队成员集体负责，大家在迭代计划会上应该将技术重构列入后续的Sprint。
+
+No.21<br>
+**刘晓林**：敏捷开发这么强调扁平化，这么重视人，这么强调开放而弱化约束，那和最初没有软件工程时期的开发主要区别是啥呀？
+
+**宝玉**：好问题，你难倒我了。前面介绍过，没有软件工程的时候呢，开发就是边写边改模式，没有需求分析、没有架构设计、没有测试，就导致很多问题。
+
+No.22<br>
+**邢爱明**：对于企业管理的软件，核心需求涉及多个部门，需要反复沟通确认周期很长，这种情况下是否还适合使用用户故事的方式做需求分析呢？
+
+另外，我按照瀑布开发模式的习惯分析，开发人员和po沟通需求后，如果没有文档作为输出物，在开发和测试的时候就没有标准，反而会造成工作返工。这是否意味着，团队成员需要高度的协同和配合?以完成任务为导向，而不是强调各自的分工？
+
+**宝玉**：好问题！敏捷开发这种方式，需要客户紧密配合，也就是可以方便确认需求，否则还是少不了要写需求文档。另外我在文章中描述用户故事，有些描写不清楚或者歧义的地方，其实用户故事还应该包括验收标准，这样可以解决你说的开发和测试没有标准的问题。
+
+团队成员需要高度的协同和配合那是一定的，尤其是架构和需求两部分。需求简化后，就意味着开发过程中需要反复沟通确认；没有专门的设计阶段，也就意味着每个Sprint开始前，团队要商量有没有要设计或者修改架构的，有就需要有个简单可行的方案对架构进行修改。如果各自分工，这样的目标就很难达到。
+
+No.23<br>
+**D**：在敏捷开发过程中如何保证业务的传承？当有新同事加进来，如何让他快速的熟悉整个业务。
+
+**宝玉**：这个是个好问题，也是个大问题！通常我的经验是：
+
+1. 团队要有自己的知识库或WIKI，常用的知识要花时间整理上去，这样新人来了可以自己查；
+1. 先给他简单的任务，再慢慢稍微复杂一点，给予必要的指导，做中学是最快速有效的；
+<li>遇到一些典型的问题可以通过结对编程的方式带着一起做。<br>
+仅供参考。</li>
+
+No.24<br>
+**dancer**：对比瀑布模型来说，敏捷开发在需求分析和软件设计上要薄弱一些，这会导致越向后迭代，软件越难以变更和维护，请问老师有什么好的方法和建议吗？
+
+**宝玉**：需求分析是在Sprint进行中同步进行，也就是开发具体的用户故事之前要和客户或产品经理充分沟通了解需求。如果用户故事不是特别大，这并不是很大的问题。另外并非只能用用户故事，也可以用传统的产品设计文档代替用户故事，也一样是很不错的实践。
+
+对于架构设计，架构只设计当前迭代的，所以迭代到一定阶段，是要考虑重构的。通常重构代码也是Sprint的工作任务的一部分。
+
+No.25<br>
+**Dora**：瀑布对人员要求不高(各自负责各自的工作，比如需求只管需求)，而敏捷流程，一个人什么都要过一遍。这样理解，对吗？
+
+**宝玉**：瀑布对人员也不说要求不高，但分工确实更细一点，比如像你说的，需求只管需求；开发一般就不操心怎么测试，写完等着测试报bug；敏捷开发里面，分工没那么细，需求不仅要写需求文档或者用户故事，还要和团队成员紧密合作，及时讲解需求；开发也要自己写很多自动化测试代码；敏捷团队也不是没有测试，但是会用自动化测试分担一部分测试任务。
+
+No.26<br>
+**Tiger**：在敏捷里面，开发写自动化脚本测试，那是不是就不需要测试这个角色了啊？感觉在敏捷里面，只需要开发这一个角色就可以了啊？
+
+**宝玉**：在《[07|大厂都在用哪些敏捷方法？（下）](http://time.geekbang.org/column/article/85018)》我有谈到这个问题。自动化测试是辅助的，还是离不开人工的测试。而且开发写的集成测试和测试写的自动化测试还是有一点差别的，一个是用程序模拟操作的固定数据，而测试用的是真实的数据环境。举个例子来说，网页的自动化测试，开发只会用Chrome Headless，数据都是事先写好的模拟数据；测试的话会用主流的Chrome、Safari、Firefox、Edge分别测试（自动化或手动），数据都是测试环境的真实数据。
+
+No.27<br>
+**一路向北**：对于小公司小团队的项目，因为项目经理，产品经理都是身兼数职，是否有更好的实施方式呢？
+
+**宝玉**：项目经理、产品经理兼多个项目是正常的，也没大问题。但是让程序员同时兼做开发和项目经理工作就很不好，因为项目经理需要更多全局掌控，而一旦要花精力在开发上，很难跳出具体的开发工作，会极大影响项目管理工作；项目管理工作也会频繁打断开发，造成进度延迟。
+
+所以我建议应该有专职的项目经理，不应该让程序员兼职项目管理。新旧项目交织并不是问题，可以放在一个项目一个Sprint里面一起管理，也就是同一个Sprint里面有维护的Ticket，也有新需求的Ticket，只要保证开发人员同一时间只是做一件事，而不要几件事并行，就可以最大化发挥敏捷优势。
+
+No.28<br>
+**天之大舒**：怎样培养团队成员？
+
+**宝玉**：有一些建议仅供参考：
+
+1. 招人和开人都很重要，招优秀的，开掉没有责任心，没能力的。这两点都不容易做到，不过得坚持做；
+1. 设置合理的流程，配合一定的奖惩制度；你奖励什么，团队就会往哪方面发展；
+1. 团队要有梯队，不能都是资历浅的也不能都是资深的，保持一个合适的比例是比较健康的；
+1. 实战中锻炼，实战中磨合；给他们有挑战的任务，给予合适的指导（这就是有梯队的原因，需要高一级别的待低一级别的）。
+
+No.29<br>
+**星星童鞋**：请问老师，对于需求更新极快，基本上每周都需要迭代更新上线的项目，在架构设计和项目部署上会不会有什么特殊的要求？
+
+**宝玉**：架构设计上，一定要定期需要重构，优化设计，不然后续新需求效率会降低，包括代码上也会越来越臃肿。比如我现在所在项目组，每1-2年会有一次大的架构升级调整，日常每隔几周会有小的架构优化，这样基本上可以保证快速迭代不会受太大影响。
+
+部署的话，一个是要自动化，可以快速方便的部署，另外一个部署后，需要有配套的数据监控和高于阈值报警的机制，因为上线后可能会有严重问题，需要及时发现，及时处理。
+
+No.30<br>
+**alva_xu**：如果一个迭代里没有评审会，怎么知道我上线的系统是符合要求的？
+
+**宝玉**：没有评审会，但是有专职测试针对最初提的需求进行测试，另外产品经理也会验收，如果验收不合格会提交Ticket。也就是说是有验收，只是没有专门的会议。
+
+## 精选留言
+
+阿杜：<br>
+软件过程不是搞科研，不是搞艺术，而是解决多人合作将一个想法落地的学科，其中包括严谨的过程步骤、规范，用于提高效率或防范风险的工具。软件工程的主体是工程，这就要求我们具备基本的工程思维：模块化思维、抽象思维；具备一些关键的意识：质量意识、风险意识、交付意识。
+
+相关阅读：[01 | 到底应该怎样理解软件工程？](http://time.geekbang.org/column/article/82848)
+
+alva_xu：<br>
+对于大型系统的建设，可否用敏捷方法来实现，一直是个问题。<br>
+敏捷方法，适合于小团队（比如两个披萨团队）、小架构。对于大型单体应用的开发，至少在架构设计上是不适合用敏捷迭代方式的。
+
+为了解决大型系统建设的迭代开发、快速交付问题，业内不断在探索。随着微服务架构的提出，以及容器技术的成熟，和cicd的实现，单体巨石应用被拆解成分布式的微服务应用，此时，敏捷方法也就开始真正大行其到了。
+
+所以，微服务、容器、devops这三剑客和敏捷方法一起，互为依存、互相促进，成为了软件工程中最有生命力的技术工具和流程，使软件开发在质量和效率上得到极大提升。
+
+相关阅读：[01 | 到底应该怎样理解软件工程？](http://time.geekbang.org/column/article/82848)
+
+老张：<br>
+在今天没有不可替代的硬件，却有无数不可替代的软件。硬件早已不是共享的壁垒，而曾经被认为有很强可塑性的却已经是最硬的壁垒。一台服务器、一块磁盘、一根内存以及交换机、防火墙等网络设备，更遑论鼠标、键盘、显示器，在冗余、复用、虚拟化等等技术之下，更换、替代、扩容如此之方便，经过简单培训的工人就可以轻松完成。
+
+可是即便是美国国会图书馆，依然认为纸质是保存资料最好的方式，因为大量资料电子化后存放在不同介质，需要当时定制的软件才能读取这些格式。今天的软件就是这么硬。也许有一天，有人会写写如何开发真正的软件。
+
+相关阅读：[01 | 到底应该怎样理解软件工程？](http://time.geekbang.org/column/article/82848)
+
+阿银：<br>
+软件工程的本质在于工程。利用工程理论来保证高质量软件产品的产出。工程讲究效率，成本，质量，除此之外，容易忽略的是工作量与效益的权衡，这一点尤为关键。
+
+相关阅读：[01 | 到底应该怎样理解软件工程？](http://time.geekbang.org/column/article/82848)
+
+hyeebeen：<br>
+软件工程的产生源自于对高效产出可靠稳定的软件产品的需求，在各种“+”的现实生活中，不掌握合格的软件工程管理技巧，日常的项目工作会很容易有瓶颈。
+
+学习对应的工程技巧，内化为自身素质，在项目过程中既能预防工程风险，也能建设面对风险的反应机制。这种人，各个企业都喜欢。
+
+相关阅读：[01 | 到底应该怎样理解软件工程？](http://time.geekbang.org/column/article/82848)
+
+阿杜：<br>
+1.做任何事情都要按照一定的理论指导来，例如，依靠系统化、结构化的“工程思维”，将生活和工作中的每个事情都看做一个项目，可以提高做事的成功率和效率，虽然不用这些理论指导也能做成事情，但是相对来说是偶然性的，不是常规性的。这就是常说的认知（意识）先行，持有高级的认知去跟低认知的人竞争，是一种降维打击。
+
+2.工程思维的核心有两点：系统化，也就是全局观，要从站在整个项目的高度去看问题，不能做井底之蛙；结构化，也就是有步骤、有节奏得做事情的意识。
+
+3.《软件工程之美》这个专栏，我给自己定了一个小目标：全部跟完，并且坚持留言跟老师交流想法。我制定了简单的阅读步骤：（1）文章至少阅读两次，第一次通读，第二次做笔记摘抄、整理文章的思维导图、提出自己的想法；（2）整理自己的学习心得，形成阅读笔记发到自己的博客（公众号）上。
+
+4.课后思考：我今年年初开始运营自己的公众号，我把它当做一个项目，就从下面几个方面进行了思考：我要提供的内容和定位是什么样的、我的用户是谁、我应该如何去运营；这些东西想好后，我就将要做的事情拆分为：公众号设置、文章内容输出、运营推广三块，然后按照一定的步骤去执行，现在公众号的设置已经基本完成，整个项目进入内容输出和运营推广的循环中了。站在项目的角度去看这个问题，可以让我在动手执行的时候更有方向感和节奏感，也会对自己清楚自己某个小的点做的改动会对全局产生什么影响；在没有使用这个角度去看问题之前，我只是简单得主张内容才是核心，但是不懂运营和推广，没什么章法。
+
+相关阅读：[02 | 工程思维：把每件事都当作一个项目来推进](http://time.geekbang.org/column/article/83277)
+
+起而行：<br>
+项目思维的两个关键在于：
+
+- 注意局部任务与总体时间的关系；
+- 用熟悉的办法解决问题。
+
+以留学为例。
+
+1.在距离留学申请还有两年的时间，可以先做不确定性强，见效慢的事情，不是不重要，而且短时间内会来不及。比如未来职业规划，兴趣的培养，长期的科研与项目。
+
+等到了申请还有半年的时候 要注意局部的任务与总体时间的关系。那么确定性不强的任务效果将不会特别好，而刷语言考试的成绩，这种确定性强，时间可控，反馈见效相对快的事情就要提上日程。
+
+2.用熟悉的办法解决问题。在留学，这种高度信息不对称的领域，可以自己试着了解前人经验，但我认为，专业的事情给专业的人去做，那么找中介辅助申请就是个好的主意。
+
+相关阅读：[02 | 工程思维：把每件事都当作一个项目来推进](http://http://time.geekbang.org/column/article/83277)
+
+alva_xu：<br>
+工程方法就是有目的、有计划、有步骤地解决问题的方法，而工程思维就是用工程方法解决问题的思维模式。这种思维模式，首先要求有全局观。
+
+而事实上，由于工程中的不同职责分工，导致各个角色有可能只从自己的分工角度去考虑问题，这实际上是软件工程中最大的障碍，也是传统的CMMI（过程域的规范化）、现在的DevOps和敏捷方法想要去解决的问题。
+
+正如《凤凰项目》中的观点，既要有自左向右的工作流，又要有自右向左的反馈流。通过人员和组织（自组织）的调整、工具和技术（CICD工具）的使用以及流程（Scrum等敏捷工作流程）的推广，确保整个工程项目不会被不同角色割裂开来，从而确保工程的实现。
+
+相关阅读：[02 | 工程思维：把每件事都当作一个项目来推进](http://time.geekbang.org/column/article/83277)
+
+纯洁的憎恶：<br>
+工程方法不仅给团队提供了一系列成熟的理论范式与实践工具，提高效率与成功率。更重要的是把团队的视角“强行”抬到全局高度，避免我们紧盯着自己关心局部问题，更好的统一思想、形成合力。
+
+相关阅读：[02 | 工程思维：把每件事都当作一个项目来推进](http://http://time.geekbang.org/column/article/83277)
+
+hyeebeen：<br>
+非常赞同“一切即项目”的思考模式，作者经历的培训活动我也经历过，确实在时间意识上会比没受过工程训练的人强一些，更注意过程控制。
+
+ps：学习自动化测试其实不等于一定能缩短测试周期，“测试周期”的定义如果是测试独占的项目时间段的话，可以通过测试前移，加强自测，契约优先的接口自动化测试等来缩短独占时间。没有系统或者不够工程化的自动化测试脚本，反而会增加测试时间。
+
+相关阅读：[02 | 工程思维：把每件事都当作一个项目来推进](http://time.geekbang.org/column/article/83277)
+
+纯洁的憎恶：<br>
+我对瀑布模型感触颇多啊！
+
+- 瀑布模型把复杂的软件生产过程，按照时间线索，切分为若干较为独立和专业的部分，条理清晰。
+- 在每个阶段内只需要集中精力于阶段任务即可，不用胡子眉毛一把抓。
+- 每个节点有交付件，过程可控、权责清楚明白。
+
+瀑布模型特别符合我所在的大型央企的性格。但是我经手好几个项目，也被瀑布模型折腾的死去活来。比如我现在正在处理的项目。
+
+首先，从可行性分析、立项、批预算、采购建设单位就花了一年多的时间。可行性分析做了1个月，立项流程走了不到1个月，批预算的时候，主管业务的领导变卦了，要求重新做可行性分析，于是我们又花了1个月。
+
+二次立项的时候，主管信息的大领导突然决定要把区块链和人工智能等热门技术加进去，于是又要求重新立项。但是我们要做的事情实在和区块链八竿子打不着，死去活来的找了个理由扯上关系了，来来回回又花了2个月，这就半年了。
+
+再次走到批预算的环节，主管领导发现原来的预算干不了这么多事情，又不同意增补预算，于是继续扯皮。经过多番协调，总算解决了，这时候叶子已经黄了。
+
+我们立刻开展需求调研，但各个需求部门和最终用户都借口工作太忙不搭理我们，我们只好自己憋需求，简直是闭门造车。等需求憋出来了，大领导把需求部门都叫来议一议，结果被集体口诛笔伐。
+
+大领导怒了，强令需求部门专门抽时间参与需求调研，各部门也是不情不愿啊，效果可想而知。需求总算审查通过了，就在我们准备采购实施单位的时候，国资委红头文件一直下来，公司的采购流程发生重大调整，项目被硬生生搁置下来。眼看年根了。
+
+第一年就这么过去了。等来年采购流程也理顺的差不多了，预算又出问题了。去年批的预算只能去年用，不允许跨年。只好等到年中调整预算，又小半年过去了。采购流程走完，实施单位也很够意思，不等合同签订就投入工作。我们用极短的时间完成了软件设计，并且开始如火如荼的开发工作，此时又到了金秋。
+
+就在这时，新的纪检书记上任了，他对我们的系统设计很不满意，要求相关部门限期整改，于是需求大调整，可是这会儿编码已经进行了1/3啦…之后就是上线日期一推再推，从10月初推到10月底，再推到11月、12月，眼看又要跨年了。我们和实施单位连续半年997，总算看到上线的曙光，这时候公司一把手退休了…
+
+新领导上任后对整个流程极不满意，否定了纪检书记的指示，于是我们又开始第2伦大调整。现在已经是项目的第三年了，我们依旧没能上线。整个团队都要累趴下了，全公司一点成果也没看见。
+
+相关阅读：[03 | 瀑布模型：像工厂流水线一样把软件开发分层化](http://time.geekbang.org/column/article/83598)
+
+纯洁的憎恶：<br>
+稳定、可靠、一步到位的瀑布模型，不太适用于违约风险大、需求不明确、快速见效的场景。
+
+**快速原型模型：不见兔子不撒鹰。**期初不考虑质量、架构，用最快的速度见效，并向用户确认需求。经过几轮直观、快速的反馈，把需求确定下来。接下来，既可以抛弃原型用瀑布精密重构，也可以在模型基础上完善。优点是快速有效地确认需求。不足难以有效应对后续的需求变更。
+
+**增量模型：分而治之。**将大系统横向拆分成相对独立的若干小模块，每个模块采用瀑布模式分批次交付。优点是较快见到成果，且能够及时了解项目进展。不足是存在需求明确、系统可拆分、交付可分批等适用条件。
+
+**迭代模型：罗马不是一天建成。**把软件项目纵向划分成若干阶段，从核心功能入手，逐渐深化、细化，直到满足用户的全部需求。每个阶段都是一个瀑布，都要在前一阶段成果基础上加工、打磨。优点是快速满足基本需要，并体会软件演进的快感。不足是需求演化具有不确定性，会导致代码冗余、系统重构风险、项目周期不可控。
+
+我做甲方管过不少外包项目，大V模型再熟悉不过了。整个过程冗长繁琐，走流程比建软件更累心。而且等项目结束的时候，需求早就变得面目全非了。乙方只能硬着头皮做，不然连业绩都没有，真是血本无归。在增量或迭代模型的每次交付后都做一次风险评估，演进为螺旋模型，可以及时止损。
+
+项目做成这样，更深远的原因是业务都是在摸着石头过河，需求不变更才怪呢。但每年几个亿的信息化预算还是非常诱人的，投标单位络绎不绝。RUB看起来不错，但需求快速演化会依然带来无法回避的系统重构压力，终归还要具体问题具体分析。
+
+相关阅读：[04 | 瀑布模型之外，还有哪些开发模型？](http://time.geekbang.org/column/article/84054)
+
+西西弗与卡夫卡：<br>
+当前不够明确、后期可能有较大变化的需求，准确说首先要考虑的不是用哪种开发方法，而是最好避免一开始就投入开发资源。开发的代价非常高，推倒重新开发的代价更高。最好是先想别的办法，验证需求是否真实存在之后再动手写代码。
+
+相关阅读：[04 | 瀑布模型之外，还有哪些开发模型？](http://time.geekbang.org/column/article/84054)
+
+alva_xu：<br>
+对于增量或迭代开发，大型企业需要考虑这些不适应点：
+
+- 大型官僚机构的办事程序和敏捷过程不匹配。比如开发想敏捷，但财务采购等都不敏捷。代码敏捷了，基础环境不敏捷等。
+- 伴随增量的添加，系统结构会逐渐退化。特别是对于大型系统，其系统结构的建设，就需要提前制定计划，而不是增量开发。
+- 与开发方的合同问题，需要新形式的合同。旧形式的合同是固定合同，做多少事拿多少钱都在合同时谈好了，不适应工作量的变更。
+
+相关阅读：[04 | 瀑布模型之外，还有哪些开发模型？](http://time.geekbang.org/column/article/84054)
+
+纯洁的憎恶：<br>
+流程、工具、文档、合同、计划都是工业化的标志。它们带来了稳定的质量、惊人的效率、超大规模的协作，对于软件工业也是如此。
+
+然而软件工业具备轻资产、知识密集型、从业人员素质高等特点，充分发挥人的创造力和价值，是其相较传统工业更高阶的要求。加之软件工程面对的不确定性与复杂度更显著。于是“个体和互动高于流程和工具，工作的软件高于详尽的文档，客户合作高于合同谈判，响应变化高于遵循计划”的敏捷思想应运而生。
+
+通过用户故事，理解用户需求；在迭代中采用渐进的架构设计；定期重构解决技术债务；功能开发的同时编写自动测试代码；自动化持续构建。
+
+由于淡化了部分工业思维中兼顾稳定、质量、效率、成本的传统手段，敏捷思想的最终落地，需要素质极高的从业人员参与其中，且数量不宜过多，以此来弥补流程上的缺失。同时要团队与客户紧密协作，上级的充分信任，才能够有效发挥其灵活应变，又万变不离其宗的优势。
+
+这是大胆的返璞归真，好似回到了瀑布模型前的蛮荒时代，实则是更高级的打法，就像独孤九剑一般。所以，敏捷开发“道”的属性更浓。
+
+敏捷开发具有快速迭代、持续集成、拥抱变化等诱人的特点，但也有苛刻的条件要求。不过，即使无法推行完整的敏捷开发，依旧可以在传统模式下，有针对性的应用敏捷开发的实践方法。
+
+相关阅读：[05 | 敏捷开发打底是想解决什么问题？](http://time.geekbang.org/column/article/84351)
+
+alva_xu：<br>
+我们现在着手的一个项目，是一个软件框架建设项目，外包给供应商做的。在签合同时，基本需求已经梳理得差不多了。所以按理是可以采用瀑布式开发来进行的。但由于以下原因，所以我们结合了增量开发和Scrum项目管理的模式进行系统建设。
+
+1. 基本需求是可以分模块来实现的。
+1. 我们这个项目所依赖的其他部门提供的基础平台也不是一次性可以交付我们使用的。
+1. 我们的使用方(另外一个应用项目）对我们项目的时间要求很急，但可以接受我们分批次交付的模块。
+
+基于以上原因，我们设立了几个大的增量阶段，每个增量阶段我们有分几个sprint来进行开发管理。到目前为止，进展还比较顺利。
+
+但由于我们这个框架建设项目的外部干系人比较多，所以在协调上游平台和下游应用系统的时候，确实遇到了许多沟通方面的问题。由于其他项目没有进行看板管理，所以需要进行例会形式的沟通来确保关键节点的功能实现。
+
+所以，我认为，开发模式和项目管理模式不可以拘泥于一种形式，关键还是要看是否真正达到了整体的敏捷和精益。对于文中老师提及的scrum管理和极限开发，确实是小团队内部协同作战的比较好的实践。但对于多团队协同作战，就要考虑综合运用各种方法了。
+
+另外，对于文中提及的站会形式，从“道”的角度来说，当然是可以视实际需求来确定是否要开，但往往一种文化的培养，需要有仪式感，需要不断锻炼。所以对于我们来说，我们还是坚持开Scrum中要求的四个重要会议。
+
+相关阅读：[05 | 敏捷开发打底是想解决什么问题？](http://time.geekbang.org/column/article/84351)
+
+纯洁的憎恶：<br>
+分治策略是应对庞大复杂系统的惯用思路，但它的难点或精髓在于如何确保形散神聚。
+
+- 详细计划（甘特图）VS 任务状态（Ticket）。
+- 代码不稳定&amp;环境部署麻烦  VS  代码审查&amp;自动测试&amp;自动部署（GIT、CI、DevOps）。
+- 上传下达 VS 频繁沟通、提醒、分享。
+
+大厂的敏捷开发实践，把枯燥的编码变得跟玩游戏一样。借助有效的流程与工具，能够有效节约团队成员的精力，聚焦于任务或角色，不会因频繁“统一思想”导致“技术动作变形”。
+
+而另一面，在大厂里每个人通常都是螺丝钉，长此以往也许会养成不谋全局的习惯。如果能从自己的角色中跳出来，俯瞰整个组织协作的全过程，并站在这个视角上思考问题，一定会有更喜人的收获。
+
+相关阅读：[06 | 大厂都在用哪些敏捷方法？（上）](http://time.geekbang.org/column/article/84652)
+
+alva_xu：<br>
+在一个以Scrum 为方法的敏捷团队里，首先，Scrum master是呵护develop team的保护神，他的其中一个职责是保护每一次迭代的工作量是dev team能按时完成的，而且保护dev team 能专注于现有sprint back log的实现，不会被其他干系人的新需求所打断。
+
+其次，Dev team是一个T型团队，技术比较全面，许多事情多能自助搞定，比如，开发人员同时又有测试技能，同时如果结合结对开发，测试驱动开发，那么，交付物的质量就更有保障。
+
+再者，在一个敏捷团队里，人数比较少，dev team的沟通能力都比较强，沟通可以比较充分，所以解决问题的能力就比较强，工作效率比较高
+
+最后，敏捷模式的开展，也依赖于工具的使用，目前常用的CICD工具，与jira/confluence 需求沟通管理工具的打通，部署次数的提高，无疑大大提高了开发发布效率，同时也提高了发布质量。
+
+综上所述，只要在人员组织架构、工具产品、流程这三个方面都达到了敏捷的要求，那么发布质量就有了保证。
+
+相关阅读：[06 | 大厂都在用哪些敏捷方法？（上）](http://time.geekbang.org/column/article/84652)
+
+Felix：<br>
+Git方面也要求团队Master中的代码必须通过Merge Request(Pull Request)来，也作为Code Review的最后一道关卡。持续集成方面大部分通过Jenkins、几个微服务是通过Gitlab CI，我们的终极目标是基于镜像部署发布，屏蔽环境影响。
+
+相关阅读：[06 | 大厂都在用哪些敏捷方法？（上）](http://time.geekbang.org/column/article/84652)
+
+alva_xu：<br>
+我觉得在计划会上，有几个事情必须要做好.
+
+第一是需要定义DOR和DOD，Define of Ready 和Define of Done,如果没有这两个定义，那么扑克牌可能会玩不起来。
+
+第二 需求（用户故事分解成的task)一定要尽量明确。不管扑克估算还是其他估算方式，如果第一轮估算偏差过大，说明大家对需求不明确，需要产品经理进行更详细的说明。通过几轮估算，如果大家能达成比较一致的估算，那么工作量的估算就比较靠谱了，这也是Scrum这种工作方法带来的好处，能让需求得到合理的资源安排。
+
+不管怎么说，在Scrum里，要重视估算，有了好的估算，速率才真正有意义，才能真正保证交付质量。
+
+相关阅读：[07 | 大厂都在用哪些敏捷方法？（下）](http://time.geekbang.org/column/article/85018)
+
+纯洁的憎恶：<br>
+“多、快、好、省”，软件工程的四难选择问题。由于质量是软件工程压倒一切的要素，因此“好”必须留在“盘子”里。剩下的要素都是可以根据具体情况权衡取舍的。四难选择变成了三难选择。于是，工程师在实践中面对不确定时，也能够有底气做到“不抵触，讲条件”了。
+
+延长时间的另一面是提高效率。借助工具、优化流程、节约资源等方法，可以在一定程度上“冲销掉”延长的时间。
+
+非常欣赏MVP模型，既可以快速见效，又降低了大量返工的可能。在瀑布模型中，通过会有过度设计的现象。一开始想了很多，结果发现恨不能80%都是瞎想。先拿出核心功能，再根据用户使用的情况，有指向性的完善，步步迭代演进，十分靠谱。
+
+唯一令人担忧的是，在外包模式中，如果没有明确的需求，就难以估算出较为准确、合理的预算，进而无法立项、采购。如果先做一版需求申请下来预算再说，再用MVP模型步步试探。那么最后做出来的东西可能与需求文档严重不一致，存在较大的审计、内控风险。也许企业大了、规矩多了，做起事来确实别扭。
+
+作者回复：迭代模型和MVP是非常好的组合，因为迭代的时候，会优先选取最重要的功能，慢慢的那些不重要的功能甚至永远不会被加入迭代中，就因为不需要浪费时间在上面了
+
+相关阅读：[08 | 怎样平衡软件质量与时间成本范围的关系？](http://time.geekbang.org/column/article/85302)
+
+alva_xu：<br>
+传统的大企业（不是指BAT这类大企业），比如我们企业，IT项目牵涉到三个部门，一个是业务需求部门，一个是IT部门，一个是财务预算审批部门，采取的形式一般都是采用外包方式，而且往往是固定合同，也就是合同价格是确定的，需求范围也是确定的，这样的话，金三角的两条边就定下来了，剩下来的就是时间和质量的关系问题了。
+
+按照金三角的理论，我们就可以知道前面所述的场景下项目组该重点抓什么了：作为甲方项目经理，重点抓的就是质量和时间了。如何通过提高效率，使单位时间的产出比原来的多（相当于增加了时间），来提高项目的交付质量，是我们甲方IT项目经理最关心的事。
+
+所以这时候，我们的方法是建立统一软件框架、提供公共服务组件、制定代码和测试规范、培训乙方团队、搭建CICD平台和自动化测试平台、sonarqube自动代码检测平台等，使原来几周一次测试变成一周几次测试，使原来低质量的代码快速变成高质量的代码…
+
+反正是采用各种方法，提高工作效率，用于抵消业务部门不时提出的变更导致的项目进度的风险。当然在开发模式上，也会衡量敏捷的开发模式（特别是scrum的管理模式）和传统瀑布及衍生模式哪种模式更高效。
+
+当然，理解了金三角，对于前期申请项目预算也是有帮助的，比如，可以和预算部门谈判，如果要砍预算，在时间一定的情况下，就只能减少项目范围，这是我们业务需求部门所不能接受的。这样，就可以使IT项目经理名正言顺地把预算部门和IT部门的矛盾转嫁到预算部门和业务需求部门去。
+
+当然，最合理的做法应该是向BAT公司看齐，IT部门转变为利润中心，自己管预算、自己有开发团队，那么金三角的三条边就都可以进行调优了。
+
+相关阅读：[08 | 怎样平衡软件质量与时间成本范围的关系？](http://time.geekbang.org/column/article/85302)
+
+## 最佳思辨
+
+林云：<br>
+文中提出可以借鉴软件开发模型中的特点，这一点并不是普通软件开发成员可以使用的。任何一个软件开发模式都有对应的主要问题。就像你把飞机的引擎放在拖拉机上一样。需要对模型进行总体考虑。而且不同的软件开发模式都有对交付团队有能力的要求。
+
+举个不恰当的例子，组合软件开发模式的特点就像让一个摩托车驾驶员开着安装了飞机引擎的拖拉机。这并不是软件工程想达到的结果。希望作者对组合研发模式的前提和应用过程进行描述，以减少软件工程方法使用的随意性。
+
+宝玉：<br>
+谢谢指正，结合最近波音747Max的案例，确实不能乱用，不能说飞机的软件也用敏捷这种快速上线快速迭代的模式。我觉得组合研发模式的前提还是质量，软件工程的目标就是要构建和维护高质量的软件，无论怎么组合开发模式，都不能牺牲质量。
+
+这里我也列一些我觉得好的实践：
+
+1. 瀑布模型可以参考敏捷开发，引入持续集成、自动化测试，提升效率；
+1. 敏捷开发可以参考瀑布模型，开发前多设计，开发后多测试，尤其是要辅助人工测试。
+
+相关阅读：[04 | 瀑布模型之外，还有哪些开发模型？](http://time.geekbang.org/column/article/84054)
+
+好，今天的加餐就到这里，非常感谢同学们用心的留言，也希望我们专栏的同学都能每日精进，学有所成！
+
+感谢阅读，如果你觉得这篇文章对你有一些启发，也欢迎把它分享给你的朋友。