随着敏捷相关议题的迅速兴起，我们发现敏捷的思想和方法不仅应用在软件开发上，实则敏捷早已跨界，比如18年3月哈佛商业评论的文章《HR迈向敏捷》。
在顾问们经历的很多敏捷咨询过程中，经常遇到那些将Scrum实施成小瀑布的团队，这些项目的结局，往往比大瀑布还差。软件开发是一个复杂系统，没有什么“最佳实践”组成的银弹，因此也没有一种方法可以把敏捷套用到每一个团队中。但一些共同的精神和价值观构成了我们常说的敏捷思维，这些是具有共通性的，它是践行敏捷实践的前提。
理解市场和需求会不断改动
我们和最终用户谈谈，辛苦做完用户调研和需求分析，但上线后他们却认为这不是他们自己想要的？这是软件工程中老生常谈的话题，工程师常常抱怨“这不是上次访谈中确认的需求吗？为什么又要改了？”然而一个真正有敏捷精神的专业工作者，应该反过来理解“需求”是会不断地变动的，因为技术、竞争对手、市场一直都在变化（我们所处的VUCA时代就是变幻莫测的时代：VUCA是Volatility（易变性）、Uncertainty（不确定性）、Complexity（复杂性）、Ambiguity（模糊性）的缩写。），因此我们该做的是在可变动的范围内保留一定的弹性，并且设定执行的优先级。
减少浪费
按照精益原则，认可不能为客户增加价值的行为即是浪费。在软件开发中，“没有必要的功能或需求”是很明显的浪费。我们也许碰到过这样的案例：开发团队觉得这个功能很酷，用户一定想要这个功能，但这些需求真的都是必要的吗？如果我们不能列出需求的优先级，很容易陷入这样的处境。因此我们要很清楚用户的行为，什么功能（需求）对他们是最有价值的，并设定正确的优先级。精益思想认为软件业有七大浪费，分别是：库存（半成品、WIP），额外过程（比如文档工作中不会产生增值的部分），多余功能（任何一段不需要的程序代码都是一种浪费），任务调换（软件开发人员每次在转化工作时都会浪费调换时间），等待（比如在软件开发过程中一方等待另一方的响应），移动（比如当开发人员遇到无法立刻处理的问题而需要他人协助时，他需要移动多少距离才能找到问题的答案？人不是唯一会流动的，各类文件也会流动，这些都可能造成浪费），缺陷（缺陷需要越早找到越好，因此借助频繁集成及发布是一种很好的实践，也是避免重大浪费的必要小浪费）。
使用者参与并尽早取得反馈
想象我们在TWI培训中做过的乐高游戏（用于理解精益创业），其中的痛点是研发团队常常容易忽略的：研发团队关在办公室中“想想”使用者的需求，并以此开始研发工作。显然这并不是好的做法，我们应该早期产出软件，让用户尽早验证这些功能是否满足需求，让用户（或是数据）反馈哪些是重要的功能、哪些功能不好，或是从中观察使用者的操作经验，使软件能够在下一个周期持续改善。
后记
在《人月神话》中有一条著名的布鲁克斯法则：“在一个时程已经落后的软件项目里增加人手，只会让它更落后。”因为增加的人员到已经延误的项目里等于是火上浇油，除非可以把工作区分，让新进人员可以在不影响他人工作的情况下有所贡献。因此这类问题的解决之道是大家一起坐下来找出真正的问题点，并针对问题提出解决方法，这也是持续改进的思想。
网友评论