5

If so, how do you deal with things that just don't "feel" right such as:

  • not writing unit tests
  • not having a continuous build
  • not refactoring
  • not having a team coding standard
  • not pair programming
  • not doing iterations
  • no daily standups
  • no retrospectives

Now, some agile organizations do leave out some of these practices, but most successful ones incorporate most of them.

What do you do to deal with the seeming chaos of the traditional development processes?

4

6 回答 6

13

Actually, I'm a Waterfall developer in an Agile organization.

Things that don't "feel" right to me include:

  • Starting work on a project with barely any idea what it should do.
  • Documenting the processes, but not the products; being unable to get information without having to go talk to someone. All I should need is a Requirements document, a Design document (which I may write myself), and Google.
  • Spending more time in meetings than coding.
  • Spending more time coding at home than at work.
  • Having no idea when the project will be done.
  • PM's being useful in any way.
  • Having a meeting to prepare for a meeting to prepare for a meeting where somebody else logs onto a server and copies a file; thus spending six hours on a process that takes six minutes
  • Multiple checkouts
  • Knowing how something should flow, but not having actual requirements.
  • Developers' unique skill sets are downplayed or outright ignored as they make the developer non-interchangeable.
  • When there are no stories remaining... nothing to do... just kinda sit there... Could be adding a new feature; may not be needed but the time isn't being wasted...
  • Every six months when I change contracts, I have to adapt to a new coding standard? By the time I get used to it, I'm already looking for my next contract.
于 2008-10-25T05:54:53.363 回答
2

不要陷入“抱怨”模式。我会选择回答问题的“处理它”部分。根据我的经验，我已经达到了以下选项

  1. 稍微简单的方法：退出并找到一个更适合您的地方......我说有点容易，因为杂项。子问题：您附近可能不存在“敏捷”工作场所。搬迁可能不是可行的方法，敏捷工作场所中的人可能是“不敏捷”的，
  2. 中路：个人继续敏捷。帮助和教其他感兴趣的人..也许是组织。会慢慢变好。希望最好的，祈祷你不要达到“不归路的退出点”
  3. 超级困难的方法：努力为您的组织带来变革。这不是每个人的一杯茶。一个组织的文化不可能在短时间内改变……你需要一个管理中的“本地赞助商”来开始任何实质性的事情。再加上这样一个事实，即除了你自己，你无法真正改变另一个人。因此，如果你充满激情、耐心、坚持不懈、高度乐观并愿意全力以赴，我会全心推荐“无畏变革”。（来源：informit.com）
    替代文字
于 2008-10-25T06:29:35.057 回答
2

Why are these practices incompatible with waterfall? As far as I can tell almost all of these if not absolutely all of them are possible with a waterfall approach. There is no particular reason waterfall development has to be chaotic. It may have other drawbacks/challenges but chaos is not likely to be high on the list.

于 2008-10-25T05:41:30.817 回答
1

说真的，如果你的组织像你描述的那样混乱和业余，我会在他们倒闭之前开始寻找另一份工作。正如马丁·福勒曾经打趣的那样

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

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

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

归根结底，这是关于自尊：你、你的同事和整个组织的自尊。您是否满足于只是按照以往的方式糊弄过去，或者您是否想尽可能地做好自己的工作？

祝你好运！

于 2008-11-21T08:45:24.767 回答
1

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

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

于 2008-10-25T06:20:47.133 回答
1

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

  • 不编写单元测试：我相信 100% 的覆盖率。是的，很容易说你可以拥有 100% 的覆盖率并编写非常糟糕的测试，但是，我编写的任何新代码，我都会尽我所能进行验收或集成测试，并对我所做的工作有 100% 的覆盖率。在构建中，我进行了覆盖检查以确保它不会低于当前限制。
  • 没有连续构建：由于每个人之前的工作方式，大多数人在没有覆盖检查的情况下运行构建，因此可以在没有测试的情况下随意检查他们喜欢的任何内容。更不用说连续构建有时似乎开启，有时似乎关闭。我非常接近建立自己的 CI 盒。
  • 不重构：我尽我所能重构，所以当我再次看到同一个类时我不会呕吐。
  • 没有团队编码标准：公司有编码标准，但是它有很多问题。因此，我尽我所能与更高层的人一起提出问题以改变它。有时以他们认为正确的方式编码会很痛苦。例如，在整个文件中为公共、私有、受保护、字段、常量等放置巨大的 java 注释部分标题。我相信这是从前完成的，因为类变得如此失控（例如数千行长）以至于它们需要节标题，以便您可以找到公共方法的开始位置和私有方法的开始位置（！！）
  • 不结对编程：幸运的是，我身后有一个跟我想法一样的人，我们尽可能多地转动椅子来交谈和讨论想法以弥补。
  • 不做迭代：我们有 3 周的迭代，但感觉非常临时。每次迭代之间都有一个清理/审查周，这使得它理论上是一个 4 周的迭代。我对此无能为力。很难说服他们缩短这些迭代时间，因为代码太糟糕了，实际上需要3 周来编写本应该只需要 1 周的东西。
  • 没有每日站立：我们有站立。
  • 没有回顾：我们有回顾。
于 2008-10-25T07:35:56.857 回答