01 | 灵魂拷问:如何利用敏捷思维更好地解决实际问题?
该思维导图由 AI 生成,仅供参考
- 深入了解
- 翻译
- 解释
- 总结
敏捷思维在项目管理中的应用价值是本文的核心内容。作者通过亲身经历的案例详细介绍了瀑布模式和敏捷模式在项目实施中的差异和影响。文章指出瀑布模式存在的问题,并介绍了敏捷模式的优势,包括团队灵活性、需求迭代、客户参与等方面。作者分享了自己在后续项目中应用敏捷模式的经验和取得的成效。通过这些案例,读者可以深入了解敏捷思维的核心理念和实际应用,以及其在项目管理中的价值。文章还提到了一些公司在实践中使用敏捷思想的例子,强调了敏捷思维的普遍适用性。文章内容丰富,案例生动,对于想要了解敏捷思维在项目管理中的应用的读者具有很高的参考价值。文章还提到了敏捷思维的普遍适用性,强调了敏捷思维在VUCA时代的重要性。文章内容丰富,案例生动,对于想要了解敏捷思维在项目管理中的应用的读者具有很高的参考价值。
《说透敏捷》,新⼈⾸单¥29
全部留言(87)
- 最新
- 精选
- 丁丁历险记置顶一定要早点把客户拉下水。让客户早点确认各种细节。这样就不会后期唧唧歪歪了。
作者回复: 赞一个
2020-01-071165 - 李永智敏捷方法使用过,虽然效率有提升,开发理解需求有极大改善,但也做了测试驱动,尽管代价不小,发现有些产品交付质量差,经分析,主要是人员水平造成的,应该是敏捷相比瀑布开发对人员的要求多和高,但现实人员更换受限的情况下,如何提升?或者是我上述的归因有偏差,那问题可能出在哪里,针对这些,有啥应对原则?
作者回复: 这是个好问题,关于人员培养的问题是个永恒的话题。这里面涉及2个方面,一个是态度转变,一个是能力提升。态度转变的话我们其实有很多方法可以让员工有参与感,参与到转型过程中,如后面05会有一些方法,让员工进到我们的转型过程,有参与感,同时也要意识到自己的能力需要提升,这样很多员工都有提升的动力;第二个问题,能力提升的问题方法也非常多,可以组织拆书会等等快速地了解一个领域的知识,也可以互相之间分享,老带新,反讲,建立辅导机制,能力高的辅导能力低的等等,非常多的方法,只要人发动起来,方法总能找得到。最后记住一点是,人毕生都是在发展的,减少对人的刻板印象,鼓励发动他动起来学起来跟上来,这个很重要。
2020-01-071037 - escray我对于,“敏捷确实好,但是推进不容易”这个说法深表认同。如果真的落实敏捷,对于研发人员的要求还是比较高的,对于每个开发的工作会有定性和定量的尺度,上班摸鱼就没那么方便了;对于组织架构来说,可能也需要进行一定的调整,比如作者说的划分小团队,但是更主要的可能还是思想上的变革。 其实如果能够照着一成不变的需求文档或者详细设计来写代码,对于开发人员来说是相对简单的,但是往往做出来的东西,并不是用户真正想要的。 不过从另一方面,如果是类似于火箭发射或者是精密仪器之类的软硬件研发,还是瀑布模式更合适,主要是因为这一类项目的需求规格相对比较稳定。 还有一点,个人感觉其实小团队更容易实行敏捷,主要是比较容易形成共识。 但是现在似乎把敏捷的范围扩展了,只要采用了一部分敏捷的方法,就可以定义为敏捷。 在体制内单位,其中也有项目的外包方采用了迭代开发、滚动上线的方式,也可以说“敏捷”起来了。但是,没有单元测试、配置管理、持续继承、版本控制……这样也可以算是敏捷么?
作者回复: 现实中没有完美的敏捷模式,虽然这是我们一直追求的目标,但大家都走在路上,推进敏捷的方式有激进式的“貌似一步到位”,但其实后面也有很多工作,另一种渐进式的则是解决一个旧问题出现一个新问题,其实一直在做持续改进,有的企业先做了“形式”上的敏捷,后面发现痛点之后继续改进一步一步地推进了更多的技术实践来助力研发
2020-01-07512 - 想想您好,我遇到的问题是: 1.我们采用原型跟用户迭代确认,也形成需求确认书签字确认。但是在具体测试过程中,用户实际使用后,又有新的想法或者原先就考虑完整的,这时也只能继续进行迭代修改。 2.如果存在多个模块处于第1个问题时,因为交付模块一直迭代调整中,导致其他任务无法继续执行。由于成员有限,一个人负责多个模块,就会导致项目工期延期。 所以在后面的项目中为了避免出行这种问题,我们只能回到“原型+瀑布”模式,等到开发结束,再集中精力修改,但是这种模式存在的问题也显而易见。一直没有好的解决方案。 如果迭代一直停留在几个模块,导致其他模块无法执行时,有什么好的解决方案吗?
作者回复: 第一个迭代结束,客户有反馈是可以的也是正常的,关键在于我们接受了反馈后的处理方式。一般我们是把新的反馈加到我们的需求列表中,并按优先级进行排列,下一个迭代继续从需求列表中选取优先级高的继续开发。这样不是所有的反馈都在下一个迭代中满足,就可以防止您的开发一直停留在几个需求上。要管理好需求列表
2020-01-1237 - 王刚老师,请教几个问题: 1.团队拆分为特性小组的标准是什么?多少人为一组为最佳呢? 2.使用敏捷模式,开发前期的接口文档要不要省略呢? 3.业务参与需求分析,是不是就是确定原型图的过程?
作者回复: 第一个问题,我们在04里有一些关于组织的说明,特性团队拆分在敏捷里如上面朋友所说,确实没有固定的死的标准,但有些原则可供你参考。一个是团队大小,是5-9个人,大了要进行拆分;第二个是全功能团队。 第二个问题,文档的留与否,需要根据实际情况来做剪裁,在剪裁前,评估文档为产品开发带来的价值大小和实际工作量,一般而言不建议省略接口文档,接口文档是开发中的重要文档,但如果团队找到了更好的工作方法替代这个文档除外。
2020-01-0754 - 桃子-夏勇杰第一步组建特性团队就是一个难题,这是一个思维方式的转变,改变了开发团队原有的开发习惯和思维惯性。宋老师是如何说服团队做这样的转变的呢?
作者回复: 思维方式转变确实是比较难的,仅靠口头说服是远远不够的,所以除了宣讲以外,我采取的方式有很多:带他们参观已经转型的团队,有一些感性认识;必要的时候带他们打个胜仗,团队在不同阶段需要的辅助也是不同的,还有我们在05团队试点里的一些方法等等重要的是要让他们觉得是他们需要改变而不是“我”作为咨询师或者敏捷推动者让他们改变。
2020-01-0722 - 王刚老师,请教几个问题 1.团队拆分成特性的小组,这个是按照什么标准拆分呢?几个人好呢? 2.使用敏捷方式,那开发前期的接口文档之类的要不要省略呢? 3.让业务参与需求分析的过程,是不是就是确定原型的过程?
作者回复: 第三个问题,确切地说,在敏捷当中,业务不仅仅需要确认原型图。我们希望业务能够更多地参与研发过程,具体来讲,在前期需求创意的时候,我们希望能够跟业务在一起梳理,可以是用设计思维的方式,也需要明确业务价值;在迭代准备中,梳理优先级、确认需求等等;在迭代中,有可以确认的东西,如有能演示的版本等都可以找业务来看看,征求他的意见。说到底,业务与开发测试团队之间目标要绑定到一起,要有及时的反馈,这样敏捷开发的效益最大
2020-01-072 - 冷月宋老师,我想请教个问题。用敏捷迭代做项目,后面做的需求开发迭代时发现前面的之前的需求迭代有很大的问题,这种问题对项目的交期,预算成本控制也有影响呢?因为过程中很多情况客户经常会改需求,前期已经迭代的确认过的需求到后面又改了,这样的事多了,交期感觉很不好控制了,这个问题老师您是怎么处理的呢?
作者回复: 最简单的一个可行的办法是一直与客户确认当前最重要的最有价值的工作,并且让客户了解到我们在有限的时间精力内只做最重要的事情。如果项目是有时间盒限定的,那么到时间盒结束的时候,我们只能做这么多,但做的这些是最重要的。
2020-01-2121 - jsl_mes老师您好,能说一下敏捷和迭代的关系或不同吗?
作者回复: 以前有一个迭代式研发,这种一般是迭代周期不一定固定,只要产品有迭代就可以叫迭代式研发了;而敏捷涵盖的内容比它广。
2020-01-0941 - 新的一页老板常在嘴边说的一句话,要先把系统做出来,能卖,回头再来修改和优化,在我看来,这就是一个敏捷的例子,只是时间长了,产品变成了一个巨复杂的系统,再加上文档不全,开发和业务人员的离职,造成现在每修改一个逻辑要从头到尾读一遍逻辑,很痛苦,现在公司风雨飘摇,也不可能把产品再重新开发一遍,请问补文档和代码持续部分重构可以慢慢改变这个现状吗?还有什么办法可以改变这种情况?望指教!
作者回复: 这是个超级痛苦的问题,也有挺多公司遇到,无论是大公司还是初创公司都有遇到,即便是使用瀑布模型要求写了大量的文档也存在这个问题,原因是文档经常是不时时更新的,很多后期接手的人员非常痛苦,基本都要扒一遍代码。我没有特别好的灵丹妙药,只能告诉团队:这不是敏捷本身带来的问题,但从实际出发有几个问题我们需要来检视一下:第一个,研发过程一定要留有必要的知识库和重要的文档;如果开始开发的时候没有留,后来人来梳理的时候要把梳理成果留下,必要的时候需要补充文件。第二个,巨复杂的系统需要重构,里面的许多逻辑估计已经臃肿不堪了,需要重新梳理。
2020-01-0821