精益价值、原则和软件实践
2019-12-25
来源：软件乌托邦 吴雪峰
直接用人天来估算)，这样的好处是：
故事小对应的需求范围也小，比较容易明确；
又因为需求小，变了也不可惜；
User Story小更容易暴露开发过程中的问题，比如把计划一天的任务分派给新人做，即使超出原计划的100%工作量其实也就是多了一个人天，这样团队可以及时干预；
只有一两天的工作也更能消除“一天完成90%，剩下的10%需要一个星期完成”的进度报告问题。或者是一个人同时做很多事情，但都没法交付；
需求小也更容易测试，能更快上线给真实用户。
微服务架构更加强化了减少批次大小的诉求和价值，达到更小的需求、更快的响应、更稳定的交付流速。
管理队列
批次大的时候，一个人好像只在处理一个事情。但实际上人脑容量有限，还是会把一件大的事情分解成多个小事情做，只是无意识的做而已。Scrum的管理方式比较粗暴，看上去只有Sprint backlog一个队列，因为在迭代会议的时候把事情都分配给开发人员了。所以对于Scrum这样的管理框架来说看不到什么队列，这样有什么问题吗？
因为人脑的局限，事情总是会溢出在外面，实际上就造成有个隐形的队列存在，只是没人刻意去管，这就造成有些人盲目的忙，有些人井井有条的干活，纯粹看个人意识。
隐形任务队列的坏处：
任务间穿插、相互影响效率。一个人最佳的工作效率产生于同一时间聚焦做一件事情。但由于事情过大，看起来是在做一件事情，其实是还是处理多个事件，然后思路在不同的事情上面跳跃穿插，造成做事效率低下；
不分任务轻重缓急。其实很多看似紧急的事情，都是因为一开始不做，到需要了才开始做就没时间了，搞得压力很大。比如客户突然过来问XXX事情进行得怎么样了，想明天看一下。你心里立刻开始跑马，“你们咋不早说啊，这事还没开始做呢！” 但从客户的角度讲，这个事情在两个星期前就安排了啊，而且说了很重要。但因为队列是隐形的，大家都只是脑子过一下，或嘴上说一下就过去了，全靠个人意识去处理。
掩盖问题。一个人或团队手上一堆事情，然后有些出现了问题阻塞进展，但因为是隐形队列，很容易导致大家都“忽视”问题，直到所有的任务都遇到同一个阻塞点。隐形的队列越大，掩盖的问题也越大。这个问题特别严重也最常见，我们经常会听见客户说自己没有问题，因为表面上大家都在做开发没遇到问题，只是到了一个月交付的时候拖延一个星期才能交付出去而已，已经是习惯了，这也很正常啊。但是稍微聊一下就会发现需求不明确，沟通不顺畅，缺乏自动化测试，质量不稳定，手工运维经常出点“小”问题等等，这些问题其实每天都在发生，但都可以一直掩盖到最后一刻才暴露出来。
所以首先应该把任务队列显性化，要用团队的能力和意识来管理队列，而不是让个人去随便搞。
然后才是队列管理技巧，比如优先级调整，任务依赖关系管理，阻塞点识别和清除。
在精益里面有个很重要的原则，叫限制在制品数量，意思是要严格限制正在进行的任务队列大小，这样就能很容易的识别阻塞点，及时处理，并且更容易控制交付流速。
交付速度
在讲TDD特有价值的时候我提出其中了两个：
质量
可维护性
但怎么衡量这两个指标呢，尤其是可维护性。我觉得可以归到“交付速度”一个指标上。我们不把修bug当做价值而是当作浪费，这样质量差的软件开发，必然导致交付资源会被修bug挤占，从而影响交付速度。
软件的可维护性也
免责声明：
1、IT项目管理界发布的所有资讯与文章是出于为业界传递更多信息之目的，并不意味着赞同其观点或证实其描述。其原创性以及文中陈述文字和内容未经本站证实，对本文以及其中全部或者部分内容、文字的真实性、完整性、及时性本站不作任何保证或承诺，请浏览者仅作参考，并请自行核实相关内容。
2、本站部分内容转载于其他网站和媒体，版权归原作者或原发布媒体所有。如文章涉及版权等问题，请联系本站，我们将在两个工作日内进行删除或修改处理。敬请谅解！
-
延伸阅读：
-
