分类: 新兴技术

所谓的精益思想的价值和原则非常多,这里引用ThoughtWorks同事Jonny Schneider即将出版的《Understanding Design Thinking, Lean,and Agile》, 通过日常软件开发实践来补充这些看起来很虚的价值和原则,以此推广“精益”成为更好的软件开发指导思想。这是下篇,上篇在这里

我们来简单回顾一下上篇:

价值一:学习和适应 优于 分析和预测

  • 通过实践验证假设,而不是分析和计划
  • 延迟决策到最后一刻
  • 刻意练习科学思维

价值二:赋权的人更快乐并容易取得更好的成果

  • 定义清晰的目标,信任团队并给予自主去取得成果
  • 去中心化决策

价值三:成果优于输出

  • 衡量交付的价值,而不是做了多少工作
  • 明确价值并经常度量

本篇将继续讲述价值四和价值五。

价值四:管理流动优化价值

  • 减少批次大小
  • 管理队列
  • 交付速度
  • 减少浪费
  • 响应客户的需求 优于 创造库存

减少批次大小

如果要我说软件开发管理中最重要的工作是什么,我觉得应该是减少批次大小。

软件管理中存在很多问题,比如需求不明确、需求易变、开发估算不准确、难测试、上线后发现没有真实价值等。

这些问题其实都可以靠减少批次大小来解决,我一般建议把User Story分解到1~2人天(当然还是要用故事点的方式,不能直接用人天来估算),这样的好处是:

  • 故事小对应的需求范围也小,比较容易明确;
  • 又因为需求小,变了也不可惜;
  • User Story小更容易暴露开发过程中的问题,比如把计划一天的任务分派给新人做,即使超出原计划的100%工作量其实也就是多了一个人天,这样团队可以及时干预;
  • 只有一两天的工作也更能消除“一天完成90%,剩下的10%需要一个星期完成”的进度报告问题。或者是一个人同时做很多事情,但都没法交付;
  • 需求小也更容易测试,能更快上线给真实用户。

微服务架构更加强化了减少批次大小的诉求和价值,达到更小的需求、更快的响应、更稳定的交付流速。

管理队列

批次大的时候,一个人好像只在处理一个事情。但实际上人脑容量有限,还是会把一件大的事情分解成多个小事情做,只是无意识的做而已。Scrum的管理方式比较粗暴,看上去只有Sprint backlog一个队列,因为在迭代会议的时候把事情都分配给开发人员了。所以对于Scrum这样的管理框架来说看不到什么队列,这样有什么问题吗?

因为人脑的局限,事情总是会溢出在外面,实际上就造成有个隐形的队列存在,只是没人刻意去管,这就造成有些人盲目的忙,有些人井井有条的干活,纯粹看个人意识。

隐形任务队列的坏处:

  • 任务间穿插、相互影响效率。一个人最佳的工作效率产生于同一时间聚焦做一件事情。但由于事情过大,看起来是在做一件事情,其实是还是处理多个事件,然后思路在不同的事情上面跳跃穿插,造成做事效率低下;
  • 不分任务轻重缓急。其实很多看似紧急的事情,都是因为一开始不做,到需要了才开始做就没时间了,搞得压力很大。比如客户突然过来问XXX事情进行得怎么样了,想明天看一下。你心里立刻开始跑马,“你们咋不早说啊,这事还没开始做呢!” 但从客户的角度讲,这个事情在两个星期前就安排了啊,而且说了很重要。但因为队列是隐形的,大家都只是脑子过一下,或嘴上说一下就过去了,全靠个人意识去处理。
  • 掩盖问题。一个人或团队手上一堆事情,然后有些出现了问题阻塞进展,但因为是隐形队列,很容易导致大家都“忽视”问题,直到所有的任务都遇到同一个阻塞点。隐形的队列越大,掩盖的问题也越大。这个问题特别严重也最常见,我们经常会听见客户说自己没有问题,因为表面上大家都在做开发没遇到问题,只是到了一个月交付的时候拖延一个星期才能交付出去而已,已经是习惯了,这也很正常啊。但是稍微聊一下就会发现需求不明确,沟通不顺畅,缺乏自动化测试,质量不稳定,手工运维经常出点“小”问题等等,这些问题其实每天都在发生,但都可以一直掩盖到最后一刻才暴露出来。

所以首先应该把任务队列显性化,要用团队的能力和意识来管理队列,而不是让个人去随便搞。

然后才是队列管理技巧,比如优先级调整,任务依赖关系管理,阻塞点识别和清除。

在精益里面有个很重要的原则,叫限制在制品数量,意思是要严格限制正在进行的任务队列大小,这样就能很容易的识别阻塞点,及时处理,并且更容易控制交付流速。

交付速度

在讲TDD特有价值的时候我提出其中了两个:

  1. 质量
  2. 可维护性

但怎么衡量这两个指标呢,尤其是可维护性。我觉得可以归到“交付速度”一个指标上。我们不把修bug当做价值而是当作浪费,这样质量差的软件开发,必然导致交付资源会被修bug挤占,从而影响交付速度。

软件的可维护性也会体现在交付速度上,做的好的软件交付速度会越来越快。因为该做的基础工作都逐渐完善,开发人员的领域知识和开发技能也逐渐提高。

然而很不幸的,能逐渐提升交付速度的团队很少,理由往往是需求越来越复杂啊,以前都没提有这样的需求现在要大改啊什么的。而且没人正在度量交付速度,所以只是开发人员和客户都抱怨罢了。

减少浪费

以前西方流行的精益观念认为“减少浪费”是精益思想的精髓,然后有非常全面的识别和消除浪费的方法。

我觉得减少浪费是精益思想的很小一部分,就像我们想增加收入要做开源节流。不能认为节流能增加收入就当做主要手段用,导致影响开源。但很不幸的是节流比开源要容易很多,所以很多企业在危机时刻很容易选择节流而导致开源不利。

比如只从业务功能角度讲,搭CI/CD所花的时间是浪费掉的,因为没有直接产出业务价值。

减少浪费的观念确实非常有用,能有效指导消除不必要的工作。

响应客户需求 优于 创造库存

我发现开发团队很喜欢创造库存,有一些原因:

  • 库存带来安全感;因为开发团队总是被客户挑战,手上拿几个已完工的需求会觉得到时候有货交差会很好。
  • 库存里的东西不用马上验证,自己认为总是对的;
  • 库存里面堆什么可以自己决定;人总是会倾向做自己熟悉或感兴趣的事情,而总是响应客户需求的话可能会被迫出舒适区。比如很多业务系统一上来就做个用户管理模块,虽然看起来这些基础模块是必须的,但在一开始的时候对客户业务人员来说真的是必须的吗,如果只有一两个用户明显可以工作,那硬写在代码里就可以了。
  • 管理者不想让开发人员闲着;尽管当前没有明确的客户需求,管理者为了不让开发人员闲着,也会要求做一些有的没的需求,号称以后用的上。
  • 客户不愿意频繁接收需求;这种情况多是因为客户接低质量的需求接怕了,所以拒绝频繁接,以为让完工的软件在库存里多呆一会质量会自动提高;第二是可以一鼓作气去应对低质量的需求,集中时间处理麻烦事。

敏捷宣言用了很大的比重来强调拥抱变化响应客户需求,很好地改变了软件开发团队和客户之间的信任关系。但是并没有什么方法很好的去响应客户需求,要不然Scrum这种固定时间盒的方法也不会大行其道了。

精益的拉动式流管理是完全面向客户的,利用客户需求驱动团队工作。而且只有需求交付到客户手上才算是完成了,使得软件尽早产生业务价值,这也是MVP思想的来源。

价值五:质量是结果而不是活动

  • 内建质量
  • 持续学习和改进
  • 追求完美

内建质量

内建质量就不多说了,是我们倡导的实践口号,只是需要配合质量度量和持续改进,不然就只是口号了。

持续学习和改进

除了交付客户所需的价值,对我们来说更重要的是团队个人能力的提升。因为软件交付给客户价值后,对我们的价值(钱)也就结束了,唯有团队个人在交付的过程中不断提升,才能提升公司的整体价值和竞争力。

在敏捷管理里面设置回顾会议以支持持续改进,而且更关注问题和解决问题。为什么要等一个月或两个星期才做一次回顾会议呢? 固定时间、固定任务、做固定的事情好处是能有一种仪式感,容易协调不同人的时间和工作内容。但因为反馈周期太长,算不上持续,只能说是断断续续的学习和改进。

其实最好的学习和改进机会是做到on demand,发现问题及时处理问题,如果处理不了及时提出来引起团队的注意。另外每日站会和每日code review都是固定的时间点,可以用来做学习和改进。

学习和改进的内容不仅仅是软件代码、架构设计、需求质量,还有协作方式、甚至座位安排、客户对接方式、价值排序原则等。

追求完美

可能对于一个商业组织来说,追求完美是最正确又是最错误的事情。因为很容易陷入闭门造车,导致投入产出比失衡,造成亏损。

但精益思想并不是一个点,而是一组。我总结的精益思想的哲学是以客户为中心,持续自我改善,追求长期利益(完美)。

每个人或组织心中应该有个对“完美”的定义,以此为愿景进行长期可持续追求,但由于是企业,所以要以客户为中心。当然基础还是富有激情的个人在每时每刻进行持续学习和改进,以达到个人的完美。


跟多精彩文章,请关注微信公众号:软件乌托邦

Share

发表评论

评论