新闻

NEWS

这些工作中的困惑【98%的人都在问】,答案看这里!

时间:2020-09-03 15:05:43


观看:127

  上周举办的【现代卓越敏捷超车训练营】反响强烈,

  很多同学都表示学不完也问不够,

  这次,小编整理了敏捷训练营中的精华帖送给你,

  这回别嚷嚷着错过一个亿了哦!

  妥妥的直接上干货,认真读仔细看!

  问题:什么样的项目不适合用敏捷?或者使用敏捷有哪些限制条件吗?

  现代卓越辅导老师周老师:

  这个问题我之前也无数次的问自己,10年前,业界的论调是对安全要求较高的行业不适合敏捷,如军工,航空航天,金融银行。但是到了今天,你会发现很多行业都已经部分或全部引入敏捷实践。就连车企也已经部分引入敏捷实践。所以考虑敏捷的适用性需要回到业务目标的角度来考虑,从组织的业务层面为什么要引入敏捷,引入敏捷的目的是什么?

  敏捷的业务目标是更快(早)地交付价值;更灵活的响应变化,这其实是和现在的项目实情相契合的,也可以说是时代发展的必然。敏捷框架的很多方法就是为了实现业务目标而出现的方法,比如:迭代模式下,如何更有效地需求澄清和验收过程?那么实例化需求,行为驱动开发就可以使用;如何管理迭代开发过程?那么你可以采用Scrum,Kanban的方法等等。

  所以我现在的看法是,在现在的VUCA时代中,针对组织想要解决的问题,一定有可以适用的敏捷实践让你豁然开朗。比如,现在的持续集成已经被很多企业所采用了,这是为了解决迭代,快速交付带来的不断增大的集成和回归测试验证过程而引入的敏捷实践。

  第二个问题也是一样的,敏捷的实践落地需要结合公司的实际情况,但是重要的是回到敏捷想解决的问题上,但是敏捷的引入一定是从上至下的,所以需要公司层面的推动和支撑。因为表面上看是一个实践的引入,但是背后影响的可能是一个系统的运转,所以如果想要敏捷方法运转起来,来自公司层面的支持是需要的。

  问题:个人理解,拥抱变化,是说的快速迭代,比较适用于互联网快节奏,比如说电商,业务方提出一个需求,快速做出一个小样(甚至不用开发),如果需求被业务方确认,再进行深度开发和测试,如果业务方觉得需求得不到满足,就再快速迭代出一个小样,所以不太涉及范围和成本。

  现代卓越辅导老师周老师:

  你说的没错,确实敏捷更适用于短、频、快的互联网产品开发。原因是因为他们的产品可以直接面向客户,得到客户的反馈。无形中形成了敏捷运行的闭环,频繁交付,快速验证,快速试错。而为什么有些行业只能部分引入敏捷实践,就是由于上下游相关方众多,从系统到硬件、总集成商等等,所以快速验证很难做到,效率竖井明显,比如车企,它们从去年开始也在尝试在软件层面部分实施敏捷了。

  敏捷项目因为采用的是迭代交付,所以迭代中的时间和成本是固定的,但是交付的范围是可以改变的,遵循价值驱动的原则。

  问题:在做快速迭代,如果没有范围控制,那不就是失控了,尤其在一般类型项目,成本固定的情况下。拥抱变化,在敏捷里更是说明实现用户期望的商业价值,举例来说,如果跟用户签了一个简装修的合同,项目不断拥抱变化,最后搞成精装修了,这个怎么办?

  现代卓越辅导老师周老师:

  问题提得真好,我的理解是这样的,欢迎交流。

  虽然使用了敏捷,但是前期的SOW,还是需要签订的,SOW中规定了我们的工作圈在哪里,我们的工作范围是什么,如果在实施过程中出圈了,一定是要另签合同的。

  那么敏捷里的拥抱变化是啥意思的?因为在传统的无论CMMI还是Aspice模型中都会有需求基线的概念,就是需求Freeze的意思,那么在需求基线建立后,任何需求的变更都要走变更控制流程。问题是现在客户实际上也不是很清楚具体的需求,需求是随着项目的不断推进,不断地被澄清,逐渐清晰的。也就是不可能一下子就Freeze。所以,敏捷没有变更控制的概念,它是拥抱变化的,认可需求是逐步演进的,渐进明晰的过程,所以是频繁交付,快速验证,快速反馈,然后根据反馈结果,规划下一步计划,也就是滚动式计划,在做下一步计划的时候,会考虑当前变化,这个变化包括市场的变化,需求的变化,团队成员能力的变化等等。

  所以敏捷的拥抱变化,不是为了需求蔓延,也不是为了让项目镀金是让项目符合用户的需求,要让项目达成既定的目标,让交付的价值达到客户的期望。也就是还是在简装的合同里,期望通过拥抱变化的方式,逐步地澄清客户需求,使我们交付的工程达成客户期望。

  问题:一般敏捷项目都会有预算总价和项目阶段时间点(里程碑),在保证大方面不变的情况下,快速迭代,频繁交付,确保在既定的预算和时间点内完成目标,交付价值。需求和技术是变化的,环境和质量是相对稳定的,最后要关注项目中人的因素了,一个频繁变化成员的敏捷团队才是最棘手的。特别是遇到上下都在变的公司……

  现代卓越辅导老师周老师:

  说的没错,敏捷实施在中国的难点就是业务和人员都不稳定,刚刚建立的规则很快就又要重来,所以想要敏捷真正的落地,公司级的支持是必然的,因为放眼公司软件只是交付的一个环节,而要实现真正的快速交付,需要打通上下游各环节,实现端到端的交付。不过,可以从软件开始,从一个项目开始,可以先提高项目的交付和验证速度。

  


  问题:如果按您说的,本质上传统的和敏捷,在控制管理上还是一样的,如果真的发生不可控的情况,还都是要做变更。

  现代卓越辅导老师周老师:

  当然,只是变更的具体流程和方式不同,需要裁剪使用,类似PRINCE2的实践方式。

  在实际执行过程中,传统的项目管理方法在敏捷也是适用的。拥抱变化也是有timebox的,就是在一个迭代周期内是不允许变更的,期望客户能遵守,但是有时候,客户就是在迭代周期里提出变更,那么只能采取特性缓冲的管理方法,移除低优先级的需求高价值优先交付。

  我们在操作的时候,之前会跟客户约定变更原则(以下是样例,和一个车企约定的,目前在按照执行):

  总之,敏捷的执行是知易行难的,特定的场景需要特定的对待,没有放之四海而皆准的万能钥匙。我觉得我们学习敏捷更多的是学习一种管理思想,很多时候是自我的提升,也就是开悟吧。

  


  问题:您好,今天看的视频,提出来人是一个核心概念,在敏捷里关键乐观看待成员的能动性和能力,是否过于理想?

  现代卓越辅导老师周老师:

  真正敏捷项目要求是全栈式人才组成团队,我现在倾向于阶梯式团队,就是有技术骨干,有新人的团队,期望SM和PO个人沟通能力较强,善于引导。

  问题:我有个问题,就是我们常用的几种敏捷模式的优缺点。我想的是团队内能融合几种模式的优点。望赐教,谢谢。

  现代卓越辅导老师周老师:

  几个模式的优缺点?其实还是我昨天说的,从你想解决的问题出发,选择使用的实践。做减法,摈弃做加法的思路。只有适不适合,没有优缺点,我的观点哈。比如,看板的管理方法不适合时间盒管理控制,适合尽力而为的管理方式。运维,改bug阶段就适用。

  问题:敏捷教练和scrum master有啥区别呢?求解。

  A:我的理解是Scrum仅限于 scrum敏捷工具,但是敏捷教练应该是包含srcum工具,但不局限。献丑了,搬砖去了,等老师专业赐教。

  B:Coach 主监控和培训 Maste主推进。

  C:教练应该算是sm的升级版。sm重点在于敏捷思想落地执行,教练主要负责理论指导。愚见~~

  sm做多了就可以去当教练的意思。

  现代卓越辅导老师周老师:

  敏捷教练是对整个agile体系都要求很熟悉,并能指导团队,组织使用的,可以从方法论和实践层给团队建议。现在我们的现状是讲师多,但是教练少,能指导团队的人就更少了。

  而sm是对scrum管理框架很熟悉的人,可以指导团队使用scrum的3355,就像是scrum的一艘船,sm是敲鼓鼓舞团队士气的人。

  所以敏捷教练要求更高。

  问题:请教老师,在公司级推敏捷转型的时候,过程中是不是需要定期用一些指标来评判敏捷的实施效果?请问大概有哪些指标呢?

  现代卓越辅导老师周老师:

  确实从组织的角度是需要的,现在的度量需要从价值交付的角度考虑,我推荐几个,抛砖引玉。

  从价值流动的角度考虑,课题比较大,后续可以有专题。

  


  问题:请问一个不断变化人员的初创团队中,需求繁杂,排期紧张,预算有限,如何更好的使用敏捷开发技术呢?

  现代卓越辅导老师周老师:

  你说的这个项目特点是国内项目常见的形势,敏捷也不是万能,执行也需要一定的条件。虽然说快速交付,快速应对变化,但是是需要客户参与的。所以我的经验还是:

  1.从需求入手,和客户沟通需求,判定优先级和价值。便于在工期紧,人手新的情况下可以有缓冲。

  2.此外要判定技术难度大不大,如果不大还好,如果大,那就只能加班,赶工期了。

  3.人员,需求都不定的情况,建议选择看板管理方式

  4.团队需要有1,2个骨干

  


  问题:老师,对于需求不确定的情况,看板管理有哪些合适的可操作方式。现在我们今年好几个项目都遇到需求不确定,工期又紧的情况,后期的变化又大,这样在项目前期的估算与实际实施情况差别比较大~

  现代卓越辅导老师周老师:

  现在的项目好像都是这样的情况 ,正好是适用敏捷,因为一两句话说不清楚,所以只能说下思路:

  1.项目只能做滚动计划。就像滚雪球一样,一遍一遍的细化。开始只是大概的计划,以后渐进明细,从里程碑计划到迭代计划,根据需求的详细程度,计划越来越详细。

  2.规划好迭代周期,两周一周内是否需求可以稳定,总不会像改bug阶段天天变吧。

  3.团队的组成什么样子的?客户参与度如何?是否有base代码等等,前期是否需要预留sprint0,进行框架搭建。

  4.这种项目scrum的方式也是可选的。选择kanban是因为无法规定迭代周期,天天变,无法预估未来。将价值流动过程展示出来,发现价值流动过程中的瓶颈,并及时解决。和scrum的思路稍有不同。

  A:谢谢老师,项目团队有预留一个sprint0,进行业务分析,设计,框架,数据模型设计。

  B:sprint0很重要。

  A:当前迭代的第二周做下一迭代的设计及评审,但有时发现当前迭代的任务。

  没有完成的情况,只能把任务移到下一迭代中。

  判断一下任务没有完成的原因是什么?很多时候是虽然形式上scrum了,但是框架里运送的故事不足以支撑迭代开发。所以建议从故事的角度分析一下。

  个人建议吧,敏捷的运用感觉是自我成长,不断反思的过程。也就是team的成长性思维。这些都是正常的,所有的项目都这样,不同的是拥有成长型思维的团队能看到目标和希望,而其他的团队就认为不适用而中途放弃了。知易行难

  看完这些精华帖,有没有觉得有些问题都是似曾相识的?如果你想敏捷的解决工作中遇到的各种问题,记好现代卓越敏捷认证课程开班时间:

  敏捷认证实战班:6月21日

  敏捷认证远程班:随报随学

  


  你可以通过以下渠道进行报名或咨询:

  1、 拨打电话400-666-5670

  2、 或直接咨询在线客服

  

学习会上瘾,尤其是你尝到学习甜头的时候,加油!现代卓越陪你一起见证你的学习成果,用敏捷的方法解决工作中遇到的各种问题!


电话咨询

15011540270

关注软考