扫码阅读
手机扫码阅读

ASK MO第42期 | 硬件开发和软件开发如何做好的统筹和协调?

68 2024-01-09

正文共:2132字2图   预计阅读:6分钟

哈喽大家好!

这里是空谈误国,实干兴邦的创新实干派。

我是莫老师????

欢迎来到每周二晚9点的ASK MO时间

SUN

MON

TUE

WED

THU

FRI

SAT

2

3

4

5

6

7

8

ASK MO来到了42期,周末给齐心集团做了一场培训,有位同学说了一句让我好感慨的话:我听过很多培训,但是基本上都是讲概念做游戏的,第一次以这种企业真正能落地的实战培训。同学,就为了你这句话,莫老师继续努力,坚持实干课程,给企业带来切实有利的帮助。

好了话不多说,回到我们的ASK MO。

本期话题

• 第一个版本怎样敏捷的规划迭代呢?

• 硬件开发和软件开发如何做好的统筹和协调?

• 如何避免站立会议上无价值的问题耽误太长时间?

请教需求切分的方法、原则,使用技巧。

• 敏捷教练可以从哪些方面来引导团队实现价值提升效率?

本期提问

问题1

想了解一下敏捷是怎样去规划迭代的,特别是第一个版本需要具备怎样的功能,感觉第一个版本的功能很难删减,需要业务闭环,有什么办法可以筛选需求的优先级?

——陈继兆

第一个版本需要把产品的价值主张表达出来,所以业务闭环无可厚非。你要搞清楚版本和迭代的概念,第一个版本可以业务闭环,但是一个版本是可以分多个迭代完成。

打个比方,你要做一个完整的商城APP,肯定是需要登录注册,首页,商品分类,商品详情,下单,支付,订单追踪这些全部完成才是一个闭环是吧,如何做第一个迭代,可以只完成首页,分类,详情,让大家看一下APP将来发版本要呈现出来的主要部分,再通过第二个迭代和第三个迭代把下单,支付,订单这些做完就好了。

另外,如果第一个版本,你们团队以前做过类似的项目,团队又在一起磨合了很久,第一个版本要完成的功能模块又是确定的,你们直接用瀑布就好了。项目管理方法本来就是活学活用的,不是因为敏捷流行,我就硬要用敏捷迭代来开发。

问题2

智能自助设备——硬件开发和软件开发如何做好的统筹和协调?前期这两个模块是独立分开,我主要带硬件的项目,现在软硬件一起带,软件节奏有点蒙,前期软件一直是产品经理带节奏。

——dealia

硬件和软件最大的不同在于,硬件一旦量产了,就已经不能进行任何更改了,一直到等到相对长的周期,在下一个批次上去做改变,做修复,而软件则可以在上线之后不断发布。

软硬件结合的项目关键期就是设计期,在前期设计的时候,要考虑到硬件对产品的支撑,把软硬件的接口先设计好,定义好之后,才可以各自进入开发。开发过程当中,硬件可以先把开发主版做出来,交给软件进行调试,以确认软件做出来的功能,硬件是否支持,软件就可以不断迭代地完成了。这个就和一般的软件开发没有什么区别了,两周一个迭代或一周一个迭代。主要业务跑通之后,就可以由产品经理来决定是否可以量产硬件了,产品发布之后,也可以通过OTA升级的方式,不断通过软件更新达到更丰富的应用。

问题3

腾讯的项目管理流程是怎样落地实践的?如何避免站立会议上那些毫无价值的问题耽误太长时间?

——溪源

我们要先搞清楚会议的流程和目的。通常会议分为三个流程:会前会会中会,和会后会

• 会前会,是要先准备好,形成决策用的。

• 会中会,主要是同步信息,形成决议用的。

• 会后会,是专题讨论用的。

对于提高站会的效率,我们可以按照这个步骤进行:

1、缩小团队的规模,拆分特性团队,按业务模块去组织团队开会,尽量少的人员参会,会提高站立会议效率。

2、站立会议之前,让大家把进度更新好,通过白板展示出来,站会就不详细过进展,只对异常进展进行讨论。

3、站会需要主持人,主持人每次会议开始时强调会议纪律,在会上只暴露问题,不解决问题。解决问题可以放到会后会去跟进。

4、站会结束后,主持人把抛出来的问题发到群里,继续跟进直到闭环。

问题4

再次请教需求切分的方法、原则,使用技巧。

——大灰狼

需求拆分成方式主要是要符合以下六点:

• 独立性——在进入迭代前,需求是否已经解耦到了这样一种程度:可以在一个迭代内实现所有强依赖的需求。如果不能在一个迭代内实现所有强依赖的需求,则意味着需要对需求重新进行定义和拆分。

• 可协商性——指的是团队对需求已经沟通到基本达成一致理解的程度。如果还存在疑问,则说明沟通未达成一致。

• 有价值——在团队间已经达成一致,以便确认迭代的目标和优先级。这里我想特别强调的是产品经理对技术需求的理解,尤其是技术债的理解,须知技术债的修复成本随着时间呈指数增长的。我们往往容易出现的一个问题是:由于非技术出身,产品经理不理解目前产品中已经欠下的技术债,而导致技术债始终无法得到偿还,进而变得修复成本越来越高。在迭代前,产品经理和团队应该一起审视下技术债的情况,以及确认是否对其价值达成一致。

• 可估算性—— 有两个因素会影响到估算的准确性:需求太大相关知识的缺乏。如果让我们估算一下一栋大楼的面积,我们很难估算;但是如果让我们估算一下一个房间的面积,我们则会估算得比较准确;所以要确保估算的相对准确,必须控制需求的规模。如果我们对需求的理解存在不足,或者技术实现方案了解不够,同样也会导致估算得非常不准。这就要求我们确认需求的规模是否已经足够小,以及确认我们的团队是否已经对需求有足够的了解,并对技术实现方案基本达成一致。

• 短小—— 要进入迭代的需求粒度必须是足够短小的,按照要求是应该能够在5人天内完成。我们应该确认需求的粒度是否已经在此大小范围。

• 可测试性——可测试性的含义是在明确的输入下有明确的输出,在迭代前我们要确认的是:是否所有需求都已经完成测试要点的讨论和整理。

问题5

在敏捷团队里,如何能体现出敏捷教练的价值?敏捷教练可以从哪些方面来引导团队实现价值提升效率?

——西米露

我上次在朋友圈里就说过,敏捷教练和健身教练从本质上来看,没有区别。

有哪个健身教练能和你签订合同,说保证你一个月之内瘦5斤肉,瘦下来了我才收费?好像没有这么干的吧。为什么呢?健身教练,不是有那么多方法,把健身计划都拆分成每天做什么吃什么都给你规划出来了?关键点不在于健身教练,他永远是个辅助角色,关键于在执行的人。如果你不遵循健身计划,或者在执行过程中,今天有时间就跑跑,没时间就不跑,少做几组扛铃,少加几片杠铃片,或者晚上饿了偷偷吃点东西,嘴馋了再出去喝个奶茶。

所以教练的价值在于,他比你更专业,趟过的坑更多,他知道在遇到类似问题的时候应该用什么方法去解决。你能在他的指导下,少走点弯路,有效解决问题,就是教练的价值。体现教练的能力,就是看怎么有效带领团队解决问题。

敏捷教练可以从迭代节奏,团队响应速度,团队工作速率这些指标来看团队的效率是否提升。我们有一套团队成熟度模型,有需要可以私下讨论一下。

· · ·END· · ·


原文链接: http://mp.weixin.qq.com/s?__biz=MzIxMjM1MjMyNA==&mid=2247484634&idx=1&sn=f133fa9ca785c8e4a50825aff243ce45&chksm=974628f1a031a1e79fef6b09b7667d62d52d0b252e03a758eb16554ce532140c8c4a6481e6d1#rd

小文分享

65 篇文章
浏览 2493
加入社区微信群
与行业大咖零距离交流学习
软件研发质量管理体系建设 白皮书上线