敏捷并不会鼓励很多预先设计。从需求管理和软件开发的角度来看,这是很好的,并且允许项目适应不断变化的业务需求。
然而,如果你不知道当你开始的时候你要构建什么,你怎么做资源的长远规划呢?哦,当然,你有一个概念模型,你要构建什么,但你没有任何可衡量的细节来判断你需要多少资源来完成这个项目,或者它将花费多少。
对于如何在敏捷环境中进行远程规划,有人有什么建议吗?
发布于 2010-12-28 13:35:23
我刚刚推动我的组织在我们的一个项目上尝试了一种敏捷方法。这对高级管理人员来说是一个挑战,因为他们需要一个预测的预算和时间表,才能获得项目资金(这是一个大型的企业级公司)。
所以,我做了我在那种情况下一直做的事情,做了一个有教养的猜测。我查看了我们假设项目需要的范围,猜测了这些项目的开发时间,为业务分析人员、DBA、项目经理等添加了一些额外的时间,添加了一些填充,并称之为估计的预算。请注意,这种“粗略的数量级”估计是在我的公司在每一个瀑布项目之前进行的,所以没有什么不同。
然后,当我们开始敏捷项目的时候,我们了解了我们的速度,我们根据速度和剩余的故事点预测了项目的终点,发现我们比我最初的高水平估计要高。但这没什么(我们也预料到了)。
所以我想概括一个答案,这取决于你所说的“远距离”,以及当你需要这些估计的时候。如果在项目开始之前需要它们,可以使用我的方法。如果在项目执行过程中需要它们,可以使用Matthew提到的发布计划概念。
此外,我强烈推荐Mike的敏捷评估与规划书,这本书有助于解决这类问题。
发布于 2010-12-27 20:55:14
敏捷有一个“发布计划”的概念。整个团队聚集在一起计划即将发布的版本。我已经提前了2-3个月了。这通常是在产品所有者确定了“最小可行的产品”之后进行的,他们确切地知道要发布该产品必须做些什么。
该团队可以采取已知的故事或史诗故事。史诗是尚未完全定义的大型故事或特征。比如“允许国际支付”。因为这个故事或史诗是如此笼统,估计将是巨大的,并说明这一点。团队可以做一些叫做“t恤”大小的事情,并给每一部史诗“小”、“中”或“大”。这使产品所有者对问题中故事的大小有了一定的了解,并允许scrum管理员对实际发布日期做出一些估计。
关键是开始一些地方,并继续完善故事点或估计,因为更多的信息是已知的。
以下是发布计划的几个链接:
发布于 2010-12-27 20:49:40
试试大卫·艾伦( David )的把事情做好方法论;我记得他的书(关于GTD的第一篇/主要部分)中的一段,他说“长期并不意味着你有很多时间开始这么做”。
GTD帮助您在可操作的条件下进行思考,因此您可以在您自己的系统中规划您可以执行的实际任务或编程操作。简单地说,这是GTD:http://lifedev.net/gtd-cheatsheet/
GTD既适用于生活,也适用于工作,也适用于最短至最长的时间,只要你继续思考行动,而不仅仅是那些让你和/或你的团队担心的事情。如果你没有足够的时间去读这本书,去拿有声读物,那是值得的。
您也可以尝试Scrum (甚至与GTD结合).你列出了一系列的特性,在一个月的开发过程中把它们放在盒子里,最后得到了产品的工作版本。
最后,我建议您阅读Jason的返工,在这里他们谈论了很多关于优先级和一些非常有用的非正式项目规划的概念。
https://softwareengineering.stackexchange.com/questions/30742
复制相似问题