Rat*_*eek 9 agile project-planning project-management
我做了一些相当彻底的阅读和搜索,并没有找到任何关于这个主题,所以希望我不是在创造一个骗局.如果有人问我之前我会欣赏一个链接.
我在一家企业开发商店工作,该商店目前主要使用瀑布流程进行软件开发项目.我已经阅读了很多关于敏捷方法的书籍和文章,我可以看到它中的很多内容可以真正改进我们的流程.我还可以设想如何在开发人员级别应用许多实践,即对编码,更短的迭代,重构,TDD等.我们已经做了很多.
在我的组织中,管理层的头脑中存在的巨大差距是长期规划如何在敏捷过程中发挥作用.在我们开始研究项目之前,我们需要获得内部客户批准的预算,这些预算是为我们正在生产的软件付费的.如果我们不预先做一些相当详细的要求和估算,我们怎么知道预算应该是什么？当然,我们的要求和估计并不完美(有时真的不合适),但它们总比没有好.
一个相关的问题是如何在施工期间判断项目的长期状态.如果一个特定的软件产品对组织来说值一定数量的美元,他们如何知道我们是否能够在我们最终花费超过它的价值之前实施该产品？我可以看出敏捷在确定下一次迭代中你可以做什么工作时的工作原理,但是你如何计算出到1.0版本的工作总和以及你是否可以完成到明年第四季度？
这个战略层面的规划如何在敏捷商店中发生？您是否只是根据您从最初的模糊用户故事开始估算？你不做这种性质的长期规划吗？您是否还有一个前期的高级需求/设计阶段,然后在项目实施后转变为敏捷流程？
谢谢,
〜贾斯汀
使用纯敏捷进行大图规划非常困难.第一个大问题是(正如你所发现的那样)纯粹的敏捷和前瞻性规划(预算,长期时间尺度等)从根本上并不能很好地发挥作用.
如果您熟悉项目管理三角形(范围,成本,时间表),Agile的重点是确定成本和进度并允许范围变化.在大型组织中,范围和时间表通常是固定的(我们需要在下个季度使用具有这些功能的产品X),然后您花费大量时间来讨论成本(即开发人员数量),并且由于时间表和允许的费用还不够.
这就把我们带到了第二个问题 - 在传统的公司环境中运行纯粹敏捷所需的思维方式的改变.理想的建议是让您的组织购买敏捷批发并认识到他们可以构建积压的功能,但并非所有功能都可以交付.然而,交付的将是高质量,准时和已知成本.改变为纯粹的敏捷可以导致组织思维的严重转变,正如Mike Cohen的书中所说的那样专业.
不幸的是,将整个组织的思维从一个项目的后面改变是非常困难的,所以第三种方式是妥协 - 你不做纯粹的敏捷.你做的就像RUP /瀑布,你可以做一些前期需求分析,并做一些设计和架构工作.足以突出风险领域并理解大局复杂性.然后运行迭代"0".
迭代0是高风险领域概念开发的证明,有助于理解关键估计和团队绩效.这可能是一个被扔掉的原型,它可能是你的应用程序框架的基础但重要的一点是要对估计的质量和团队的可能速度有一个基础感觉.这为你提供了构建的基础一些计划并设定了可能的预算.
然后,您可以将开发工作作为正常的敏捷迭代运行,从早期用户反馈和可见性等方面获益.迭代方法还有助于为您提供定期里程碑,以便跟踪计划,允许重新计划点和早期的预算警告超过/不足 - 运行.使用迄今为止的估算/实际值来重新制定未来的计划.