我已经在 IT 行业工作了 10 年，但曾在“传统”管理的项目团队（管理良好和管理不善的项目团队）中工作。
我听说过“新”scrum 或 XP 类型的项目管理，并渴望成为其中的一员（作为软件人，我们总是喜欢我猜的任何新事物）但没有机会。
我的问题是——你在转向“新”方式方面的经验是什么——是明显更好还是更糟，或者没有任何不同？使用 XP 开发方式是否有任何项目成功率的提高，或者与任何管理良好的传统项目一样？
这不应该是一个政治问题，而应该只是你搬到新世界或至少经历一次来回的经历。
提前致谢
9 回答
12
在我听说 XP 之前，我有一个非常好的经理（迈克）在我早期的工作中。他习惯于管理工程师并过渡到管理软件。在经历了几次糟糕的工作经历后，我回顾了他的风格与我与他合作前后的典型项目管理。
- 每天至少与每个人见面一次，但给了我们工作的空间
- 使用了一个有两列的白板，人们正在工作以及他们正在做什么，任何人都可以查看该白板，看看是否已经完成或正在完成某些事情
- 让每个人都交叉训练。我在那里学习了 rcs 和 cvs 以及如何使用 make 文件
- 当一项任务完成时，运行富有成效的“死后”。他会问诸如“如果 X 会有帮助吗？”之类的问题。或者“下一次，我们可以试试……”
- 让每个人都做短期任务并管理我们的时间，所以我们总是在做一些事情，但从来没有堆积很多东西
迈克在纸上做了所有事情。他会随身携带笔记本和索引卡。他坚持把管理层对他提出的任何要求都转化为易于管理的任务，通常写在记事卡上。他拒绝让任何人从事任何无法清楚解释或没有明确目标的事情。他会问副总裁“更快是什么意思？” “报告旨在显示哪些指标？” “为什么这应该是优先事项？” 他似乎有近乎无限的耐心来写出需要做什么以及“完成”是什么意思
当我第一次阅读 XP 书籍时，我惊讶于“迈克的工作方式”如此熟悉
敏捷似乎只是实施一组最佳实践并评估它们在您的环境中的工作方式。当它们不起作用时，改变它们。当他们工作时，坚持他们。
我认为传统项目管理的真正问题在于，它通常并不真正存在。令我惊讶的是，有多少商店声称使用 RUP 或 Code Complete 甚至是敏捷，但实际上并没有任何可识别的项目管理。当然，有会议。人们称为项目经理。但是问一个简单的问题，比如“项目 X 做了什么”或“项目 Y 还剩下什么”，没有人有答案。他们必须挖掘电子邮件或指向一个可笑的不准确的 MS 项目文件。
如果一个人声称正在节食，但无法回答有关他们正在吃什么或如何锻炼的问题；你会接受他们真的在节食吗？
于 2009-08-10T16:01:06.190 回答
2
你去的时候带上你的旧行李。这意味着您之前的任何项目管理不良做法仍然会持续存在。
但是，我会说，当我们开始关闭我们和客户之间的循环时，情况有了很大的改善。与客户进行更多和更频繁的反馈和原型设计意味着客户说“这不是我想要的”的时间要少得多。
于 2009-08-04T15:14:19.700 回答
2
我之前在工作中使用过（稍微修改过的）Scrum，以下是我的想法：
- 每天的会议和燃尽为在任务上取得进展提供了动力。
- 我们的经理可以与池塘对面的同事交谈并向他们展示“这就是我们这个月正在做的事情”。
- 您确切地知道需要完成哪些任务，并且已经估计了完成所需的时间。
- 当优先级发生变化（新任务，添加重要错误）时，有一个明确定义的流程来处理将它们添加到 sprint 或简单地将它们推到积压工作。
于 2009-08-04T15:25:14.910 回答
1
这些是可爱的答案，但我认为每个人都将项目管理与开发/设计方法相混淆。
于 2009-08-15T05:40:58.327 回答
0
我在一个几个月前开始 Scrum 的团队中，我们似乎可以更快地完成工作，并且“浪费”（被废弃的项目）更少。只是我对我们小团队（4 个开发人员）的观察。
于 2009-08-04T15:17:05.437 回答
0
我发现向敏捷/XP 实践的整体转变非常积极，在很多方面它都将质量优先加载到项目/开发过程中。您需要管理层和团队的支持才能真正看到成功……一些建议：
- 用一个小项目（2-3 人）尝试任何改变
- 了解您当前的团队可以最大程度改进哪些领域（质量？生产力？上市时间？）并将一些敏捷/XP/Scrum（曾经有过的）流程纳入其中……不要同时将它们全部纳入并了解哪些流程在任何更改之前解决了哪些问题
- 如果可能的话 - 跟踪您希望更改的那些区域并与同时运行的另一个项目进行比较（仅仅关注改进某些东西通常就足以改进它，有一个研究/术语，但我忘记了它是什么)
- 有时您会在开始新流程时看到性能下降，这是学习曲线的一部分
- 永远不要假设今天的好改变明天仍然是好的改变，始终审查您的项目领域并随时准备改变任何流程
- 没有任何改变永远是好的，就像重构代码，重构你的流程
- 确保你得到团队和管理层的支持，你不能强迫成功
于 2009-08-05T13:29:41.137 回答
0
我喜欢敏捷方法所做的一些事情，但我也重视传统方法所做的一些事情。
两者都可以工作，两者的混合也可以，这是我发现现在最适合我的团队的方法。我已经实施了增量开发，它确实对我们有帮助；迭代开发有点困难，我们仍在努力。然而，我们有各种各样的组成部分，我们的许多利益相关者（和 PM）更喜欢传统的工件和里程碑。因此，我们必须不断找到正确的平衡点。
我还发现，比方法更重要的是实施它的人。优秀的人会找到一种方法来做好工作并完成工作，而不管方法论如何，尽管方法论肯定会影响效率（和士气:)）。然而，不协调的资源可以使用最好的方法并找到提供糟糕结果的方法。
于 2009-08-06T15:44:16.750 回答
0
对于开发人员而言， XP & Co. 的重要教训是更短的发布周期和更进化的方法——从某种意义上说，需求的变化被认为是任何项目的自然组成部分。此外，客户提出解决方案，但设计人员和开发人员需要了解问题。
给管理者的教训：开发人员不是可交换的规范到代码的转换器，他们的个人优势和劣势可以使给定主题的生产力差异达到 10 或更多。知识和经验是团队中最有价值的技能，开发人员可以互相传授。管理人员不需要了解开发人员为了强制执行预期的结果而做了什么。
XP & Co. 通常将这些解决方案与问题混合在一起，以使公司发生变化。英勇的 XP 顾问一手拯救了一个注定失败、延迟和脱轨的项目，在很大程度上充当了开发和管理之间的缓冲。但是，如果您正在研究要学习的内容，则必须将这些方面分开。
近年来我学到的是，错误不是性格缺陷，而且规格变化时天也不会塌陷。我了解到，虽然设计错误仍然是最昂贵的，但没有一个“完美”的设计。与其把一件事做对，我们需要实施保障措施，确保所有细节都不会出错——而且我已经学会利用“正确”和“正确”之间的余地来发挥我们的优势。
于 2009-08-10T16:33:46.063 回答
0
我的经验是，我更喜欢使用 Scrum 而不是传统方法，因为在一个项目的整个过程中需求可能保持不变的情况并不经常发生，通常项目似乎运行至少 6 个月，而我目前的项目已经超过一年.
也可能没有任何项目管理，每个人都争先恐后地“让它工作”，所以有一些正式的结构总比没有好。有一个问题是团队的团结程度如何，自负很少出现，因为它不是某人的代码，而是团队的代码，并且有一种集体思考，虽然每个人都有自己的观点，但没有人试图让其他人以这种方式看待事物。
有时在我看来，我使用的一些 Scrum 和敏捷方法最终会像急流而不是大瀑布。我的意思是，收集需求 - 分析和设计 - 实施 - 测试 - 部署和获取更新需求的循环似乎一遍又一遍地重复，因此最终出现的内容在开始时很难说明除非项目发起人可以给出永远不会改变的非常详细的要求。
于 2009-10-30T21:45:53.940 回答