XP vs传统的良好项目管理

Question

我已经在IT行业工作了10年，但他曾在“传统”管理的项目团队（管理良好和管理不善的团队）工作。

我听说过“新”scrum或XP类型的项目管理，并渴望成为其中一员（作为s / w人，我们总是喜欢任何新的东西）但是没有机会。

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

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

提前致谢

Answer 1

在我听说过XP之前，我有一位非常优秀的经理（迈克）。他习惯于管理工程师并转向管理软件。在经历了一些糟糕的工作经历之后，我回顾了他的风格与我之前和之后的典型项目管理。

• 每天至少与每个人见面，但给了我们工作的空间
• 使用带有两列的白板，工作人员和他们正在处理的人可以查看该板，看看是否已经完成或正在进行的工作
• 让每个人都过火车。我在那里学习了rcs然后cvs以及如何使用make文件
• 任务完成后，高效率的“post mortum”。他会问“如果X会有帮助吗？”或“下一次，我们可以尝试......”
• 让所有人都从事短期任务并管理我们的时间，所以我们总是在做一些事情，但从未有过大量的东西堆积起来

迈克在纸上做了一切。他会随身携带笔记本和索引卡片。他坚持认为，管理层要求他的任何事情都要转换成可管理的任务，通常写在便条卡上。他拒绝让任何人从事任何无法明确解释或有明确目标的事情。他会问副总裁“你的意思更快？” “报告要显示哪些指标？” “为什么要优先考虑？”在撰写需要完成的工作以及“完成”的含义时，他似乎几乎有无限的耐心

当我第一次阅读XP书时，我对“Mike工作方式”的熟悉程度感到惊讶

Agile似乎只是在实施一套最佳实践并评估它们在您的环境中的工作方式。当它们不起作用时，请更改它们。当他们工作时，坚持下去。

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

如果一个人声称节食并且无法回答有关他们正在吃什么或他们如何锻炼的问题;你会接受他们真的节食吗？

Answer 2

你去的时候随身携带旧行李。这意味着您之前的任何项目管理不良做法仍将存在。

但是，当我们开始关闭我们与客户之间的循环时，我会说事情有了很大改善。与客户进行更多，更频繁的反馈和原型设计意味着客户说“这不是我想要的”。

Answer 3

我在工作之前使用过（略微修改过的）Scrum，这是我的想法：

• 每日会议和焚烧都为完成任务提供了动力。
• 我们的经理可以与整个池塘的同事交谈并向他们展示“这就是我们本月正在努力的事情。”
• 您确切知道完成所需的任务，并且已经估算完成所需的时间。
• 当优先级发生变化时（新任务，添加了重要的错误），有一个定义明确的流程来处理将它们添加到sprint或只是将它们推送到积压工作。

Answer 4

这些都是可爱的答案，但我认为每个人都会将项目管理与开发/设计方法混为一谈。

Answer 5

我在几个月前创建Scrum的团队中，我们似乎更快地完成任务并且更少“浪费”（项目被废弃）。只是我对我们的小团队（4个开发者）的观察。

Answer 6

我发现Agile / XP实践的整体转变非常积极，在很多方面它都会将质量加载到项目/开发过程中。您需要管理层和团队的支持才能真正看到成功...一些建议：

• 试用小项目的任何变更（2-3人）
• 了解您当前团队可以最大程度提高哪些领域（质量？生产力？上市时间？）并在...中加入一些Agile / XP / Scrum（以及哪些）流程。同时并了解哪些流程可以解决任何变更之前的问题
• 如果可能的话 - 跟踪那些你想要改变的区域，并与同时运行的另一个项目进行比较（仅仅改善一些东西的重点往往足以改善它，有一个研究/术语，但我忘了它是什么）
• 有时候，当你开始一个新的过程时，你会看到性能下降，这是学习曲线的一部分
• 从不认为今天的良好变化将在明天保持良好变化，始终审查您的项目区域并随时准备改变任何流程
• 永远不会有任何改变，就像重构代码一样，重构你的流程
• 确保您从团队和管理层购买，不能强制成功

Answer 7

我喜欢敏捷方法所做的一些事情，但我也重视传统方法所做的一些事情。

两者都可以发挥作用，两者的混合也是如此，这就是我觉得现在对我的团队最有效的。我实施了增量开发，它确实对我们有所帮助;迭代开发有点困难，我们仍然在努力。但是，我们有各种各样的成分，我们的许多利益相关者（和PM）更喜欢传统的工件和里程碑。所以我们必须不断找到合适的平衡点。

我还发现，比实施方法更重要的是人们实施它。无论方法如何，优秀的人都能找到一种做好工作并完成工作的方法，尽管这种方法肯定会影响效率（和士气:)）。然而，不一致的资源可以使用最好的方法并找到产生不良结果的方法。

Answer 8

对于开发人员来说， XP＆amp; amp;有限公司是更短的发布周期和更具进化性的方法 - 从某种意义上说，需求的变化被认为是任何项目的自然组成部分。此外，客户建议解决方案，但设计人员和开发人员需要了解问题。

经理的教训：开发人员不是可交换的规范到代码转换器，他们的个人优势和劣势可以使特定主题的生产力差异达到10或更多。知识和经验是团队中最有价值的技能，开发人员可以教授每个人。管理人员无需了解开发人员为实施所需结果所做的工作。

---

XP＆amp;公司通常会将这些问题的混合解决方案与进行公司变更联系起来。英勇的XP顾问单一地处理了一个注定要失败，延迟和脱轨的项目，这在很大程度上起到了开发和管理之间的缓冲作用。但如果你正在研究学习内容，你必须将这些方面分开。

近年来我学到的是，错误不是人格错误，当规格发生变化时，天空不会下降。我了解到虽然设计错误仍然是最昂贵的，但没有一个“完美”的设计。我们需要实施所有许多细节都没有出错的保障措施，而不是让一件事情变得正确 - 而且我已经学会了利用“正确”和“没有错误”之间的余地来发挥我们的优势。

Answer 9

我的经验是，我更倾向于使用Scrum而不是传统方法，因为通常项目的长度通常项目似乎运行至少6个月到目前的项目时，并不经常发生需求保持不变的情况。一年多了。

也可能存在没有任何项目管理的情况，每个人都只是争抢“使其工作”，因此拥有一些正式的结构是无所不能的。有一个问题是团队如何融合在一起，而自我很少出现，因为它不是某人的代码，而是团队的代码，并且有一种群体思考，每个人都有自己的观点，没有人试图让其他人以这种方式看待事物。

有时在我看来，我使用的一些Scrum和敏捷方法最终会像急流而不是大瀑布。我的意思是收集要求的循环 - 分析和设计 - 实施 - 测试 - 部署和获得更新的要求似乎一遍又一遍地重复，以便最终出现的内容在开头时很难说明除非项目发起人能够提供永不改变的非常详细的要求，否则项目。