如何使敏捷适应不同的公司？MBA论文

Question

我的硕士论文是研究如何应用敏捷.

有大量的企业销售敏捷 - 许多管理顾问将其品牌称为"最佳".

我不感兴趣XP,Scrum,Crystal Clear,Agile-CMMI,Six Sigma或任何其他品牌/变体是否最佳.我对真实的,活跃的开发人员(即你们)真正适用于敏捷的人感兴趣.

我调查的是如何根据不同的组织要求定制敏捷.

通过对不同组织如何应用敏捷的研究,我制定了以下指南 - 应该在什么情况下应用敏捷变体的方法:

• 更大,更分散或更灵活的团队需要更严格的编码和测试标准,小团队可以(并且应该)使用更少的.
• 流程文档应该是最小的,实时的和最新的.
• 详细的统计控制指标是不必要的开销:不完整软件的早期发布是进步的更好指示.
• 理想情况下,开发人员应该与客户关系密切,没有专门的中间角色.只有在客户专注于阻止开发人员成为用户的方式时,才应使用其他角色.
• 迭代应该是灵活的,除非它有利于与其他部门或其他过程协调发布.
• 开发人员应该能够轻松,定期地进行沟通,但会议应该很少(每月和每周,而不是每天).
• 结对编程应仅用于培训和研究任务.
• 这些指南仅是一个起点:应该使用持续改进来进一步根据具体情况定制敏捷变体.

当应用于具有现有传统(即BDUF或瀑布)模型的组织时,这些因素会发生变化,敏捷团队必须与使用非敏捷方法的团队共存或改编:

• 注销和结构化步骤的流程文档将帮助其他团队跟踪项目.
• 统计指标(如速度)可以帮助非敏捷团队确保流程得到控制.
• 固定迭代将有助于团队之间的协调.

这些附加指南将有助于敏捷与传统模型共存,但它们提供了额外的开销和限制.

我想知道的是你 - 编写软件的人,而不是敏捷顾问 - 想到这个框架.

您认为准确的是什么？你觉得怎么了？你会改变什么？我错过了什么？

最重要的是:为什么？

---

我已经为此添加了一笔赏金,以提供额外的奖励来回答这个相当长的问题.赏金将归于SO社区获得最多选票的人 - 我意识到没有单一的正确答案,但我对最接近社区共识的内容感兴趣.

Answer 1

• 更大,更分散或更灵活的团队需要更严格的编码和测试标准,小团队可以(并且应该)使用更少的.
• 流程文档应该是最小的,实时的和最新的.
• 详细的统计控制指标是不必要的开销:不完整软件的早期发布是进步的更好指示.
• 理想情况下,开发人员应该与客户关系密切,没有专门的中间角色.只有在客户专注于阻止开发人员成为用户的方式时,才应使用其他角色.
• 迭代应该是灵活的,除非它有利于与其他部门或其他过程协调发布.
• 开发人员应该能够轻松,定期地进行沟通,但会议应该很少(每月和每周,而不是每天).
• 结对编程应仅用于培训和研究任务.
• 这些指南仅是一个起点:应该使用持续改进来进一步根据具体情况定制敏捷变体.

编码/测试标准无论团队的规模和分布如何,都需要实施IMO.具有编码/测试标准会导致更多可管理/稳定的代码.

我同意文件.通过使用一些清洁代码实践,例如有意义的注释和意图揭示代码中的命名约定,您可以删除对代码本身的文档的一些需求.文档应该在业务级别,我更喜欢采用验收测试的形式.

虽然通过迭代过程使开发人员与客户关系得到改善,但您需要通过直接向开发人员添加/更改/范围蔓延来保护开发人员免受业务影响.企业仍然需要通过积压整理/优先排序等来跟踪流程.

通过使用发布迭代以及开发迭代,您可以维护适用于团队的灵活的迭代计划.目前,我们每3到4周进行1周冲刺迭代,发布冲刺.

会议的类型应决定会议的频率.每日站立时间需要每天进行.它们为团队提供了可靠性和透明度,这对于拥有一支成功的团队至关重要.回顾需要在每次迭代结束时发生,并且该频率由迭代的大小决定.代码审查,演示等其他会议不应该按时规定,而应根据需要和完成情况.

对编程永远不应该固定到特定类型.我们将我们的QA测试人员与我们的BA团队进行编程,以便双方更好地了解UAT和故事.我们还为知识共享,原型设计,研究任务等配对编程.在我们的环境中,编程已成为第二天性.

当您学习如何根据业务需求修改敏捷实践时,敏捷的持续改进将成为二手性质.只要你不偏离宣言,你的敏捷应该是成功的.