是否有过程气味这样的东西?

时间:2009-01-16 20:06:17

标签: project-management

我们在这里一般都熟悉code smells,但是如果不是更具破坏性,那么事情的商业方面 - 尽管它属于我们的领域 - 是错误的。

作为示例,Joel测试中的任何内容的倒数都将被视为主要的过程气味(即没有源代码控制,没有测试人员),但这些是显而易见的,而“气味”的意思是它们是微妙的并且构建陷入破坏性的东西。我在这里寻找粒度。

从这里开始一对(可以在答案进入时将其变成一个列表)


  • 在与客户签订合同之前编写代码

  • 被要求进行即时估算(“只是一个粗略的人会做”)对于任何需要超过一天(几个小时?)的事情。

  • 古代货物崇拜智慧占上风(个人案例 - 禁止VisStudio源安全集成)

  • 您已停止举行非项目特定小组会议(或缺少任何类似的讨论论坛)


那么其他一些过程气味是什么,它们有多糟糕?

10 个答案:

答案 0 :(得分:20)

William J. Brown等人的书“Antipatterns”。人。有一堆与项目有关的气味。它们并非总是在发生灾难;几乎任何气味都存在缓解情况。

Portland Pattern Repository还有一个关于Antipatterns的页面,涵盖了许多与“Antipatterns”一书相同的主题。访问http://c2.com/cgi/wiki?AntiPatternsCatalog并向下滚动到“管理反模式”。几个例子:

  • Analysis Paralysis - 一群智慧和善意的分析师进入分析阶段,只有在项目取消时才会结束。
  • Give Me Estimates Now - 客户(或PointyHairedBoss)在您有足够的数据提供之前需要估算。你接受“挑战”并给出头部估计(即猜测)。然后,客户/老板将估算视为铁腕承诺。
  • Ground Hog Day Project - 举行会议似乎一遍又一遍地讨论相同的事情。在上述会议结束时,决定“必须做某事。”
  • Design By Committee - 鉴于一个政治环境中没有一个人有足够的影响力来展示系统的设计并获得批准,你如何完成设计?组建一个大型委员会来解决问题。让他们在他们之间进行斗争,最后采取任何结果。

全部收集! : - )

答案 1 :(得分:7)

  • 返回约会 - 给出结束日期,然后告诉他们需要完成什么
  • 反向QA覆盖范围 - 质量保证重点关注非必要项目(因为他们都知道如何测试)
  • 环境对齐问题 - 各种环境(开发,测试,分段,生产)与代码和数据不同步 - 因此生产前的任何测试都无效
  • 交货日期分离 - 没有人相信结束日期,因为:它是由一开始就完成的,并且100%以前的项目从未达到过交付日期
  • 旧的脾气暴躁的代码 - 旧代码令人担心,因为没有重构的愿望
  • 邪恶的下三角形(范围,成本,资源和/或质量) - 调整项目需要添加人员,降低质量,缩小范围等......一旦项目开始运行,大多数变化(甚至减少范围)增加时间和成本,降低质量......火车轨道下降,只是左转弯很难

答案 2 :(得分:5)

有一种气味我有一个真正的问题(因为我使用它):不放弃工具,开发软件,方法或其他任何不起作用。

很多时候,有一个(或多个)软件显然,公然,不起作用并可能干扰开发过程,但项目经理只是拒绝更换/升级“因为它会花费太多{时间,金钱,无论如何}来取代。“

编辑:这也扩展到了机器和其他基础设施(例如:构建服务器需要一个小时才能完成两分钟的构建,或者版本控制系统 - ahem CVS - 需要15分钟,找出50MB源树上是否有任何更新)。

答案 3 :(得分:4)

  • 运送原型 - “我们稍后会产品化

答案 4 :(得分:3)

我建议在Organizational上查看维基百科页面的Anti-Patterns部分。我必须处理的是“危机模式”和你提到的“即时估算”。

答案 5 :(得分:2)

当项目在6个月前结束时,您还没有进行项目后审核....

答案 6 :(得分:2)

我见过的一些气味:

  • 乐观的管理,但他们本月无法支付你的工资。这真的很糟糕。我及时离开公司,但几个月后就死了。
  • 极度狂热的团队建设会议。关注公司有多棒。但最终一切都在下降。
  • 好的新人都是因为他们试图改变这个过程。真惭愧。我见过一些真正试图改善公司的人,但旧习惯永远不会消亡,所以它往往以一种巨大的幻想结束。
  • 老板心态永远是正确的......

还有更多,但我不会破坏别人的乐趣。

答案 7 :(得分:1)

对流程的更改是在没有考虑时间安排或当前可交付成果的情况下进行的,然后在可交付成果由于实施新流程而延迟时立即发生逆转。

有人休病假,结果是团队试图接受那个人的工作以及他们自己的工作,当经理或客户或客户销售代表被告知事情会因此被推迟时,他们是只关心事情什么时候会发生,同时你可以在晚上和周末工作,甚至不会询问有紧急情况的人以及他或她在做什么。

当预计会为低级别人员加班时,但是那些急需离职的人会按时离开并且无法回答问题。或者,当他们让你加班加点准备到早上8点,然后不再在质量保证上再看三天。你好,我可以在正常时间做到这一点。

在截止日期之前交付所需文件(例如用于数据导入)或信息分钟,然后在未达到截止日期时指责开发人员。

答案 8 :(得分:0)

我所说的:NIH(流程版),a.k.a。选择你自己的冒险。

证据:

  • 你花了无数次会议来调试这个过程。并重构它。
  • 没有真正完成任务,因为没有人知道他们应该做什么。

我想这是反模式,而不是气味。

答案 9 :(得分:0)

有趣的问题,甚至更有趣的答案。谢谢你们。

我几乎担任过软件开发的所有角色(开发人员,QA,技术主管,项目经理 - 甚至是客户),我可以安全地列出以下气味

  • 团队对新投入的反应速度(以及他们如何接受变革)
  • 通过多少层来完成工作(beaurucracy)
  • 功能/任务有多清楚 - 目标是SMART还是我们有任何KPI。
  • 关于该项目的团队工作有多严重
  • 团队定期会议(每日阅读),讨论成就,目标和问题。

然而,最重要的是,最明显的(对于一个好的鼻子)是所使用的项目管理工具的卫生级别(excel表,纸片,敏捷工具,电子邮件,无论您使用哪种方法)。这是我在评估项目时首先注意到的事情。

  • 我现在知道该项目的立场吗?
  • 我可以告诉(不询问团队)接下来需要做什么吗?
  • 我能告诉团队现在正在做什么吗?
  • 我可以告诉下一个版本是什么时候以及它是否可以实现?
  • 我可以判断客户是否定期更新?
  • 我可以判断客户是否正在批准以及他的反馈是否得到及时处理?
  • 我可以通过查看工程师的项目负载分布来判断吗?

显然,如果您选择任何现代敏捷方法,所有这些都会得到很好的覆盖,但根据市场和工作类型,里程可能会有所不同。因此,保持自己的方法不可知,这是应该摆脱的最低限度的气味。