Dej*_*jan 8 agile project-management scrum
我已经阅读了敏捷宣言,并花了一天的时间浏览网页,寻找这个难以捉摸的答案.但遗憾的是,我没有得到涵盖所有基础的答案.
在观看敏捷传教士的所有博客文章和新闻广播时,您只需了解开放范围或开放"时间"项目.您如何将此应用于修复成本项目？
从我发现的最大的问题是范围管理.您如何确定某些内容是否在预计的范围内？您如何为您的决定制定论据？由于您实施软件的敏捷方式,没有详细的设计可供争论.在大多数情况下,您只有一个模糊的愿望清单,客户会向您提供.并且非常通用,您可以将任何功能解释为其中.
随着固定成本项目比例的上升,这对我来说是一个真正的问题.
所以问题是:
Pas*_*ent 11
对我来说,关于敏捷和固定价格的简短回答是你不能这样做,至少不是固定范围.
我知道有些人会说" 那不是真的,我们正在这样做 ",但是,在充分尊重的情况下,我不认为他们真的在做敏捷,我会解释原因.实际上,解释非常简单:固定价格意味着固定的范围,并且基于可预测性,其中敏捷是关于可变范围,范围管理和适应性的.所以具有固定范围的固定价格基本上与敏捷相反.
使用敏捷方法,固定价格可为您提供针对给定团队规模的多次迭代.在这些迭代期间,客户将能够让团队首先构建最有价值的功能,从而最大化生成的业务价值.当迭代的成本大于生成的值时,整个想法就是停止迭代.这就是敏捷的工作原理.
因此,当人们说他们以灵活的方式确定固定价格的固定价格时,他们实际上会引入一些与敏捷理论并不完全兼容的约束 - 比如对一组特定功能进行前期估计并冻结这些特征和估计 - 他们失去了敏捷的重要优势(除非他们对技术和业务领域有完美的了解,并掌握足够的知识来预测一切,但我知道很少有类似的项目).
无论如何,这是各种敏捷合同的良好汇编:下一个敏捷软件项目的10个合同可能会有所帮助.但我认为它们都需要对客户进行一些教育,特别是那些用于定价固定价格(以及延迟交货)的客户.
Scrum不会取代有适当的要求,甚至不会有偶尔的主要版本或里程碑.相反,它为您提供了一种方法,可以让您的团队保持高效和专注,并避免瀑布流程浪费时间的副作用.
事实上,如Scrum敏捷过程的最大优势之一是,它使你在你的项目的问题区域"快速,大声失败".如果在几次冲刺之后,您的团队仍然无法有效地估算实施特定功能所需的时间和资源,那么可能值得推迟该领域的要求 - 可能需要澄清,简化,或完全报废.然而,在传统的瀑布过程中,这些"问题特征"通常可以被推回到最后一分钟,从而导致大多数项目下放的通常的死亡和交付不足.
但是,在使用具有大量需求的Scrum的团队中,产品负责人的角色更为重要.留给他们自己的设备,大多数开发团队将首先关注最有趣/有趣/令人讨厌的功能(服务API,缓存,搜索),并留下"混乱"的东西,如支付流程,用户体验设计和i18n直到最后一分钟.强大的用户语音对于确保对最终用户至关重要的功能获得公平的关注至关重要.