敏捷项目管理(第2版)
使用敏捷的目的是快速完成对企业有价值的事情,以获得反馈。 为什么? 出于多种原因,但第一个原因是您可以更改项目的优先级。 第二个是这样,您可以更改项目组合。 第三是获取您所做工作的反馈。 好吧,如果愿意,您可以交换一,二和三。 对我而言,这是每隔几天至两周要完成的三大原因。 他们在彼此之间处于优先地位。 敏捷就是改变。
这就是每个项目都需要设计自己的完成方式的原因。
如果您只有一个并置的团队,并且知道如何快速交付价值,那么您可能会遇到“ 设计敏捷项目,第1部分”中描述的情况。
当您有更多未知数时会怎样? 如果您的组织“沉迷于”瀑布式和漫长的项目怎么办? 当您因为每个人都不在同一个地方而看不到项目中的人员时? 什么时候您有很多技术风险,例如技术债务? 当您启动程序并且每个人都在过渡到敏捷时,该怎么办(哦,请不要这样做)。 或者,您不熟悉敏捷,也没有培训。 我有一个问题:您是否会在未经培训的情况下在汽车上开车?
重新考虑当项目或组织充满未知数时该怎么办
当您有更多未知数时,让我们讨论设计敏捷项目的原理。 让我们从一个常见的问题开始:一个组织“沉迷”于瀑布和漫长的项目。 而且,他们听说过这种“敏捷”的东西,并且想尝试一下。
如果您听说过Scrum失败的许多地方,那就是经典。 Scrum说:“用这种新文化代替您的旧文化。” 哇,这是一个很大的转变。 如果您查看Cynefin框架,您会发现对于沉迷于瀑布,冗长的项目和高要求的组织而言,它们并不复杂。 他们在复杂。 为什么? 因为他们有太多未知数。
在这些组织中进行评估时,我会看到以下内容:
- 许多多任务处理紧急情况。
- 没有项目组合管理
- 他们的要求如此之大,需要他们forevvveerrr释放任何东西
- 由于它们的需求如此之大,并且它们的发布时间如此之长,因此增加了对紧急情况的需求:补丁,临时发布,消防。
可能还有更多。 这就够了。
在这种情况下,您想看一下Cynefin框架,然后说:“框架的复杂方面怎么说?” 它说我们应该考虑紧急实践。 我们不仅应该考虑现成的解决方案。 我们必须探知-回应。
我们需要完成什么? 在迭代结束时使用可用的软件。 或者,在流动。 我们想要一两天甚至三天的功能。 我们需要完整的功能,而在迭代结束时没有剩余的工作(未完成的功能)。 我们希望能够在迭代之后或在功能之后更改我们要做的事情。 从团队的角度来看,我们如何做到这一点? 让我们忘记标签,专注于团队。
团队可以做的第一件事是什么?
我想问:“ 我们能做什么? ”团队经常问“我们能做什么?” 从这个问题开始会有所帮助。
用小卵石思考,定时工作,尖峰工作,所有这些都有助于学习如何从小做起。
有时,当我们有了故事时,我们不知道如何将它们分解开来,我们会问:“可以增加价值的第一件事是什么?” 也许这是一个好问题。 您可能会问:“团队可以做的第一件事是什么?” 或者,“我们能做的第一件事是帮助我们在一两个星期的迭代中完成工作吗?” 或者,“我们如何完成流程中的功能(看板)?”
对于那些处于框架复杂方面的团队,我通常建议以下几点:
- 启动看板。 您需要查看实际过程。 您需要视觉效果。
- 确定您的工作进度限制,并坚持至少一周。
- 回顾并反思这些限制,您所取得的进步以及随之而来的任何其他事情。 作为团队,你在哪里? 您取得了什么进展? 您要保留,添加或更改什么?
注意这不是开箱即用的敏捷或精益。 这是启动团队从“复杂”团队过渡到“复杂”团队的一种方式。 一旦团队度过了第一周,他们就会迭代,并牢记以下原则:
让我们回顾一下原理:
- 以流程或迭代的方式完成。 为什么? 因为我们要开发工作软件。
- 缩短迭代周期,一到两周。 时间越长越好。 为什么? 该时间太长,无法进行频繁更改。 为什么? 因为我们需要允许项目中的更改。 这样,我们可以获取有关功能的反馈,更改项目的优先级以及管理项目组合。
- 无论您如何合作,都应找到一种以团队方式联系的方式。 如果实时仪式会使每个人由于缺乏睡眠而发疯,那么它就不好了。 为什么? 即使实时仪式是最好的,我们也需要可持续发展。
- 找到一种反映团队精神的方法。 替代反射不好。 为什么? 别人怎么能代替团队中真正发生的事情?
我们现在在哪?
没有人改变角色。 没有人改变文化。 我们正在研究我们的过程,并将其缩小一会儿。 我们正在反思。 所有这些都是为了简化,从复杂到复杂。
记住,我只是讨论了我与并置的团队的工作情况,这些团队在功能过大,瀑布项目过长以及紧急情况方面遇到了问题。 我还没有解决分布式团队的问题。 他们是下一个。
我希望您在我们进入第3部分时与我在一起。
翻译自: https://www.javacodegeeks.com/2014/04/design-your-agile-project-part-2.html
敏捷项目管理(第2版)