project-management - 是否有过程气味之类的东西？

Question

关闭。这个问题是opinion-based .它目前不接受答案。












想改善这个问题吗？更新问题，以便可以通过 editing this post 用事实和引文回答问题.

2年前关闭。




Improve this question




我们一般都熟悉 code smells在这里，但是当事情的业务方面——尽管它属于我们的领域——出现问题时，同样具有破坏性，如果不是更多的话。

例如，Joel 测试中任何事物的反面都将被认为是主要的过程气味(即没有源代码控制，没有测试人员)，但这些都是明显的，“气味”的重点是它们很微妙，并且会形成破坏性的东西.我在这里寻找粒度。

首先，这里有几个(随着答案的出现，它们可以变成一个列表)

在与客户签订契约(Contract)之前编写代码

被要求对需要超过一天(几个小时？)的任何事情进行即时估计(“只是一个粗略的估计”)

古老的 cargo 崇拜智慧盛行(个人例子 - VisStudio sourcesafe 集成被禁止)

您已经停止召开非项目特定的小组 session (或缺乏任何类似的讨论论坛)

那么还有哪些其他过程气味，它们有多糟糕？

Answer 1

威廉 J. 布朗 (William J. Brown) 等着的书“Antipatterns”。阿尔。有一堆与项目相关的气味。它们并不总是在发生灾难；几乎任何气味都存在缓解情况。

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

Analysis Paralysis - 一个由其他聪明且善意的分析师组成的团队进入分析阶段，该阶段仅在项目取消时结束。

Give Me Estimates Now - 客户(或 PointyHairedBoss)在您有足够的数据来交付之前要求进行估算。您接受“挑战”并给出头部估计(即猜测)。然后，客户/老板将估算视为铁定的 promise 。

Ground Hog Day Project - 举行的 session 似乎一遍又一遍地讨论相同的事情。在上述 session 结束时，做出“必须做些什么”的决定。

Design By Committee - 考虑到没有人有足够的影响力来展示系统设计并获得批准的政治环境，您如何完成设计？成立一个大委员会来解决这个问题。让他们在自己之间进行战斗，最终拿下任何结果。

把它们都收集起来! :-)