如何使敏捷适应不同的公司? MBA论文[已结束]

问题描述 投票:17回答:9

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

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

我不感兴趣XPScrumCrystal ClearAgile-CMMISix Sigma或任何其他品牌/变体是最好的。我对真正的,活跃的开发人员(即你们)真正适用于敏捷的人感兴趣。

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

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

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

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

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

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

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

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

最重要的是:为什么?


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

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

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

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

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

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

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

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

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


3
投票

最后两点我有一个小问题。每日站立会议非常有益。它让我们可以回顾前一天我们的工作,以及我们打算在下一次会议(明天)之前工作的内容。值得注意的是,每日站立会议应该保持简短和重要。我们陷入了一种情况,有些人喜欢提出有关该项目的各种问题,所以我们决定不问任何问题,只有生产力声明。如果有问题,则与该组件的负责人安排进一步的会议。

另外,结对编程不应该用于训练和研究任务。结对编程有许多好处,例如知识共享/传输和代码所有权。关于一个问题的两个想法可以带出许多有趣的观点,并有助于隔离潜在的设计缺陷。在我看来,结对编程被低估了,大多数自私的程序员不喜欢结对编程。这对项目和团队是有利的,而不是对自己的好处。好的软件是由协作团队编写的,而不是一个书呆子。


3
投票

作为博士论文的一部分,您还应该考虑如何在遍布全球不同部分的团队中使用敏捷。所以,如果你在东海岸有一个产品团队,在印度和俄罗斯有开发团队,在新加坡有QA团队等等。这对我来说是一个完全不同的球类游戏,需要完全不同的模式。

例如,一些模式是:

  1. 根据时区,将世界某一地区的早起者与另一部分的晚期起居者配对,反之亦然。这不是完全对编程,但你可以称之为你想要的任何模式。
  2. 重点必须是使代码尽可能可读,而不是可写。这意味着我们可能必须强调统一的设计模式和流畅的命名。
  3. 以这样的方式创建团队,即您拥有其中一个和我们中的一个。这意味着您将Russsian开发人员与印度开发人员配对,他们在一个模块上一起工作。

随着时间的推移创建自己的模式,使敏捷工作变得非常有趣,并且需要大量的耐心和努力。

希望这个新角度能以某种方式帮助你。


2
投票

好家伙。祝好运。

我喜欢你的方法,特别是从我们的咕噜声中获取输入而不是金表的powerpoint设置。

我想说任何这样的方法都需要适应具体情况。没有人应该做某事只是因为别人说他们应该这样做。对于自己的思考应始终站在最前沿,恕我直言。

自从我与斯隆学校的MBA学习合作以来已经有一段时间了,但我清楚地意识到他们被教导程序员要“管理”,而不是“培养”。我们是一种不愉快的商品,而不是完整的团队成员。我希望你有比这更好的经历。


2
投票

当软件可以在共享硬件环境中部署到生产时,我们在具有高度集成的软件和预定窗口的大公司中实践敏捷。

我们开发了一套由SCRUM(项目管理)实践和XP(工程)实践组成的敏捷实践。我们部署的许多系统都使用传统的瀑布流程

关于您的框架,我将回复每个项目:

“更大,更分散或更灵活的团队需要更严格的编码和测试标准,小团队可以(而且应该)使用更少的。”

如果通过编码和测试标准,您指的是工程实践(XP),例如持续集成,结对编程,测试驱动开发,自动化功能和性能测试等。无论团队或项目的规模如何,我们都会采用所有相同的实践。因此,我们经常发布在用户验收测试期间发现零缺陷的软件。发布高质量的软件(低缺陷),这些软件仍具有可延展性,能够以可持续的速度实现持续开发,这推动了对工程实践的需求,而不是组织的规模。

“流程文档应该是最小的,实时的和最新的。”

如果通过流程文档表示敏捷流程文档,那么我们所有的工作都适用于墙上。我们展示宣言,映射到12条原则,最后展示我们雇佣的21条实践。它们适合墙壁并且高度可见的事实使团队能够理解它们,更重要的是实际将它们付诸实践。

“详细的统计控制指标是不必要的开销:不完整软件的早期发布是进步的更好指示。”

完成传统工作工件的百分比几乎没有价值。每两周向我们的产品所有者/业务合作伙伴提供工作软件是进度的最佳指标。跟踪实际速度(完成故事卡的单位)和缺陷率以及在大型可见图表上显示数据非常有帮助。在向团队介绍某些实践时,显示进度很有用。例如,学习TDD时代码之前编写的单元测试数。

“理想情况下,开发人员应该与客户关系密切,没有专门的中间角色。只有当客户专注于阻止开发人员成为用户的方式时,才应使用其他角色。”

如果可能,用户应与开放工作区中的团队一起工作。如果用户不可能与团队在一起,那么用户代理就是下一个最佳人选。没有人可以提供比实际使用该软件来完成工作的人更好的反馈。

“迭代应该是灵活的,除非它有利于与其他部门或其他流程协调发布。”

更重要的是,发布日期应该跨团队进行。如果持续时间保持一致(我们每2周使用一次),则迭代最佳。一致的迭代长度与时间装箱和用于下一次迭代的用于提交故事卡的速度的计算一致。

“开发人员应该能够轻松,定期地进行沟通,但会议应该不常见(每月和每周,而不是每天)。”

团队应该参加每日站立会议,每次迭代都要参加迭代计划会议,展示和讲述会议,计划扑克会议和回顾会议。每个版本的团队都参与了发布计划会议。鉴于用户/业务合作伙伴使用该线路,可以对正在完成的工作进行日常对话。

“结对编程只应用于培训和研究任务。”

使用Pair Programming的第一个原因是消除缺陷。我已经写了很多关于结对编程的回复。总而言之,不太可能被阻止,不太可能接受电子邮件或网络假期的对,提供了转移业务领域,应用领域和工程实践技能的机制,消除了知识孤岛(大型组织中的关键)等。

“这些指南只是一个起点:应该使用持续改进来进一步根据具体情况定制敏捷变体。”

回顾,计划每次迭代或发生需要回顾的事件,并且零缺陷的思维模式推动持续改进。员工XP工程实践使团队能够保持代码健康,从而可以无限期地轻松添加新功能。我们将瀑布项目中的可交付成果视为约束。为了管理约束,我们提前请求这些团队的工作,并使用工程技术(如模拟)来测试将与这些可交付成果集成的故事卡。

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

我们拥有生活在瀑布世界的敏捷团队。我们邀请瀑布项目参与我们的发布和迭代计划会议(以及回顾展)。我们已经并将继续取得成功,继续为公司内部的敏捷实践带来新的转变。

“带有注销和结构化步骤的流程文档将帮助其他团队跟踪项目。”

不同意。故事卡墙,迭代计划和发布计划是团队成员或团队外部人员所需要的。

“统计指标(如速度)可以帮助非敏捷团队放心,这个过程得到了控制。”

同意。敏捷团队将提供可见的速度和缺陷率。预算将在1%或2%之内,并且发布将按计划进行,因为它们是时间框。

“固定迭代将有助于团队之间的协调。”

需要高度集成的大型环境。还可以帮助团队根据速度构建迭代和发布计划。


2
投票

一个崇高的事业,祝你好运。以上所有优点也是如此。我只会补充:

Agile is about the principles, not the process.

Agile Manifesto

改变公司行为是目标,而不是改变一个经过验证的过程来“与一个破碎的组织合作”,因此强调每个实践背后的原则。然后不要改变做法。如果原则不适用,则放弃反映原则的实践。改变做法会破坏原则并使其目的失效。这种“适应”的最终结果很可能是已经使用的同样有缺陷的过程,现在包含在敏捷术语中,但缺乏使其起作用的原则。

Process Documentation is Anti-Agile

"Process documentation with sign off and structured steps 
 will help other teams track the project"

我不得不对此说一个大胖子。文档将把敏捷带到流程之外(更不用说开发人员的生活和精力)。如果您想帮助其他团队跟踪项目,请在Intranet上发布迭代计划和速度。请不要浪费开发人员的时间 - 以及客户的资金 - 编写流程文档,特别是对于非利益相关者并且没有风险的其他人的所谓利益。

当然,如果没有至少一个Dilbert参考,没有MBA候选人可以逃脱程序员线程:Dilbert meets an MBA (来源:dilbert.com


1
投票
  1. “流程文档应该是最小的,实时的和最新的。”

“最小”是什么意思?它是指页数或覆盖意义上的总和(v.gr. standards doc,configuration management manual,design doc)。

当你假设一个团队中没有营业额的项目时 - 在长项目中这不是一个合理的假设,你需要一个有效的知识转移机制,而最有效的知识转移机制就是文档。

我已经看到文档保持最小(从页数意义上讲)的项目,因为开发文档太麻烦了。但是,如果您可以重复使用从一个项目到另一个项目的文档而无需更改或进行最小的更改(这对于编程标准,配置管理手册等文档来说是合理的),则不会产生文档开发负担。

流程文档应涵盖所有软件开发过程,否则您将面临以不一致的方式执行的流程的风险。敏捷团队拥有敏捷的软件流程。通过软件开发过程,我指的是管理代码,控制版本,控制评论,检查代码,修复错误等的清晰机制。


1
投票
  • 更大,更分散或更灵活的团队需要更严格的编码和测试标准,小团队可以(并且应该)使用更少的。

无论团队规模如何,持续测试都是非常宝贵的。应根据项目成熟度和组件关键性进行测试的数量。

对于新产品,定期演示非常适合士气,并且足以为管理层提供进步感。

对于成熟和运输产品,最低定期验收主要功能的测试将跟踪产品的发布准备情况。

对于主要系统接口,单元测试是说明性的,有助于避免意外。在处理签约的子项目时,单元测试比文档更好,对于避免指责延迟至关重要。

测试优先开发是重型代码的有价值的实验。如果您最宝贵的资产是您的技术,那么它应该经过彻底的测试。

  • 详细的统计控制指标是不必要的开销:不完整软件的早期发布是进步的更好指示。

统计控制指标对于早期识别项目超限至关重要,但它们最好永久地留在“敏捷教练”或“Scrum Master”手中,或者直到整个团队在准确计算进度和延迟时受到纪律处分。

有效应用时,敏捷开发实践应该产生足够小的故事和任务,以便在数小时到数天内完成。有效管理“计划游戏”和导致个别任务超支的反馈可以最小化估计和收集进度数据的开销。

最后,客户(和/或管理)决策的历史记录以及对这些决策实际花费时间(天)的会计将导致改进工程和业务流程的方法。阻碍开发和花费时间的“泳道”或“甘特图”将显示“但我们敏捷”并不是轻率商业决策的借口。

  • 理想情况下,开发人员应该与客户关系密切,没有专门的中间角色。只有在客户专注于阻止开发人员成为用户的方式时,才应使用其他角色。

我曾经同意!单独的开发和管理会议可以很好地解决问题。

  • 迭代应该是灵活的,除非它有利于与其他部门或其他过程协调发布。

敏捷迭代是建立持续可释放产品的宝贵发展节奏。迭代的结束是当可以实现特征决策并且可以进行源控制改变以分支不会成为目标的特征。

但是,当迭代不能满足业务需求时,团队可能难以实施这种做法。应根据演示和促销等业务需求安排迭代。

  • 开发人员应该能够轻松,定期地进行沟通,但会议应该很少(每月和每周,而不是每天)。

周一/周四的站立会议是一个好主意。然而,它需要15-30分钟的硬帽。根据需要拆分会议以减少时间。分开关注以避免浪费开发人员的时间。

办公室的狗可以帮助人们在会议期间保持专心。一些树皮比点头或发短信的人要好。

  • 结对编程应仅用于培训和研究任务。

结对编程,单元测试,无情重构和测试驱动实践是团队采用的最难的敏捷技能。结对编程的好处是提高意识和知识,防止在错误的决策和假设可以延迟和级联的情况下孤立地完成工作。


1
投票
  • 更大,更分散或更灵活的团队需要更严格的编码和测试标准,小团队可以(并且应该)使用更少的。

无论团队规模如何,都应该存在编码和测试标准。它们提高了代码的可维护性,并使新资源更容易上手。

  • 流程文档应该是最小的,实时的和最新的。

同意。

  • 详细的统计控制指标是不必要的开销:不完整软件的早期发布是进步的更好指示。

软件开发的统计控制指标并不多,这些指标始终具有价值。我会寻找时间和预算的差异,测试和生产中的缺陷率,以及估计的方差。

  • 理想情况下,开发人员应该与客户关系密切,没有专门的中间角色。只有在客户专注于阻止开发人员成为用户的方式时,才应使用其他角色。

因此,这通常是不切实际或不可能的。客户在自己的工作中有很多工作要做,以至于他们很少有时间与开发人员进行过多的交流。业务分析师具备整合业务问题所需的技能,并能更有效地获得明确的答案。如果您的发布周期足够短,客户将有充分的反馈机会。

  • 迭代应该是灵活的,除非它有利于与其他部门或其他过程协调发布。

应该有一些灵活性,但并不多。敏捷方法的一个好处是它迫使团​​队将范围限制在最有价值的要求。增加迭代时序的灵活性会增加范围蔓延的风险。

  • 开发人员应该能够轻松,定期地进行沟通,但会议应该很少(每月和每周,而不是每天)。

每日会议对大型团队有效。他们使人们保持正轨并增加协作。它们有助于防止团队成员在没有寻求帮助的情况下陷入困境。它们还有助于保持对迭代的控制,考虑到缺少其他可用控件,这非常有用。

  • 结对编程应仅用于培训和研究任务。

关于这个我没什么可说的。

  • 这些指南仅是一个起点:应该使用持续改进来进一步根据具体情况定制敏捷变体。**

究竟!敏捷旨在满足组织的需求。不断调整对于完善流程至关重要。

你的论文祝你好运。

© www.soinside.com 2019 - 2024. All rights reserved.