xp与传统良好的项目管理[关闭]

在我听说XP之前,我有一个很好的经理(迈克),在我早期的工作中。他习惯于管理工程师,转而管理软件。在经历了几次糟糕的工作之后,我回顾了他与我之前和之后的典型项目管理相比的风格。

• 每天至少和每个人见面一次,但给了我们工作的空间
• 使用一个有两个栏的白板,人们在工作,他们在做什么,任何人都可以看看那个白板,看看是否做了什么或正在做什么。
• 让每个人都过火车。我学习了rcs和cvs,以及如何使用make文件
• 在任务完成时运行生产性的“死后”。他会问这样的问题:“如果x有帮助吗?”或者“下次,我们能试着…”
• 让每个人都在做短任务,管理好我们的时间,所以我们总是在做一些事情,但从来没有堆积如山的东西。

迈克把一切都写在纸上了。他会随身携带笔记本和索引卡。他坚持认为,管理层向他提出的任何要求都应转化为可管理的任务,通常写在便签上。他拒绝让任何人做任何无法清楚解释或目标明确的事情。他会问副总裁“你说的更快是什么意思?”报告要显示哪些指标?“为什么要优先考虑?”他似乎有无限的耐心写出需要做的事和“完成”的意思。

当我第一次读XP书的时候,我惊讶地发现“迈克的工作方式”是如此的熟悉。

敏捷似乎只是实现一组最佳实践,并评估它们在您的环境中是如何工作的。当它们不工作时,改变它们。当他们工作的时候,坚持住。

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

如果一个人声称自己在节食,却不能回答他们在吃什么或如何运动的问题,你会接受他们确实在节食吗?

你走的时候带着你的旧行李。这意味着你以前的任何项目管理不好的做法仍然会持续下去。

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

我以前在工作中使用过(稍微修改过)scrum,下面是我的想法:

• 每天的会议和烧毁提供了在任务上取得进展的动力。
• 我们的经理可以和池塘边的同事交谈,向他们展示“这是我们这个月的工作内容。”
• 你确切地知道你需要完成哪些任务,并且已经估计了完成所需的时间。
• 当优先级发生变化(新任务、添加了重要的bug)时,有一个定义良好的流程来处理将它们添加到sprint中,或者简单地将它们推到积压工作中。

这些是很好的答案,但我认为每个人都把项目管理与开发/设计方法混淆了。

我在一个几个月前开始Scrum的团队中,我们似乎正在以更快的速度完成工作,而且“浪费”更少(废弃的项目)。只是我从我们小团队(4个开发人员)的观察。

我发现向敏捷/xp实践的整体转变是非常积极的,在许多方面它将质量提前加载到项目/开发过程中。你需要管理层和团队的支持才能真正看到成功……一些建议:

• 用一个小项目(2-3人)尝试任何更改
• 了解当前团队最能改进的领域(质量?生产力?上市时间?)将一些敏捷/xp/scrum(what ever)流程合并到……不要同时将它们合并到一起,并理解在任何更改之前哪些流程解决了哪些问题。
• 如果可能的话-跟踪那些你想要改变的领域,并与同时运行的另一个项目进行比较(仅仅关注改善某件事情的重点就足以改善它,对此有一个研究/术语,但我忘了它是什么)
• 有时,当你开始一个新的过程时,你会看到性能下降,这是学习曲线的一部分。
• 不要以为今天的一个好的改变明天仍然是一个好的改变,总是回顾你的项目领域,随时准备改变任何过程。
• 没有任何变化永远是好的,就像重构代码、重构流程一样。
• 确保你得到团队和管理层的认可,你不能强迫成功。

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

两者都可以工作,二者的混合也可以,这是我发现对我的团队最有效的。我已经实现了增量开发,它确实帮助了我们;迭代开发有点困难,我们仍在努力。然而,我们有各种各样的参与者,并且我们的许多利益相关者(和PM)更喜欢传统的工件和里程碑。所以我们必须不断找到正确的平衡。

我还发现,比方法论更重要的是实施它的人。好的人会找到一种方法去做好的工作并完成事情,不管方法论是什么,尽管方法论肯定会对效率(和士气)产生影响。然而,排列不好的资源可以使用最好的方法,并找到方法来提供较差的结果。

对于开发人员来说, xp&co.的重要经验是更短的发布周期,以及一种更为进化的方法——从某种意义上说,需求的变更被认为是任何项目的自然组成部分。此外,客户建议解决方案,但设计师和开发人员需要了解问题。

管理者的经验教训: 开发人员不是可交换的规范到代码转换器,他们各自的优点和缺点可以使给定主题的生产率差异达到10或更多。知识和经验是团队中最有价值的技能,开发人员可以教授每一个oterh。经理不需要 理解 开发人员为强制执行所需结果所做的操作。

xp&co.通常将这些问题的解决方案与 改变公司 . 英勇的XP顾问单手挽救了一个注定要失败、延误和脱轨的项目,这在很大程度上起到了开发和管理之间的缓冲作用。但是如果你在看要学什么,你必须把这些方面分开。

最近几年我学到的是,虫子不是一种人格缺陷,当规格改变时,天空不会塌下来。我知道,尽管设计错误仍然是最昂贵的,但没有一个“完美”的设计。我们不需要做一件正确的事情,我们需要实施所有细节都不会出错的保障措施——我已经学会了在“正确”和“不错误”之间留出余地,以利我们的利益。

我的经验是,比起传统的方法,我更喜欢使用Scrum,因为在一个项目的长度上,需求并没有经常发生变化,在这个项目的长度上,项目通常比我目前的一年多的项目至少运行6个月。

也可能是没有任何项目管理的情况,每个人都只是为了“让它工作”,所以有一些正式的结构是无益的。有一个问题是,团队如何团结在一起,自我很少出现,因为它不是某人的代码,而是团队的代码,有一种团队思考,当每个人都有自己的观点时,没有人试图让其他人看到这样的事情。

在我看来,有时我使用的一些Scrum和敏捷方法最终会变成急流而不是大瀑布。我的意思是,收集需求-分析和设计-实施-测试-部署和获取更新的需求的周期似乎反复出现,因此在项目开始时,最终的结果将非常难以说明,除非项目发起人能够给出非常详细的需求,而这些需求永远不会出现。安格