建议使用以下浏览器,以获得最佳体验。 IE 9.0+以上版本 Chrome 31+ 谷歌浏览器 Firefox 30+ 火狐浏览器
请选择 进入手机版 | 继续访问电脑版
设置昵称

在此一键设置昵称,即可参与社区互动!

确定
我再想想
选择版块

小助手

发帖: 30粉丝: 71

级别 : 版主

Rank: 7Rank: 7Rank: 7

发消息 + 关注

发表于2019-8-1 10:19:30 4013 10 楼主 显示全部楼层
[华山论剑] 《解决企业敏捷转型中101个痛点》大连站线下活动实录

所有混乱都是尚未被理解的和谐

华为云敏捷江湖桃花岛力邀5位敏捷大神,

为企业敏捷转型痛点把脉问诊!


1.jpg


7月26日,敏捷江湖桃花岛来到了海风阵阵的半岛城市——大连!

第三期的华山论剑大连线下活动,就在风景如海的星海湾广场游艇码头旁的微来餐厅举行。

 

本次线下活动为了最大程度保证用户体验采取了邀请制,参会用户来自大连本地的企业家,敏捷圈内的专业人士以及桃花岛群内的积极成员。而本次活动的主讲专家更是堪称豪华阵容:

华为云DevCloud首席布道师 刘恒

曾任京东首席敏捷创新教练、北大光华管理学院特邀讲师 王立杰

IBM敏捷教练 14年IT工作背景 管婷婷

管理3.0认证引导师&Co-owner Scrum联盟CSP,CSM,CSPO 伯薇

华为云DevCloud敏捷专家、资深过程改善顾问 黄隽


2.jpg


以下为本次活动文字实录:

举报
分享

分享文章到朋友圈

分享文章到微博

小助手

发帖: 30粉丝: 71

级别 : 版主

Rank: 7Rank: 7Rank: 7

发消息 + 关注

发表于2019-8-1 10:25:10 沙发 显示全部楼层

环节一:破冰环节:寻宝环节


3.jpg


现场20人,分为四组,每个组分配一张宝物清单,组员推举组长,在队长的带领下,在全场寻找到清单上的全部物品。找到全部物品后,按照完成的先后顺序,组长上台进行展示,最全且最快的2组可以获得提问机会;


环节二:企业敏捷转型案例问诊与分析


案例一:合一网络


公司/团队敏捷转型的痛点:

1、项目上线后客户提出质疑,导致交付出现问题,项目管理上如何操作可以避免这种情况的发生?

2、流水账式的站会让站会成为形式,这样的站会是否有意义?怎么平衡会议和开发时间之间的冲突?

3、传统软件外包公司是否适合采用敏捷开发呢?从实践来看,敏捷开发除了增加开发人员的会议时间外,对管理似乎没有太大的变化?

4.jpg


问诊与分析:

 

无敌哥王立杰:

在过程中客户不能看到完整产品,敏捷应该走迭代,每个迭代应该让人看到,迭代结束时候让客户看哪儿不对,对大客户玩小迭代,所以瀑布流程是比较大的问题,至少每个迭代让客户看一下;

 

管婷婷:

转型敏捷之后开会流程变多问题,Scrum之后四大会其实并不是很多,其中三大会议在一个迭代里只开一次,每天站会控制在十五分钟以内,我们用敏捷的四大会议,代替传统的各种会议。用敏捷的话,项目的状态可以用看板实时了解,不需要额外会议了解项目进度。任何迭代内的目标和进展都可以通过旁听四大会议获得大部分信息。四大会议就可以取代大部分传统会议,这样团队就不会觉得会议多;

 

侯伯薇

把这些问题总结来看,就是沟通机制和方式的问题。很多公司都是带着敏捷的帽子干着传统项目,敏捷的玩法关注的是人,有人就有沟通问题,和客户进行需求沟通,应该通过利益来驱动。

 

黄隽:

一定要把电子看板好好利用起来,尤其是异地协作,这些完全可以暴露给客户,每个人的工作量,项目进度都可以让客户了解。对客户不透明,客户就会对团队不放心.我做过一个国企项目,在给他们做showcase review时,我们邀请他们来公司参观,引导他们了解项目进度,介绍开发人员怎么做的,这时候客户就会提出来一些临时需求,项目进行及时调整。把实施人员派到客户现场,转变为请客户来公司参观,客户就会及时为项目来把关;

 

刘恒:

会议要短,早会可控制在15分钟内,每个人只讲关键信息,求助什么,昨天做了什么就可以。求助的事情单点下来解决。planning会议需求很多,技术难度很大,大家会陷入技术和架构细节中,一个技巧可以做一个pre会议,华为的话我们每周四下午会和SL开一个pre会,确定大方向,星期五的会议把planning放在大会上,直接安排技术人员进行交付,就会节省很多时间。我们现在一周一个迭代,客户不认可敏捷这个问题,其实不是客户不认可,而是客户没发现价值。如果你想安利客户用敏捷,每个迭代一定是要体现客户最想看到的高价值需求,这样会加强客户对你的信心。如果客户很强势,不管迭代,只管三个月后履行合同,这个时候我们只要保证阶段满足验收就行了,内部还是用敏捷迭代的方式;

点赞 引用 举报

小助手

发帖: 30粉丝: 71

级别 : 版主

Rank: 7Rank: 7Rank: 7

发消息 + 关注

发表于2019-8-1 10:29:09 板凳 显示全部楼层

案例二:星汉网络


公司/团队敏捷转型的痛点:

1、公司规模小,很多客户在项目初期就没想好需求,到了中期有各种需求变更,得不到客户的体谅,给客户展示项目的细节越多,客户的问题和需求就越多,到底应该不应该给客户展示项目的全貌呢?

2、人力不足的时候,一个人负责多个项目,如何让敏捷能实施到位?


5.jpg


问诊与分析:


王立杰:

需求变更问题,制定计划能快速响应外部变化,SCRUM讲究时间盒,在一个周期内需求最好不变,一个迭代内尽量要稳定,这样可以倒逼客户想清楚需求。这里我们提到一个DOR概念,是DOD的延伸,什么东西就绪了才能进入开发,需求没有想清楚不要进入开发阶段,我个人喜欢去变更,有一个概念是敏捷快速迭代试错,如果方向是错的,可能项目都要停掉,即使是外包型项目也是受益的。第二个问题,两三个人,就不要去搞敏捷了,做流程实际上是一种浪费,不要为了敏捷而敏捷.


刘恒:

我们也在摸索,以前华为做这种项目我们不用操心,需求变更是要用制衡的方式,后来我们做华为云,发现市场项目超出我们的想象,针对星汉的问题,有几个建议:

1、看客户,如果客户是强硬派,企业还必须要拿单,建议用变形迭代,一开始把所有需求理清楚,得到可跟踪记录,再开始迭代开发,我会拥抱变更,但是有变更的话周期会延迟,增加费用。

2、客户可沟通,也喜欢变化,认为变化合理,前提是公司必须拿下这个客户,可以用原型的方式,把需求具象,尤其是针对政企类客户。

 

6.jpg

 

管婷婷:

在项目中期需求有大幅度变更,越是变更大的项目,越适合敏捷。我们在迭代过程中通过交付MVP,让需求浮现出来,客户能得到自己想要的东西。这里涉及到技巧,MVP怎么定,用最小成本交付出来想要的东西。我们怎么定第一个迭代的mvp,第一步javascript做静态页面,没有成本,这样就可以去和客户交流是不是他想要的。

 

黄隽:

No Change原则,谈需求的时候要埋下一个点,在迭代周期内,阐明迭代周期已经很短了,需求和工作量都是有限的,需变动小,为了维护客户关系可接纳,变化大,不要有过多争论,把当前迭代停掉,新起一个迭代及时止损。定位最关键的项目干系人,告知其要准备2-3个迭代,还有询问清楚AC和DOD。

 

侯伯薇:

这两个问题可以用GROW原则,G就是Goal目标,弄清楚自己的项目目标,是保质保量拿下项目进行交付,还是一锤子买卖。

R,reality,要考虑清楚现实情况。如果开发人员超牛,写不写文档都能如期交付项目,那就不用写。

O,option,想到达到目标,考虑现实情况,那选择有很多种。

W,way。敏捷是试错的过程,敏捷实施没有统一标准答案,从一堆option中选择一条路去实施,进行持续改变

点赞 引用 举报

小助手

发帖: 30粉丝: 71

级别 : 版主

Rank: 7Rank: 7Rank: 7

发消息 + 关注

发表于2019-8-1 10:32:55 地板 显示全部楼层

案例三:溪蔓国际

 

公司/团队敏捷转型的痛点:

1、敏捷开发的要点是什么?对需求分析阶段是否有改变?

2、使用敏捷开发形式开发过两个项目,基本都会导致需求蔓延,如何避免?

3、敏捷开发的优势是什么?节约开发成本?减少沟通成本?提高软件质量?


7.jpg


问诊与分析:


侯伯薇:

我做的项目曾走到跟业务一起制定业务规则的程度,想要达成这样的而目标,要有足够的信任,足够深的业务知识背景。当业务规则是自己制定的时候,写代码的时候就不会写错了。要记住客户合作高于合同谈判。溪蔓国际提到,我和对接人聊得很好,但是老大不happy,这怎么办?要了解老大的目标,就能知道自己接的项目业务方向做得对不对。研发的兄弟不能死守研发,否则做事很累,要提高思考高度,和思考速度,拓展思考宽度

 

黄隽:

敏捷真正会节约成本么?这分情况,我做过政府类项目,当时我的公司市占率很高,在行业是很有权威的,这时候需求不频繁变动,就用瀑布即可。另外一个场景,需求变化越多,就必须敏捷。

 

我创业时,团队招聘的大部分是全栈工程师,这样可以减少沟通,传统瀑布是接力棒模式。

第二个提到对接人需求match,但是老板不认同,我觉得你要做沟通需求矩阵,你要找到关键人,并且灌输思想,你的业务进展我都会和你的领导汇报,所以要让业务人员及时传达领导的需求

 

管婷婷:

现场的嘉宾一直在提到需求蔓延,敏捷的需求是涌现式的,一开始有没有scope,可能是模糊的,敏捷里维护需求是通过产品待办事项product backlog,这里有三种级别需求,epic、 feature、 user story,我们在维护product backlog的时候只需要拆解到feature即可,未来一两个月要做的东西可拆解到user story,远期的可以不做,一旦现在的迭代发生变化,远期的就扔掉吧。在传统项目里是先文档再沟通,但敏捷重沟通轻文档,敏捷里有3C的原则,Card写在卡片上、 Conversation用于对话、 Confirmation及时确认,这都可以减少沟通成本。

 

王立杰:

敏捷里有SDD特性驱动开发,这里认为需求是有前端需求分析阶段,和SCRUM承认需求是涌现的是不同的。要提前约定好需求是什么,这对需求蔓延是有约束的

 

刘恒:

华为内部讨论过,敏捷方法论会减少雇佣开发人员成本么?不是,敏捷可以降低需求变更的风险,而不是降低开发成本。第二敏捷可以增加收入,你的团队大概率可以早一些交付项目,有更多时间和能力交付别的项目,而成本没有变化。

需求分析是软件最重要环节,第一要识别利益相关人诉求,这不是技术的活,而是走向市场,要和市场人员去到客户那里,反复沟通,确定客户需求。

需求蔓延,需求的变更是要进行管控的,业界提出了很多标准,无论用什么方法论,你们现在走的很快,一下子转型敏捷,忽然把需求变更的标准放松了,要用敏捷的方式去适应需求变更。

8.jpg

点赞 引用 举报

小助手

发帖: 30粉丝: 71

级别 : 版主

Rank: 7Rank: 7Rank: 7

发消息 + 关注

发表于2019-8-1 10:36:35 5# 显示全部楼层

问答时间

 

现场提问1:

项目本身做得是企业级定制开发,做得过程中有需求变更,每一个不同类型的企业,对软件有定制化的需求,一个产品服务20家企业,就有20个版本,非常痛苦,我们是不是搞这样一个通用型的平台适应变化,

 

刘恒:

项目型走向产品型,多个产品需要企业有个平台,平台团队饱受摧残,这个平台不能自high,脱离业务,为一个宏大的目标去做,这是死的最快的,如何避免自high,平台和中台要通过业务来沉淀,平台团队要进入业务团队,把业务好的项目抽出来,做成公共的东西。团队走下去的话,所有的业务都长在你的根上面,在做类型东西会发现平台上的业务很全。

 

侯伯薇:

如果想做一个平台,先看市面上有没有类似,如果有的话就直接买,能花钱就别自己做,太辛苦。


9.jpg


现场提问2

现场几位嘉宾有遇到过传统团队成员,成功转型敏捷团队的案例么是从老总开始推广,还是从项目经理开始推广,还是团队成员有这种意识?

 

王立杰:

我之前搞手机APP,两周一个版本。部门操作是搞试点,大的团队一定是从上往下打,之前团队有八百多人,app研发VP直接从他往下打,他把所有总监聚到了一起开会,之后会发一个宣传材料到全员,给下面的团队做一个敏捷转型的表率。

传统项目经理也要变换服务职能,协调资源,细节到订业务方会议室等等。这样上下一起努力,就会带领团队向敏捷转型,打破那些观望情绪。

点赞 引用 举报

寻水的鱼

发帖: 92粉丝: 19

级别 : 管理员

Rank: 9Rank: 9Rank: 9

发消息 + 关注

发表于2019-8-5 10:08:31 6# 显示全部楼层

点赞 引用 举报

建赟

发帖: 286粉丝: 17

级别 : 版主

Rank: 7Rank: 7Rank: 7

发消息 + 关注

发表于2019-8-5 13:40:05 7# 显示全部楼层

好活动,希望能在其他城市开展

点赞 引用 举报

建赟

发帖: 286粉丝: 17

级别 : 版主

Rank: 7Rank: 7Rank: 7

发消息 + 关注

发表于2019-8-10 21:38:50 8# 显示全部楼层

敏捷无敌

点赞 引用 举报

改进无止境

发帖: 22粉丝: 2

级别 : 管理员

Rank: 9Rank: 9Rank: 9

发消息 + 关注

发表于2019-8-13 19:17:53 9# 显示全部楼层

ba b

点赞 引用 举报

改进无止境

发帖: 22粉丝: 2

级别 : 管理员

Rank: 9Rank: 9Rank: 9

发消息 + 关注

发表于2019-8-13 19:18:36 10# 显示全部楼层

分析的不错

点赞 引用 举报

游客

富文本
Markdown
您需要登录后才可以回帖 登录 | 立即注册