敏捷开发 敏捷个人
敏捷开发自然会导致维护–增量敏捷开发的目标是尽快将可用的软件发布给客户，并让客户使用它。 在某些时候，当客户依靠软件来完成实际业务并需要支持和帮助以保持系统运行时，团队就会从开发过渡到维护。 但是，发生这种情况时，敏捷开发团队没有理由从根本上改变他们的工作方式。
将敏捷实践引入传统维护团队比较困难–有很多技术要求和一些文化上的改变需要进行。 但是，大多数维护团队从敏捷开发团队所做的工作中所获得的利益几乎没有，可以从中受益。 敏捷方法旨在帮助小型团队应对大量变更和不确定性，并快速交付软件-所有对维护至少与在开发中同样重要的事情。 极限编程中的技术实践尤其有助于确保代码始终有效-在维护方面比在开发过程中更为重要，因为代码必须在生产中首次工作。
敏捷方法必须适应维护，但是大多数团队发现有必要对这些方法进行适应以适应他们的情况 。 让我们看看哪些方法有效，哪些必须更改才能使敏捷方法（如Scrum和XP）在维护中起作用。
什么有效，什么无效
规划游戏
管理维护与管理开发项目（甚至是敏捷开发项目）并不相同。 尽管敏捷开发团队期望处理歧义和不断变化，但维护团队需要更加灵活和响应能力强，以处理冲突和不可预测的资源问题。 工作必须不断进行审查并确定其优先级–客户迫不及待需要2周的时间来查看生产错误。 团队需要快速的途径来进行紧急更改，尤其是热修复。
您必须为支持需求和中断做好准备。 组建团队，以便某些人可以得到二级支持，消防和紧急错误修复，而团队的其他成员则可以继续前进并完成工作。 将空闲时间安排在日程表中，以允许进行最新更改并支持升级。
您还必须在计划维护工作时更加谨慎，以考虑到技术和操作上的依赖性以及约束和风险。 您现在在现实世界中工作，而不是在项目的虚拟现实中工作。
站立
在敏捷项目中，站立式起着重要的作用，以帮助团队加快速度并建立联系。 但是大多数维护团队都可以很好地工作，而无需站着工作 -因为许多维护工作可以由一个人独自完成，所以团队成员不必每天早上互相倾听，谈论他们昨天的工作以及他们的工作要做的事情-除非团队正在共同努力进行重大变更。 如果有人有问题或遇到问题，他们可以寻求帮助，而无需等到第二天。
小发行
维护团队需要进行的大多数更改和修正都是很小的，几乎总是有来自企业的压力，要求它们在准备好代码后尽快将其发布，因此采用少量且频繁发布的敏捷方法非常有意义。 如果时间间隔足够短 ，则客户中断和重新安排进行中工作的优先级的可能性就降低了-大多数企业可以等待几天或几周来进行更改。
时间拳击为团队提供了一种控制和组织其工作的方式 ，可以为相关工作分批进行批量处理以降低开发和测试成本，还可以利用自然机会添加安全控制和审查以及其他功能。 它还使维护工作更像一个项目，使团队有机会设定目标并看到完成的事情。 但是，时间装箱带来了额外的开销-从头开始进行规划和设置，然后在结束时进行部署和检查-所有这些都会随着时间的推移加在一起。 维护团队必须毫不留情地举行仪式和会议，将它们削减下来，只保留必要的内容和有效的内容。
要记住，目标是在每个时间框的末尾交付工作代码，这在维护方面比在开发中更为重要。 如果某些代码不起作用，或者您不确定它是否起作用，则延长截止日期，撤消某些更改，或者拔掉此发行版的插头并重新开始。 不要冒险因任何截止日期而导致生产失败。 如果团队在将工作安排到时间框时遇到问题，请停下来弄清楚自己在做什么–团队试图做得太快，或者代码太不稳定，或者人们不理解代码足够-修复它并继续前进。
回顾与回顾
回顾对于维护团队保持前进，寻找更好的工作方式并解决问题非常重要。 但是，像许多做法一样，定期审核会随着时间的流逝而减少收益–人们最终会通过动议。 团队成立后，除非团队遇到问题，否则无需在每次迭代中进行审核。
在您或团队需要它们时安排评论。 收集有关团队工作方式，周期时间和错误报告/修复率的数据， 将生产中的问题与变更相关联 ，并召集团队一起审查数字是否偏离预期。 如果团队遇到严重问题，例如重大生产故障，请通过根本原因分析深入研究问题。
可持续的节奏/每周40小时
每周维护40小时并非总是可能的。 有时候，团队会被迫进行紧急更改，在深夜进行消防，下班后释放并在周末进行测试。 但是，如果这种情况发生得太频繁或持续的时间太长，团队就会精疲力尽。 建立长期的可持续发展速度，公平对待人们并为他们提供做好工作的机会至关重要。
配对
在人们从事许多不同工作的小型团队中，配对很难做到。 在某些情况下，配对确实很有意义-人们在尝试调试一个棘手的问题或进行复杂的更改时自然会配对-但没有必要强加于人，并且有充分的理由不这样做 。
一些团队（例如我的团队）更多地依赖于代码审查而不是配对，或者在第一次查看问题或变更时试图使开发人员配对，最后再次审查代码和测试。 重要的是要确保如果可能的话，至少要有至少一位其他人来查看更改，但是这样做可以做到。
集体代码所有权
因为维护团队通常很小，并且必须处理许多不同种类的工作，所以迟早会有不同的人最终从事代码的不同部分的工作。 这是必要的，这是一件好事，因为人们有机会了解更多有关系统的知识，并可以使用不同的技术和解决不同的问题。
但是仍然有维护专家的地方。 您希望最了解代码的人员能够进行紧急修复或高风险更改-或至少让他们检查更改-因为它必须在第一时间工作。 有时您别无选择–有时只有一个人足够了解框架，语言或技术问题，可以完成某项工作。
文章继续于您在维护中不能敏捷？ （第2部分） 。
参考： 您在维护方面不能敏捷吗？ 从我们的JCG合作伙伴 Jim Bird在“ Building Real Software”博客中获得 。
翻译自: https://www.javacodegeeks.com/2011/10/you-cant-be-agile-in-maintenance-part-1.html
敏捷开发 敏捷个人
扫一扫
217
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
