软件开发：从瀑布过渡到敏捷

敏捷方法的兴奋自2010年以来爆发了。软件交付中近乎灵丹妙药的回声，激发了敏捷技术作为客户对应用界面需求的解决方案。敏捷的应用程序是许多敏捷团队和公司所赞赏的主要属性。

敏捷方法阐明了软件交付和促进交付流程。然而，平滑过渡到敏捷的复杂性更为不透明。敏捷演习的有机性超越了程序，更深入到视觉和发展的本质上。从过程驱动的传统向有机驱动的创新过渡的挑战是概念身材的近乎全面的转变。要开始旅程，首先看看软件开发出现的地步。

什么是瀑布？

系统设计和开发的传统方法是瀑布。瀑布，因为开发和发布遵循下降的一系列时间顺序，所以要求所有流程始终从项目开始到项目结束。要求，设计，实施，验证和维护的顺序阶段始终如一。瀑布方法假设所有的开发元素都要在项目开始时进行组装。用户投入，管理需求和预期成果在项目实际实施之前确定。然后，项目的其余部分在随后的流程中形成，如同瀑布。

瀑布方法根据规定的程序结构很好。瀑布测试是参照项目初始阶段制定的要求定义的功能和设计定义的场景进行的。结构化的交付方式通常取决于抽象的客户定义的需求，这通常在验证阶段迫使整个应用程序进行重新设计。随着要求迅速改变原有要求，设计可能不再适用于消费者的需求或偏好。而且由于该项目是连续的，所以往往需要更长的生产时间。

瀑布设计的模式是连续而不是迭代的。项目以比虚拟编码设计更好地适用于物理制造和施工的阶段降序排列。发展是建立在不可逆转的基础之上的。尽管阶段之间的反馈环路允许进行修改，但该过程延长了上市时间。修改一般只允许更新上一个阶段，通常不会考虑到更新如何改变其他开发阶段的有效性。意外更新所需的延长时间使得时间和成本估算不准确。

随着瀑布方法的几乎60％的失败，需要最初稳定的软件，敏捷而不是有限的结构，迭代而不是严格格式化的阶段，更新迭代工具中的过时的发现，并重新定义DONE，积极的系统分析师搜索替代的软件交付方式。

什么是敏捷？

敏捷不仅仅是一个流行语。敏捷开发在软件开发方面是迭代和增量的。发展前期的成果影响或决定后续阶段的规划。敏捷是 对严格控制的瀑布模式的软件开发和发布的挑战的答案。

敏捷从创新的角度来看待软件开发。基于可预测结果的技术从敏捷方法中消除。敏捷流程不仅接受软件构建的不确定性，而且还将不确定性作为创新的资源。先入为主的期望是敏捷构建的有机性和增量技术的外在因素。

非分级敏捷方法使团队和团队成员能够在自我指导的团队内自由协作。团队通过对构建组件的简要描述启动开发，并通过开发，讨论，测试和审查的迭代增量来形成细节。通过产品工程的增量手段更好地管理风险。增量开发也更快地生成功能性软件应用程序。测试和审查也是增量的，发生在整个开发过程中，而不是生产的高潮。管理和项目发起人可以沿着发展时间表做出坚定的决定。




敏捷旨在促进团队成员之间积极和运作良好的关系，实现自我管理团队和团队流程，以满足持续消费者对更新的需求和软件消费水平的波动。团队将多才多艺的资源整合到跨职能过程中，以促进生产，激发创新。

敏捷方法允许在整个软件生命周期中评估项目方向。定期迭代的策略激励团队在每个增量版本结束时产生潜在可运输的产出，为即时更新和更持续的交付提供即时的机会。这样，当需求和分析正在发生时，可能会发生软件开发。开发通过构建活动而不是严格定义为生产阶段而被整合到事实调查中。

值包括：

个人与过程和工具之间的协作互动

软件开发涉及广泛的文档

通过合同谈判与客户进行互动和协作

响应规定的方案进行变更

敏捷开发的必要属性是：

积极的用户参与

团队获得决策权

在时间线固定的情况下流动的要求

设想为高层次的总体要求

执行为迭代的小的增量发布周期

专注于频繁交货

确保每个增量在进入下一个增量循环之前完成

确保在整个项目生命周期中整合测试生命周期

所有利益相关者之间的合作与合作

敏捷的视觉焦点和合作参与可以是一个丰富而有益的团队经验，激发了软件应用程序的价值产出。当团队成员有动力时，生产中的成果是惊人的。

过渡到敏捷方法

层次结构，如瀑布模型，使用领导力和力量个性工具。领导人物聘请销售人员，具有魅力，使用角色建模，并进行谈判来实现过程。权力人士还使用谈判，倾向于有限地定义角色，需要权威许可，有时使用恐吓或胁迫来影响生产过程。

敏捷方法更多地依赖文化和利用正确的工具，包括测试管理。敏捷强调口头和合理的沟通，信仰和尊重的文化，视觉，规定的行为形式，人们是生产力​​的主要来源。敏捷流程强调战略规划，财务激励，坚实的指标，渐进的标准和自我激励。

考虑到这些属性，从传统开发模式转变为敏捷开发需要一种与组织关注的所有方面相吻合的方法。负责过渡到敏捷的人员的优先事项应该是处理可能受到过渡影响的每一个考虑因素，在过渡过程中采取可能的顺利运作的手段。

过渡管理人员有责任确保将敏捷技术应用于适合敏捷流程的项目。该项目需要一个活跃和有吸引力的客户作为商业赞助商。发展应该是中等简单的，时间安排为2-3个月。应避免过多的复杂性，使团队成员的学习过程复杂化。更短的时间表可以更好地吸引管理层的兴趣，否则随着时间的推移可能会减少。为了进一步参与管理，初始敏捷项目对组织来说应该是重要的，如果是在瀑布模型中开发的，那么可能会遇到生产和时间线要求失败的情况。

建立正确的团队 - 选择合适的人选

对于第一个敏捷项目，在项目启动时从一个敏捷团队开始，并在项目生命周期内扩展到不超过五个开发团队。敏捷团队是多学科的。选择可以跨职能团队有效运作的多才多艺的人。选择与严格现状不同的团队成员，以及具有不同背景的团队成员，如具有哲学学位的分析师。

避免大的自我倾向于将空气吸出房间，并且往往缺乏自我评价。确保团队成员之间没有负面关系。即使从高专业知识或政治影响力来看，也不要强迫不情愿的参与。热情是促进敏捷的。

很多时候，最好的敏捷人物是可能看起来无组织和非常规的创始人。起源者喜欢改变目前结构的挑战，这使得他们成为可能的创新者。发起人的个性挑战假设，风险和不确定性蓬勃发展，并表现出对政策的减少。缺点可能是作为团队成员的创始人可能过度，侵略性和叛逃。

考虑敏捷团队的另一个个性是实用主义者，他们可以实用，愉快和灵活。实用主义者喜欢可行的结果，并且多次主要集中在结构上而不是结构上。实用主义倾向于考虑事物的双方，因此可以成为有效的调解员，同时也更多地引导与团队的互动。实用主义者的缺点可能是犹豫不决，过分遵守。

选择团队成员，从而补充彼此的个性以及彼此的技术专长。还要寻求赞助敏捷的赞助商和舆论领袖，他们专注于创新，具有敏捷经验的代理人。一系列人才和观点构成了最具创新力和敏捷性的敏捷团队。

从管理层收购

鼓励和使管理层接受和促进过渡目标。促进敏捷流程的成本效益方面，以及持续交付的速度。克服对项目尚未验证状态的抵制，注意降低风险。了解传统观点，有利于可预测的行为和持续的期待，以便您可以强调和澄清迭代过程在提供可靠结果方面的改进效益。

克服阻力

了解那些最具抵抗变革能力的人通常都是刻意考虑情境，遵守标准，并按照过程的方式进行组织。他们通常喜欢保持现状的活动，例如可预测性，细节和常规培养他们的安全感，这使得他们对敏捷方法的不可预测的文化谨慎。

首先研究组织中的人是否听。这些可能不是具有正式权威的人。但他们将是影响和建议操作行为的人。说服敏捷的好处的影响者。然后利用这些影响者来说服决策者。强调需要纠正措施的问题，而不是任何设计的解决方案。人们觉得他们已经知道了解决方案。但是，更充分地理解这​​个问题可以理解解决方案可能难以捉摸，需要对敏捷方法进行深入的迭代。

聆听替代解决方案，并介绍敏捷方法与这些解决方案平行或互动的方式。然后说明为什么目前需要改变。让利益相关者知道为什么现在是投资敏捷过程的时刻。帮助那些抗拒转型的人看到发展过程，从而认识到敏捷变革的好处。然后激发他们的认可，具有培养他们专业既得利益的特定利益，减轻对风险的焦虑。

启发团队

将项目紧迫感植入团队。项目的重要性必须处于每个团队成员动机的前列。然后将团队连接到产品和交付过程的愿景。创意的灵感来源于创新，激发了团队的艰辛迭代。授权团队成员和整个团队成为决策者，并对其做出决定。




将发展整合到精心调整的团队对称性中。利用Agile方法经验丰富的教练来协助团队合作。计划构建，支持流程，并创建产生概念上可交付产品的增量胜利。计划，生产，测试，适应和重复。

敏捷作为替代方案被证明是软件交付的一个可行的答案。

通道：ACP敏捷项目管理说明会