您是瀑布组织中的敏捷/务实开发人员吗？

Question

如果是这样，你如何处理那些没有“感觉”正确的事情，例如：

• 不写单元测试
• 没有持续构建
• 不重构
• 没有团队编码标准
• 不是结对编程
• 没有进行迭代
• 没有每日站立
• 没有回顾

现在，一些敏捷组织确实忽略了其中的一些做法，但大多数成功的做法都包含了大部分做法。

你如何处理传统开发过程中看似混乱的问题？

Answer 1

实际上，我是敏捷组织中的瀑布式开发人员。

对我而言“不合适”的事情包括：

• 在项目上开始工作，几乎不知道应该做什么。
• 记录流程，但不记录产品;无需与某人交谈就无法获取信息。我需要的只是一份需求文档，一份设计文档（我可以自己编写）和Google。
• 在会议上花费的时间多于编码。
• 在家中花费更多时间而不是工作时间。
• 不知道该项目何时完成。
• PM在任何方面都很有用。
• 召开会议以准备会议以准备其他人登录服务器并复制文件的会议;因此花费六个小时来完成一个需要六分钟的过程
• 多次结帐
• 了解事情应该如何流动，但没有实际要求。
• 开发人员的独特技能集被淡化或完全忽略，因为它们使开发人员不可互换。
• 当没有剩下的故事......无事可做......只是有点坐在那里......可以添加一个新功能;可能不需要，但时间不会浪费......
• 我改变合同的每六个月，我必须适应新的编码标准？当我习惯它时，我已经在寻找我的下一份合同了。

Answer 2

为什么这些做法与瀑布不兼容？据我所知，几乎所有这些，如果不是绝对所有这些都是可能的瀑布方法。瀑布开发必须是混乱的，没有特别的原因。它可能有其他缺点/挑战，但是名单上的混乱可能并不高。

Answer 3

没有进入“抱怨”模式..我会选择回答问题的“处理它”部分。我从我的经验中得出了以下选项

1. 有点简单的方法：退出并找到一个更符合你自己喜欢的地方......我说因为misc而有点容易。子问题：您附近可能不存在“敏捷”工作场所。搬迁可能不是一种可行的方法，敏捷工作场所的人可能会“非敏捷”，
2. 中间路径：继续亲自敏捷。帮助和教导有兴趣的人..也许是组织者。会慢慢变好。希望最好，并祈祷你没有达到'不归的退出点'
3. 超级强硬的方式：努力为您的组织带来变革。这不是每个人的一杯茶。组织的文化不可能在短时间内改变......你需要管理层的“本地赞助商”才能开始实质性的工作。认为除了你自己以外你无法真正改变另一个人这一事实。因此，如果你充满热情，耐心，无情，高度乐观并愿意坚持下去，我全心全意地推荐“ Fearless Change ”。
   alt text http://www.informit.com/ShowCover.aspx?isbn=0201741571&type=f

Answer 4

首先，敏捷方法论强调这些实践，但他们没有引入它们。在敏捷进入之前，他们一直在软件开发过程中。所以简单地说，如果你不使用Scrum / XP / RUP，那么你不遵循这些做法是完全错误的。如果您是一个专业的软件开发组织，这些实践将以一种或另一种形式存在。

其次，无论您是瀑布式组织中的敏捷开发人员还是反之亦然，您都无法做很多事情，至少不能有效或显着。组织的“文化”发展是管理和执行的承诺和重点的一个功能。如果那不存在，你可以做你的'有点'，但你最终会失败。这就是敏捷在转型时失败的原因，因为他们不愿意进行文化变革。

Answer 5

我是一个伪敏捷组织，这是我对你提出的那些观点的回应：

• 不写单元测试：我是100％覆盖率的信徒。是的，很容易说你可以有100％的覆盖率并编写非常糟糕的测试，但是，我写的任何新代码，我都尽力接受验证或集成测试并且对我
• 没有持续构建：由于每个人之前的工作方式，大多数人在没有覆盖检查的情况下运行构建，因此可以毫不费力地检查他们喜欢的内容而不进行测试。更不用说连续构建有时似乎已经开启，有时似乎已经关闭。我非常接近于建立一个自己的CI盒。
• 不重构：我尽我所能重构，所以当我再次看到同一个班级时，我不会呕吐。
• 没有团队编码标准：公司有编码标准，但是，有很多事情是错误的。因此，我会尽最大努力将那些更高层次的东西用来改变它。有时候他们认为正确的方式会受到伤害。例如在整个文件中为公共，私有，受保护，字段，常量等放置巨大的java注释节头。我相信这是曾经做过的，因为类失控（例如数千行），他们需要节标题，这样你就可以找到你的公共方法的起始位置以及私有方法的起始位置（!!）
• 没有结对编程：幸运的是我有一个像我一样坐在我身后的人，我们会尽可能多地谈论和讨论想法以补偿。
• 没有进行迭代：我们有3周的迭代次数，但感觉非常特别。每次迭代之间都有一个清理/复查周，这使得它理论上是一个4周的迭代。我不能做任何其他事情。很难说服他们将这些迭代缩短，因为代码非常糟糕实际上需要 3周才能写出一些只需要1周的时间。
• 没有每日站立：我们有立足点。
• 没有回顾：我们有回顾。

Answer 6

说真的，如果你的组织像你描述的一样混乱和业余，我会在他们失败之前开始寻找另一份工作。作为Martin Fowler once quipped

  

如果您无法更改组织，请更改您的组织

另一方面，如果您觉得他们可以改变，那么我会尝试通过在列表中的其他任何内容之前引入回顾来启动此更改。如果你能让人们互相交谈，并开始识别正在发生的浪费，并且有关人员有足够的授权来听取反馈和做出改变，无论多么试探性，你都会走上正轨。

您已经确定的所有其他实践都是消除特定类型废物的技术 - 例如，编写单元测试，以减少项目后期修复缺陷的浪费。通过举办回顾会，您将了解这些废弃物并为人们提供一个空间，让他们决定更专业地做事。

最后，它是关于自尊的：你的，你的同事，以及整个组织。你是否满足于一如既往地糊里糊涂，或者你是否想尽可能地做你所做的事情？

祝你好运！