XP vs传统的良好项目管理
我已经从事IT行业已有10年了，但曾在“传统”管理项目团队（管理良好，管理不善）中工作过。我曾经听说过“新”Scrum或XP类型的项目管理，并渴望成为其中一员（因为我们总是喜欢任何新的东西），但没有机会。XP vs传统的良好项目管理
我的问题是这样的 - 你在向“新”方式转变的过程中有什么经验 - 它明显好还是差或者没有什么不同？使用XP的开发方式时，是否有任何项目成功率提高或与任何管理良好的传统项目相同？
这不应该是一个政治问题，而只是你的经历，因为你已经搬到新的世界或经历过至少一次又一次。
在此先感谢
在我听说过XP之前，我有一位非常优秀的经理（Mike）在我的早期工作。他习惯于管理工程师，并转向管理软件。在经历了一些糟糕的工作经历之后，我回顾了他与他一起工作之前和之后的典型项目管理的风格。
- 先后与每个人每天至少一次，但给我们的工作空间
- 使用白板有两列，人们的工作和他们对任何人的工作有什么可以看那个板，看看是否有什么东西被完成或正在完成
- 如果每个人都交叉训练。我学会了rcs和cvs，以及如何使用make文件。
- 任务完成后，可以实现高效的“后期制”。他会问这样的问题：“如果X能帮助吗？”或“接下来的时间，我们可以尝试......”
- 不停大家对短任务的工作和管理我们的时间，所以我们一直在努力的东西，但从来没有一吨的东西堆放
迈克所做的一切在纸上。他会保留笔记本和索引卡片。他坚持要求管理层提出的任何问题都要转化为可管理的任务，通常写在记事卡上。他拒绝任何人从事任何无法清楚解释或明确目标的工作。他会问副总裁：“你的意思是快点是什么？” “报告想表明什么样的指标？” “为什么这应该是一个优先事项？“他似乎有无限的耐心写出需要完成什么以及”完成“是什么意思
当我第一次阅读XP的书时，我很惊讶于有多少被熟悉为”迈克的工作方式“
看来，敏捷只是实施一系列最佳实践，并评估它们在环境中是如何工作的。如果他们不工作，改变他们。当他们这样做的工作，坚持给他们。
我认为，与传统的项目管理，真正的问题是，往往不是，它并没有真正存在。我很惊讶的要求有多少商店使用RUP或代码完成，甚至敏捷而实际上并没有什么识别为 项目管理。当然，有会议。人们称之为项目经理。但问一个简单的问题，比如“项目X上做了些什么”或“项目Y上剩下的事情”，没有人有答案。他们必须挖掘电子邮件或指向一个不太准确的MS项目文件。
如果一个人自称是节食，不能回答什么他们吃或他们是如何行使的问题;你会接受他们真的在节食吗？
你把你的旧包袱与你当你去。这意味着你之前的任何项目管理不良行为仍然会持续。
但是，我会说，当我们开始关闭我们和客户之间的循环时，情况会有很大改善。与客户进行更多更频繁的反馈和原型设计，意味着客户所说的时间要少得多，“这不是我想要的。”
我正在一个几个月前创立Scrum的团队中，我们似乎正在更快地完成任务，而且浪费更少（项目被废弃）。只是我的小团队（4位开发人员）的观察。
我使用（稍作修改）之前的Scrum工作，这里是我的想法：
- 的日常会议和燃尽提供动力做出各种任务的进度。
- 我们的经理可以与池塘里的同事交谈，并向他们展示“这是我们本月正在进行的工作。”
- 您完全知道您需要完成哪些任务，并且已经估计完成所需的时间。
- 当优先级发生变化（新任务，添加重要错误）时，有一个定义良好的进程来处理将它们添加到冲刺中或者将它们推送到待办事项。
回声我自己的经验 – 2009-08-04 15:28:57
我发现Agile/XP的整体举措非常积极，在很多方面它将质量加载到项目/开发过程中。你需要买进于管理层和球队真正看到成功...几点建议：
- 试验用小项目中的任何改变（2-3人）
- 了解什么地方你目前的团队可以最大程度地提高（质量？生产力？上市时间？），并将几个Agile/XP/Scrum（以往）如果可能，请不要将它们全部并入，并了解哪些进程可以解决哪些问题需要更改
- - 跟踪您希望更改的区域，并与同时运行的另一个项目（仅限于改善某些东西的重点足以改善它，这里有一个研究/术语，但我忘了它是什么）
- 有时，当你开始一个新过程时，你会看到性能下降，这是学习曲线
- 永远不要以为今天好的变化明天仍然是一个好的变化，总是检查你的项目区域，并随时准备改变任何过程
- 没有变化永远保持良好，就像refac toring代码，请重构过程
- 确保您获得从团队和管理层收购，你不能强迫成功
我喜欢的一些东西的敏捷方法做的，但我也很看重一些传统方法做的事情。
两者都可以工作，两者的混合物也是如此，这是我发现的最适合我团队的工作。我实施了增量式开发，它确实帮助我们;迭代开发有点困难，我们仍在努力。然而，我们有各种各样的组成部分，我们的许多利益相关者（和PM）更喜欢传统的文物和里程碑。所以我们必须继续找到合适的平衡点。
我也发现比方法更重要的是实现它的人。好人找到一种方法去做好工作，不管方法如何，都可以完成工作，虽然方法可以对效率（和士气:)有影响）。但是，如果资源配置不协调，可以使用最好的方法，并找到提供不良结果的方法。
对于开发商来说， XP &有限公司的重大教训，更短的发布周期，更循序渐进的方式 - 在这个意义上的要求，这一变化被接受为任何项目的一个自然组成部分。此外，客户提出解决方案，但设计人员和开发人员需要了解问题。
经理们的教训：开发人员不是可交换的规范到代码转换器，他们各自的长处和短处可能会使某个特定主题的生产力差异达到10个或更多。知识和经验是团队中最有价值的技能，开发人员可以教导每个人。经理们不需要了解开发人员为了执行预期的结果而做的事情。
XP &公司通常混合解决这些的问题，以使公司改变。英勇的XP顾问单一地保存了一个注定要失败的，延迟的和脱轨的项目，这在开发和管理之间起着缓冲作用。但是如果你在看什么学习，你必须分开这些方面。
我近年来学到的是错误不是个性的过错，当规范改变天空不落。我了解到，尽管设计错误仍然是最昂贵的，但没有一个“完美”设计。我们需要实施所有许多细节都没有出错的保障 - 而且我学会了利用“正确”和“没有错误”之间的回旋带来我们的优势。
这些可爱的答案，但我认为与开发/设计方法大家的困惑项目管理。
我的经验是，我更喜欢使用Scrum，比传统的方法，因为它并没有发生往往是要求可以留一个项目的长度，其中通常项目似乎运行至少6个月，以我目前的一个不变的是超过一年。
此外，还可以的情况下没有任何项目管理，每个人都只是以打乱“使工作”，所以有一些正式的结构是在没事找事。对于团队走到一起的程度和自我很少出现的问题有一些问题，因为它不是某人的代码，而是团队的代码，并且有一种团队认为在每个人都有自己的观点的时候，没有人试图让其他人看到这样的事情。
有时候我觉得有些Scrum和敏捷方法最终会变成急流而不是大瀑布。我的意思是说，收集需求的周期 - 分析和设计 - 实现 - 测试 - 部署和获取更新的需求似乎一遍又一遍地重复出现，以至于最终出现的内容在开始时很难说明项目，除非项目发起人可以提供永不改变的非常详细的要求。
应该是社区Wiki – 2009-08-04 15:28:15
我并不太清楚您所指的“传统良好管理”是什么。我与许多经理人都有不同的定义。 – monksy 2009-10-30 21:48:28