XP与传统良好的项目管理

Question

我已经在IT行业工作了10年，但我在“传统”管理的项目团队中工作过(包括管理良好和管理不善的团队)。

我听说过“新的”scrum或XP类型的项目管理，并渴望成为其中的一部分(作为软件人员，我猜我们总是喜欢任何新的东西)，但还没有机会。

我的问题是-你在迁移到“新”方式时有什么经验-它是明显更好还是更差，还是没有什么不同？在使用XP开发方式时，项目成功率是否有所提高，或者与任何管理良好的传统项目相同？

这不应该是一个政治问题，而应该是你的经历，因为你已经搬到了新的世界，或者至少经历了一次。

提前感谢

Answer 1

在我听说XP之前，我在早期的工作中有一个非常好的经理(Mike)。他习惯于管理工程师，并过渡到管理软件。在几次糟糕的工作经历之后，我回顾了他的风格与我在与他共事前后的典型项目管理。

• 每天至少与每个人会面一次，但给了我们工作的空间
• 使用了一个有两列的白板，每个人都在工作，他们正在做什么任何人都可以看着这块白板，看看是否已经做了什么或正在做什么
• 让每个人交叉训练。我在那里学习了rc和cvs，以及如何使用make files
• 在任务完成后进行高效的“事后检查”。他会问这样的问题：“如果X会有帮助吗？”或者“下一次，我们可以尝试...”
• 让每个人都在短任务上工作，并管理我们的时间，所以我们总是在做一些事情，但不会有一大堆东西堆积在

上。

迈克把所有的事都写在纸上。他会随身携带笔记本和索引卡。他坚持管理层对他的任何要求都要转化为可管理的任务，通常写在笔记卡上。他拒绝让任何人做任何不能清楚解释或有明确目标的事情。他会问副总裁：“你说的更快是什么意思？”“报告要显示的是什么类型的指标？”“为什么要优先考虑这件事呢？”他似乎有近乎无限的耐心，能把需要做的事和“做完”的意思写出来。

当我第一次读到XP这本书时，我惊讶地发现“Mike的工作方式”是如此的熟悉。

看起来敏捷只是关于实现一组最佳实践，并评估它们在您的环境中如何工作。当它们不起作用时，改变它们。当他们工作的时候，坚持他们。

我认为传统项目管理的真正问题是，它往往并不真正存在。我很惊讶有多少商店声称使用RUP或Code Complete，甚至敏捷，但实际上并没有任何可识别的项目管理。当然，还有会议。人们称其为项目经理。但是问一个简单的问题，比如“项目X已经做了什么”或者“项目Y还剩下什么要做的”，没有人能回答。他们必须挖掘电子邮件，或者指向一个滑稽的不准确的微软项目文件。

如果一个人声称在节食，但不能回答关于他们吃什么或如何锻炼的问题，你会接受他们真的在节食吗？

Answer 2

你走的时候要带上你的旧行李。这意味着你以前的任何项目管理糟糕的做法仍然会挥之不去。

然而，我要说的是，当我们开始关闭我们和客户之间的循环时，情况有了很大的改善。更多、更频繁的反馈和与客户建立原型意味着客户说“这不是我想要的”的时刻要少得多。

Answer 3

我以前在工作中使用过(稍微修改过的) Scrum，下面是我的想法：

• 日常会议和工作耗尽提供了在任务上取得进展的动力。
• 我们的经理可以与大西洋对岸的同事交谈，并向他们展示“这就是我们这个月要做的”。
• 你确切地知道你需要完成哪些任务，并且已经估计了完成所需的时间。
• 当优先级发生变化(添加了新任务、重要错误)时，有一个定义明确的过程来处理将它们添加到冲刺中或简单地将它们推到积压中。

<代码>F29