敏捷开发方法背后的哲学原来是避免浪费
我最近一直在思考，为什么敏捷开发这么流行，难道是传说中的银弹吗？为什么《敏捷革命》这本书要将敏捷称之为一种革命？为什么作者那么鄙视瀑布式开发方法和甘特图？经过反复阅读《敏捷革命》这本书，我发现敏捷开发方法背后的哲学原来是避免浪费，我将从以下9个方面简要讨论一下敏捷方法是如何避免浪费的，希望读者再补充1个，帮我凑个整数。
-
敏捷方法最强大的地方，是通过迭代式增量开发的节奏，定期给客户展示真实的产品，从而及时收到真实的反馈。传统的软件开发方法的迭代周期比较长，一般是按照几个月前的需求文档编写代码，并且需求分析多多少少都会有点偏差，最终交付到用户手上的功能可能已经不是用户想要的了，程序员们辛辛苦苦开发出来的东西没有人愿意用，这是一种极大的浪费。
-
对于项目管理来讲，项目经理要保证每个项目成员都清楚地知道自己要做什么事情，以及每件事情完成的标准是什么，SCRUM看板就是一个很好地工具。每个项目成员都会在SCRUM看板上认领自己的任务，这相当于项目成员做出的承诺，这样就避免了员工由于工作目标不明确而造成的混乱（我曾经待过一个团队，大家都不知道自己这个月要干什么，这对企业来讲是一种很大的浪费）。另外，看板传递的另外一个信号是信息透明，任何人都可以通过看板看出来团队的每个人正在做什么，进度怎么样，这促进了信息的流动，防止有些团队的成员甚至团队负责人利用信息的不对称来维护自己权威。
-
每日站会上，每个人要回答三个问题，我昨天做了什么、我今天计划做什么、我遇到了哪些障碍。这个机制有助于及时暴露问题，SCRUM master的一个重要的职责就是调动资源为团队扫清障碍，避免由于障碍导致项目卡壳，卡壳的话，有些人只能干等着，什么都做不了。
-
SCRUM master除了要为团队扫清障碍以外，还要保护团队成员不受外界干扰。对团队成员来讲，同时做多件事情会大大降低效率，是一种很大的浪费，SCRUM master要及时叫停与本次迭代没有关系的事情，避免团队成员因为处理其他杂事而出现上下文切换的浪费。
-
每项任务最好一次做完，所以要明确每项任务完成的标准。如果很多任务只做到了一半，就像一个工厂的仓库里堆满了半成品，卖也卖不出去，又占用了大量的成本，这也是一种浪费。每个用户故事都应该是完整的，可以解决用户的某个问题，因此一个用户故事完成后是可以交付的。
-
与一次性把事情做完相比，另一个非常重要的事情是最好一次性把事情做对，修复bug或返工是一件充满了坏味道的事情，不仅可能会打乱已有的开发节奏，造成过多的上下文切换，而且，重复的返工和遍地的bug甚至会影响团队的士气。敏捷是一种迭代式开发的方法，配合持续集成和持续交付的基础设施，能够通过自动化的手段更好的在发布前发现问题。
-
在任何一款软件上，80%的价值来自20%的功能，有些不重要的功能反而会占用大量的工时。产品负责人要不断地找出最有价值的那20%的功能，并列入到团队的待办清单中，确定好优先顺序。
-
敏捷团队要具备彻底完成一项任务所需的全部技能，并且成员之间还要具备相互backup的能力。这个就类似特种部队的小分队，俗称老A，每个人除了自己的专长以外，还需要具备比较综合的能力。对应到开发团队，就是全栈工程师。试想一下你们的团队想要启动一个项目，需要先去产品团队借一个产品经理，再去前端团队拉一个前端工程师才能启动项目，但产品经理可能不具备你们项目所需的行业知识，前端工程师只能协助你们两周，两周以后就去忙别的事情去了，以后再想改需求就要另外排期了，那么这样的项目注定充满了低效的沟通和失败的风险，这也是一种浪费。
-
敏捷方法主张由开发人员来评估每一个迭代能够完成多少工作量，反对在一个迭代周期内临时加入任务，导致任务量过大而加班。更直接地讲，敏捷方法不主张加班，因为加班容易造成人的疲劳，人在疲劳状态下犯错的概率大大增加，而修复这些错误所需要的时间甚至会远远大于加班的时间。尽管加班在当时看来会有立竿见影的效果，但是把眼光放长远的话，疲劳加班其实是一种得不偿失的、具有后遗症的浪费行为。
最后，我想聊一下产品负责人这个角色，我目前的角色就更像是产品负责人。产品负责人要花很多时间和用户沟通，听取用户的想法，然后根据用户的反馈制定出团队的下一步待办清单，并排好优先级。产品负责人除了需要具备产品设计的专业知识以外，还需要具备以下四个特点：
产品负责人要具备相关领域的专业知识和行业背景，餐饮行业的产品经理要懂餐饮，能源行业的产品经理要懂能源，运维领域的产品经理要懂运维，只有具备了这些，才能懂用户，懂用户的痛点，懂产品的价值。
产品负责人必须具备自主决策权，才能带领团队做出自己认为有价值的功能，才能不过多地受到行政干预，或者外部压力的干预。
产品负责人必须有足够的时间与团队成员接触，向团队成员解释清楚需要做什么以及为什么要这么做。产品与研发在考虑问题时的出发点不一样，思维方式也不一样，比较容易产生争执和矛盾，网上关于这方面的段子也比较多，但双方必须意识到，产品负责人需要依靠研发来实现自己的想法，否则PRD永远是PRD，无法变成可以运行的软件送到用户的手上，研发则需要依靠产品来实现自己的价值，否则无论你编写出多么优雅的代码，无法产生商业价值。所以，产品与研发要充分融合，让对方觉得值得信赖、言行一致、易于沟通。
产品负责人必须为价值负责。产品负责人要设计出能够解决用户问题的产品，并通过产品为公司实现商业价值。
本文首发在我的个人公众号老朱的读书随想，如果感兴趣的话，欢迎关注我哦。