从去年我一直设想能够在公司的整个开发部门有机会在成型开发团队尝试中小范围的敏捷开发.这个想法其实也是由来已久.或者是说源自于自己在工作中深受传统瀑布开发模型一些弊端的切身感受.

作为一个软件工程师不断重复努力开发出高质量的软件.希望我们的用户能够使用到无Bug最佳的应用程序和良好的用户体验.而构建一个稳定可靠的软件是在软件开发流程中其实一件很困难的工作.而仅仅吧软件质量的责任归咎于程序员是不公平的. 软件开发流程是需要来自不同领域人或Team参与一个过程. 而软件质量在这个整个开发流程也是息息相关的.

针对开发流程.业界早已衍生出一些相对成熟. 可控. 能够预估软件开发模型. 本篇你能够了解如下两个方面内容: A:如果你是一个开发人员.还停留传统瀑布开发模型中.想了解软件开发的敏捷方法? B:软件质量控制在传统瀑布开发模型与敏捷方法不同之处,有何优劣?

软件开发流程是一个很大的命题.所以本篇我不会对此进行泛泛而谈.我要说的所有内容都会围绕着，如何在传统瀑布开发和敏捷开发方法之间进行软件质量控制? 二者有何差异和不同? 两个问题展开.

瀑布[Waterfall Model]开发方法.相信对于大多数开发人员来说都是很熟悉的.可能很多人和Team现在依然还停留在这个开发方法中进行日常开发工作. 瀑布方法是由Winston W.Royce 博士在1970年代发表的一篇论文中“管理大型软件系统开发[]”提出的.很多人都认为瀑布开发方法都是源之于这篇论文. 其实如果你仔细的阅读这篇论文.你会发现在最初的文章中，Royce提倡重复地使用瀑布模型，以一种迭代的方式. Royce实际在论文中试图拿这种Waterfall Model开发方法来论证说明这种开发模式是存在缺陷的.而且可能导致项目失败. 而Royce没有料到的是Waterfall Model却意外的成为业界大多数软件开发的最早标准.

瀑布模型[Waterfall Model]最早强调系统开发应有完整生命周期，且必须完整的经历周期中每一开发阶段，并系统化的考量分析与设计的技术、时间与资源之投入等，因此瀑布模型又可以称为‘系统发展生命周期’[System Development Life Cycle, SDLC]。由于该模式强调系统开发过程需有完整的规划、分析、设计、测试及文件等管理与控制，因此能有效的确保系统品质

Waterfall Model瀑布开发模型强调的是软件开发周期中每一个阶段都是线性的向下进行的:

至于这个流程相信很多开发人员已经是非常熟悉了.但在实际开发流程瀑布模型存在哪些问题、>?

首先第一点不得不说的就是在瀑布模型每个步骤都必须要按照顺序执行.直到整个软件开发周期完成. 最关键的是每个阶段在完成之前不能开始下一个阶段. 每一步的执行则是完全依赖于上一个阶段. 另外相信很多人会说在瀑布模型里说明问题是需要文档来记录的. 而且文档在这个过程每个阶段都需要详细文档来维系.

很多人会问 如何在瀑布模型中保证软件质量?>

相信很多在实际项目中完整执行过该流程开发人员。应该清楚我们确定需求需要做持续做在文档做出软件概要设计和详细设计. 其实瀑布模型这样做要求在设计分析阶段尽可能多发现纰漏. 才能在开发阶段避免错误. 这有什么问题呢?

相信很多人发现.这种要求在设计分析阶段就能发现整个软件开发周期要发现所有可能出现的问题. 基本是不可能的. 而很多关键的细节如果不到具体的实现阶段是不可能发现的.

而由于这个模型.强制要求在编码开始之前要冻结规范文档. 也就是说很难在发布阶段将早起用户以及测试反馈的问题包含进来. 这样一来就降低开发团队响应客户需求的能力. 特别在发布周期要求比较高时.开发团队不能持续想客户交付有效功能点.

至于测试则是整个编码结束后拖到整个开发周期的最后. 这就是集成化测试的开始阶段.为交付有效功能点和软件质量照成一定风险.

其实对用瀑布模型这种臃肿不堪.要求严格.而无法适应软件开发周期变化开发模型.业界渐渐可是兴起向更轻型的软件开发方法演化。在90年代时提出好几种轻型方法.强调专注于软件自我管理的团队. 提倡面对面的交流. 轻型文档和迭代发布等概念.

敏捷方法是试图通过小型的. 自我管理的团队用短小的合作发布周期来鼓励迭代式软件开发方法.软件的质量贯穿敏捷软件开发每一个阶段.且非常重要.,并提出很多关键的规则[例如: 结对编程. Test Driver Development测试驱动开发.,重构和持续集成]来保证能在每一个迭代周期内及早是的发现并及时相应消灭开发过程中出现错误.

Scrum大概是目前敏捷方法里面最出名. 至少也是各位实行听说敏捷方法最熟悉一个.

其实冲本质上来说Scrum本身并不是所谓方法论.而是一组实践和为其过程参与者制定角色框架.其实它和其他敏捷方法是殊途同归.Scrum鼓励小型的,自我管理的团队在短的开发周期完成一系列定义良好的开发任务.

Scrum虽然提供了一个很有价值的框架. 但实际上和XP TDD不同的是它并没有定义明确可行的方法来管理开发出来的软件的质量.但其实这没有问题.Scrum的做法只是这个工作下放到Scrum团队每一个人.让开发团队自己决定选择实现什么样的质量控制实践.

在这一点上和XP TDD提出关注项目的框架.Scrum则淡化这一部分.而是更多对管理代码质量做出很多实践规定.

Scrum周期如何执行的?

每一个Scrum项目周期都被看做一个Sprint.它用来标识完成一组功能开发所需要的时间.Sprint即从Scrum团队打算把精力放在一组功能上开始.而这组功能是由Scrum团队在源自于Product Backlog的计划阶段期间选择的. Produc Backlog其实是指一张关于软件开发所有可能功能点优先级列表.

其中在计划阶段的末尾.所有从Product Backlog里选出来的功能都会被加入Sprint Backlog里执行跟踪.Sprint Backlog表示团队要开发的具体功能的细节.或者就是需求表现出来的功能点.一旦Sprint Backlog定义完成整个Sprint周期就开始.

通畅在一个Sprint周期会持续30天.在Sprint期间团队成员会聚在一起检查工作进展并帮助每一个队员保持工作效率.而在这个Sprint末尾。在Sprint Backlog里定义的功能点将全部完成并可用.

而这个过程就如上图.Scrum优缺点在那?

Scrum相对传统瀑布模型.在构建真个开发活动前.思考并记录下来真个流程.,按照具体的计划实施，保持各项事务尽可能的有组织性.另外可以从整个Sprint周期来看到.Scrum模型的一个显著特点就是响应变化，它能够尽快地响应变化.使用传统的软件开发模型(瀑布模型、螺旋模型或迭代模型)。随着系统因素（内部和外部因素）的复杂度增加，项目成功的可能性就迅速降低:

Scrum模型和传统模型的对比:

Programming，极限编程）不同，Scrum并没有提供核心的价值观与指导原则，也缺乏具体的实践方法，例如结队编程、测试驱动开发。Scrum仅仅规定了实施的基本流程与检查表，它是一个开放的管理框架，重心在于项目管理，而不是指导团队成员如何进行开发。它很灵活，能够适应大多数场景，也可以兼容并包地引入其他方法学所提倡的实践.这既是Scrum的优点.

但在实际执行中也存在缺陷缺陷，使得它难以被实践。如果没有一位优秀的Scrum Master，而团队成员又缺乏自我组织和管理的能力，就会让开发过程变得混乱无法达到预期效果.

Scrum的核心在于迭代。团队首先浏览开发需求，考虑可用技术，并对自身技术及能力做出评估。然后共同确定构建功能的方案，并每日调整方法，以应对新的复杂问题、困难和出乎意料的情况。团队找出并选择最佳方案去完成任务。此创造性过程便是Scrum生产力的核心[1]。Scrum的所有实践就是围绕着一个迭代和增量的过程开展的

中文名：《》  作者：
《Scrum敏捷软件开发》是及创始人之一、及计划的鼻祖Mike Cohn三大经典著作中影响最为深厚的扛鼎之作，也是全球敏捷社区中获得广泛肯定的企业敏捷转型权威参考

《用户故事与敏捷方法》：敏捷大师Mike Cohn的软件需求方法圣经，小型团队(项目)不可或缺的敏捷开发宝典，亚马逊五星级长销图书，敏捷社区重点推荐，结合精髓和实例，充分演绎用户故事的智慧。

上海：世界图书出版公司，2007：

1、什么是敏捷（Agile）？

敏捷是一种通过创造变化和响应变化在不确定和混乱的环境中取得成功的能力。

敏捷软件开发是基于敏捷宣言定义的价值观和原则的一系列方法和实践的总称。自组织、跨职能团队运用适合他们自身环境的实践进行演进得出解决方案。

3、主流的敏捷开发框架：

敏捷不是指某一种具体的方法论、过程或框架，而是一组价值观和原则。符合敏捷价值观和原则的开发方法包括：极限编程（XP），Scrum，精益软件开发（Lean Software Development），动态系统开发方法（DSDM），特征驱动开发（Feature Driver

对于以上框架的详细介绍，可查看文末的推荐阅读

• 20世纪50年代-美国国防部（DOD）和美国航空航天局（NASA）开始采用迭代式的增量方法（IID）。
• 20世纪60年代-科技的发展，制造业岗位的消减，”知识工人“产生，旧模式不再凑效，生产工具在人的头脑里，旧式的方法被提倡信息共享和劝导的新方法代替。
• 20世纪60年代-Thomas Gilb提出演化项目管理的概念（EVO方法）。
• 2001年2月，Martin Fowler，Jim Highsmith等17位著名的软件开发专家齐聚在美国犹他州雪鸟滑雪圣地，举行了一次敏捷方法发起者和实践者的聚会。在这次会议上面，他们正式提出了Agile(敏捷开发)这个概念，并共同签署了《敏捷宣言》。

敏捷是项目管理和软件开发的一种迭代方法，可帮助团队更快地向客户，交付价，减少麻烦。敏捷团队不是把所有事情都押在“大爆炸”的发布上，而是以小的但可消耗的增量交付工作。需求、计划和结果会得到持续评估，因此团队拥有快速响应变化的机制。

• 更快交付价值：敏捷是基于价值驱动交付，项目团队要频繁的且尽快的给客户交付可以使用的产品，并尽早的让让产品投入市场可以尽早的验证其商业模式和商业价值，这是敏捷提倡的核心价值之一。
• 更低的风险：敏捷提倡优先交付高价值、高风险的需求，然后交付高价值、低风险的需求、再交付低价值、高风险、最后低价值、低风险的需求。这样的好处是把最高风险的需求在项目的初期就开始做，可以最早发现该产品是否可行（通常只要1~4周）。如果因为市场、技术或者其它原因失败了，可以及时停止该项目，降低项目风险。即使这个项目失败了，这个失败的代价相对来说小一些。
• 拥抱变化：在VUCA 迭代开发的后期也接受变更。因为市场在变化，用户的期望和要求在变化，客户的需求也会随着这些因素的变化而变化，只有及时响应这些变化，并尽快予以实施，才能帮助客户在瞬息万变的市场中保证竞争力和吸引力。而敏捷能够帮助团队在小步快跑的过程中能够快速的响应变化。
• 更好的质量：敏捷提倡高频率的交付有价值的产品。每天的例会、迭代计划会议、迭代评审会、迭代回顾会议都在对可交付成果质量上进行层层把关，因为在这几个会议中会频繁讨论遇到的问题/解决方案，验收标准，DoD等等。同时，也会邀请项目干系人参加迭代评审会并对可交付成果验收和反馈，这样团队可以及时予以调整，以确保质量。
• 持续改进：敏捷提倡不断调整和优化，并在每个迭代的迭代回顾会议进行分析、讨论、总结敏捷当前迭代开发过程中需要改进或者要提升的地方，进而在下个迭代中改进、调整和优化。这是整个团队成员不断学习，不断提升自己经验、技能的一个很好的机会。另外，因为敏捷强调客户参与的重要性，对于客户的反馈意见和建议，开发团队也会及时给与相应以及反馈，让双方可以更好的合作，建立更加信任的合作关系。
• 更高的客户满意度：敏捷提倡尽早和频繁的为客户交付有价值的产品，以确保更高的质量，更高的成功率，为客户尽早带来商业投资回报率的机会。
• 更高的团队满意度：敏捷提倡仆人式的领导，SM需要给团队工作上的指导、帮助和支持，扫除团队成员工作上遇到的问题和障碍。重视并尊重团队成员的想法和意见，授权团队并引导团队成员自组织和自管理。更重要的是，团队成员可以决定要做什么、怎么做、什么时候做，并自己监控和管理工作进展，对结果负责；团队成员可以一起讨论并确认工作协议，确保考虑并接纳每个人的意见；团队成员可以一起评估故事点；同时，SM要引导团队成员之间相互协作并促进合作。通过这些，团队成员可以更高效的工作，交付的质量也会提高，团队成员的满意度也会大大提高，"A
• 更大的灵活性：敏捷基于价值驱动，它的项目范围是可以灵活调整的，这就给项目干系人很多的灵活性来根据市场不断调整需求范围、变更以及优先级等等。另外，敏捷提倡频率与团队和客户沟通交流，并不断根据反馈和意见调整管理方法、需求流程、开发流程以及运维流程等等。还有，验收标准，DoD都可以根据实际情况进行调整。

当然敏捷还有很多其它的优点，比如透明、简洁、高效，更早进入开发等等，在这里就不一一介绍了。

尽管敏捷带来了很多改善，但是再次重申它并不是适合所有人和所有情况的。因此，了解敏捷的不足显得特别重要。知道这点后，你心理上是准备好的并且会根据具体情况来做裁剪和优化来规避或减少负面影响。

• 很难进行准确的资源规划：由于敏捷团队不是一开始就知道产品“最终的样子”，而是在过程中探索用户的需求逐渐知道产品真正的终局状态，这样一来就给前期的规划（成本，时间，资源）带来了很大的挑战（项目越大越复杂这一点变动更加明细）。
• 很难准确的定义“轻量的“或必要的文档：敏捷倡导的是用工作的软件即文档（核心是代码即文档）。整个项目用于产品开发的文档不是一开始准备好的（甚至都没有RP原型设计），而是在过程中”及时的“ just-in-time准备出来的。因此，我们看到的是非常简单的且常常被放在最后处理的文档（在项目中涉及到移交或问题分析时这一点显得尤其突出）
• 很难把握整体产品的一致性：增量交付可能有助于更快地将产品推向市场，但这也是敏捷方法论的一大缺点。因为当团队在不同的周期内对各个组件进行开发时，整体的输出往往会变得非常零散，而不是一个内部紧密集合的整体。（当项目对UI和UX有更高的要求时，这个挑战就变得更加明显）。
• 很难预测有限的终点：敏捷在一开始要求最低限度的规划，这使得交付新的、意想不到的功能时很容易偏离方向。此外，这意味着项目没有限定的终点，因为从来没有一个明确的 "最终的产品"样子。
• 很难有效地进行度量：由于敏捷是以增量的方式交付的，所以跟踪进度需要你跨周期地看。而 "边走边看 "的特性意味着你不能在项目开始时设置很多KPI。这种长期的游戏使得衡量进度变得相对困难。

6、敏捷开发与瀑布开发的区别

瀑布模型式是最典型的预见性的方法，严格遵循预先计划的需求、分析、设计、编码、测试的步骤顺序进行。步骤成果作为衡量进度的方法，例如需求规格，设计文档，测试计划和代码审阅等等。

瀑布式的主要的问题是它的严格分级导致的自由度降低，项目早期即作出承诺导致对后期需求的变化难以调整，代价高昂。瀑布式方法在需求不明并且在项目进行过程中可能变化的情况下基本是不可行的。

有论文统计，它是造成70%软件开发失败的原因。

瀑布开发大体分为这几个阶段：需求分析、设计、编码、测试、维护。

目前来说2B的传统企业，包括ERP，MES，WMS，CRM，OA，IBMS等系统当中可以经常见到他们的影子。现在这种模式仍然流行在一些大的项目或者是外包的一些项目当中。

瀑布模型作为最典型的预见性方法，其优点主要在于：

• 阶段清晰：从计划到开发最后到上线运行，三个阶段非常清晰。
• 时间顺序：每个阶段顺序必须是从上到下，严格按照时间先后进行。
• 环环相扣：在每一个阶段都必须有产出物然后才能进入到下一个阶段进行。
• 黑盒模式：每个阶段都有各自的角色和分工，各自只关心自己的任务。比如需求阶段开发人员无需关注。

• 需求隔离：由于各阶段的人员只能接触到自己工作范围内的东西，所以对客户需求的理解程度高低不等，开发人员更像是定义为流水线上的工人。
• 变更代价大：既然叫做瀑布，就意味着不应该走回头路。否则如果出现返工，付出的代价会很大。需求变更，编码人员会很强的抵触情绪。
• 束缚创造性：由于强调文档管理，所以管理人员会比较喜欢，但是他束缚了开发人员的创造性。
• 周期漫长：整个开发持续的生命周期很长，需求和设计的时间会耗费特别多，有时候会占用三分之一甚至更多时间，这样整个周期就会变长，大都在半年到一年左右的时间，所以更适合需求相对稳定的大项目。

从上文来看，敏捷开发似乎要优于瀑布开发，但本质并非如此。

两者都有自己适用的范围，而当下这个VUCA的时代，大部分项目可能都适合用敏捷开发，但仍旧有一部分确定性很强的项目会适合适用瀑布开发。

7、为什么敏捷在企业中越来越流行？

可以从两个方面简单表述：

因为移动互联网的飞速发展，基本上所有的行业要想在这个时代保持竞争力并赢得市场，都需要和互联网扯上关系，因此诞生了很多的项目，有项目就需要有人来管理，那项目管理离不开方法，那敏捷无疑是当下最好的选择了（“感觉说敏捷就是为互联网而生的并不为过”）。

敏捷方法论更符合当前这个时代的发展需求, 它可以更好、更快、更简单、更有效的应对VUCA时代，并且可以让SM/PM更加从容、淡定、自信来管理项目，并提高项目交付的成功率。

8、为什么国内有些人认为敏捷开发不行？

认为不行，自然是因为尝试过，然后失败了，便觉得敏捷项目管理不行。关于为什么会失败，国外资深敏捷教练在深入调查后在《Scrum在亚洲难以实行》一文中总结了四点原因，个人觉得是比较到位的：

• 不一样的教育方式：人们习惯于遵循体制，与敏捷思想中的“自我组织”、“自我管理”相违背
• 性格普遍偏内向，很难像西方人一样在大众场合下发言
• 组织内犯错很大程度是不被允许的，与敏捷思想中“快速试错”理念背道而驰
• 外包泛滥，所有的行为都倾向于节约成本

除了以上四点原因，其实还有诸如对开发团队的人员素质要求比较高等很多因素。

不可否认，敏捷在国内的落地过程中有种种阻碍，但这并不表示敏捷思想本身存在问题。

因为敏捷软件开发的核心思想之一就是：通过自组织、跨职能团队运用适合他们自身环境的实践进行演进得出解决方案。这也就意味着敏捷并没有固定的规章制度和流程，团队要根据自身环境的实践演进出属于自己的敏捷项目管理方法。

所以，并不是敏捷不行，而是很多人没有真正理解敏捷的思想。

我们也能看到，近些年敏捷项目管理在国内的热度持续攀升，BAT等诸多一线大厂普遍采用，敏捷项目管理所带来的价值和优点被越来越多的团队发现。

敏捷从国外传入国内，由于滋生土壤不一样，必然有一个适应完善的过程，逐渐发展出适合国内环境的敏捷项目管理模式。

9、敏捷落地需不要辅助工具软件？如果要又有哪些好用的软件？

实施Scrum 就一定要用专业的Scrum 管理系统吗？答案当然是不一定。

如果团队在25人以下，由于规模小信息差不大，流程简单，很多事情拉个会议，使用一般的白板或者是在线文档就能满足需求，这个时候上工具有时候反而会给团队的效率造成阻碍。

但是当敏捷成为超过百人团队，或进行大型项目的主流开发方式时，这些自己临时组织起来的技术团队，或者是在跨团队之间，以及日常管理多个团队，如仅靠白板、电子表格和Wiki 等将难以满足需求。

如果大家要选择一款工具来学习敏捷，国内比较推荐的是（这也是国内最标准敏捷开发管理工具）。

其他敏捷开发管理工具，大家也可通过文末的——国内外著名的10款敏捷开发管理软件盘点查看。

1.优秀的软件工程师应该具备什么素质跟能力？

要有不断被开拓进取的决心，自觉的规范意识和团队精神，英语能力要优秀，会运用数据库

2.怎样有效的开发高质量的软件？

3.软件工程重点需要学习哪些知识？

我觉得要学习高等数学，还有计算机英语，程序实际语言，当然，软件工程概论也是要掌握的

这些年来python大火，因为云计算的出现，还有互联网市场的火爆，加速了它的发展，我相信还会继续火下去

2.python的模块与JAVA，C语言相比，它的优缺点对比是什么？

Python是一种脚本语言，其语法类似C和模块化语言的结合,但它缩进来确定语句块。Python语言简练,设计优雅,具有出色的模块化特性。它提供了面向对象能力,但不强迫用户进行面向对象设计。其类型系统提供了强大的表达能力,我觉得它比 Java简单
3.在检查代码缺陷时，pylint得具体操作如何进行?

1. 进入这个模块所在的文件夹，运行

这种调用方式是一直可以工作的，因为当前的工作目录会被自动加入 Python 的路径中。

1. 不进入模块所在的文件夹，运行

1.静态代码分析工具主要做什么

静态代码分析是指无需运行被测代码，仅通过分析或检查源程序的语法、结构、过程、接口等来检查程序的正确性，找出代码隐藏的错误和缺陷，如参数不匹配，有歧义的嵌套语句，错误的递归，非法计算，可能出现的空指针引用等等。

在软件开发过程中，静态代码分析往往先于动态测试之前进行，同时也可以作为制定动态测试用例的参考。统计证明，在整个软件开发生命周期中，30% 至 70% 的代码逻辑设计和编码缺陷是可以通过静态代码分析来发现和修复的。

但是，由于静态代码分析往往要求大量的时间消耗和相关知识的积累，因此对于软件开发团队来说，使用静态代码分析工具自动化执行代码检查和分析，能够极大地提高软件可靠性并节省软件开发和测试成本

2，什么是合适的设计模型？

3.在单元测试中，用什么代替被测模块的子模块？

1.动态测试和静态分析有什么区别和联系？
静态测试是指测试不运行的部分：只是检查和审阅,如规范测试、软件模型测试、文档测试等。动态测试是通常意义上的测试，也就是运行和使用软件。静态测试，通过评审文档、阅读代码等方式测试软件称为静态测试，通过运行程序测试软件称为动态测试

2.传统开发和敏捷开发的异同在哪里？

3，软件需求开发分析模型体现在哪？

1.铁路信号采用哪种模型？

2.当新系统有差错时，系统能否自动降级版本？

3.项目管理的目地是什么？

1.价值驱动和计划驱动的利弊？

2.敏捷开发需要注意什么？

3.项目开发过程中，用户提出新的要求很难满足怎么办？

1.怎样促进高效团队建设？

3.民主式结构，主程序员式结构以及矩阵式结构的优缺点以及它们的比较？

1.敏捷开发和瀑布开发模式丝袜异同？

2.怎样制作用户故事？

3.git分支的操作？git版本库的操作？

2.软件工程师改如何才能最好的解决茅盾问题不一致的需求，完美的满足所有需求？

3.需求获取分析中分析师所扮演的地位？