说起精益软件开发，这绝对算是一个老生常谈的话题了。所以在这里，我不想去谈论诸如“精益软件开发的几大原则”或是“精益软件开发的最佳实践”等陈词滥调；只是最近在同事的推荐下，拜读了一本有关IT运维方面的书籍(《凤凰项目》)。书中的故事十分有趣，同时又引人深思，细细品味后颇有感悟，对工作和生活上有了许多新的想法，于是便按耐不住写下此文。

写在前面

布伦特是一个有着十年以上开发及运维经验的高级工程师，无论是服务器宕机，发布失败还是线上出现bug等紧急情况，他总是第一时间着手处理，虽然有时并不按照公司的正常流程去提交变更申请，但他总能在大家一筹莫展时漂亮的完成任务。于是整个IT部门的领导和同事都非常的喜欢他，甚至其它和IT相关的部门有需要帮助时，也很愿意找他，布伦特也照样能够快速并且出色的完成。直到有一天，问题堆积的越来越多，布伦特终于忙不过来了，而除了他，在没有其他同事知道问题的来龙去脉，导致许多一级紧急事故无法及时处理，从而让公司损失惨重。这时，大家的态度骤变，都将矛头指向他，认为他没有尽力，并且开始抱怨他总是不按公司流程处理问题从而引发了许多其他问题。老板也不在赏识他，甚至觉得应该在他身边安排几个同事去取代他，而后辞退他。

什么是制约点

开篇的故事来源于《凤凰项目》，其实不难看出，故事中的布伦特对于整个IT部门来说极其重要，由于他掌握了大多数人所没有的资源，技术以及处理问题的上下文，并且没有及时与他人分享，从而让自己成为了问题的核心，事故的焦点以及部门的制约点。

而事实上，布伦特就是布伦特，他一直都在出色的完成任务，他一直都独享着所有一切的上下文，是“一直”让他变得无法取代，也是“一直”让他成为了那个制约点。

制约点总是那么的让人琢磨不定：一开始，它必定是一个舒适点，大多数人并不会在意它，因为总有那些或那个人去悄悄的关注它；慢慢地，你也许很需要它，你才发现束手无策，不得不求助于你身边那些悄悄的人，它又变成了一个痛点；最后，你还是在舒适点和痛点之间选择了前者，随着时间的沉淀，它终于成为了一个制约点。

寻找制约点

忘记是什么时候，耳边听到了一句“其实一切的一切，只是我们（devs）做的不够快，不够好”，此话虽然有些极端，但细细想来，似乎也颇具有几分道理。

但我觉得这不仅是一个个人问题，同时也涉及到了一个团队的运作方式。所以我也时常在想: 如果你是一名身处Agile Team，并且保持求知欲，富有激情，喜欢激辩的dev，那么怎样才能把交付做的又快又好呢？

问题的答案肯定不是诸如“多看书，多学习”等唐塞之言，因为我相信一个能问出如此问题的dev，并且“保持求知欲，富有激情，喜欢激辩”，那么他一定遇到了自身难以察觉的制约点。

所以，不妨从发现身边的痛点开始，学着在组内寻找自己的制约点吧。

解决制约点

如果将制约点看做是一个树根的话，那么起初它只是一个点，而后慢慢成长，具有枝干，渐渐的新的枝干上又有了其他的分枝，直到枝繁叶茂时，你才发现无法从根部去找寻任意一片叶子的路径，因为，它的层级已经太深。

因此解决它的最好办法就是将层级扁平化：当你发现并且解决了一个只有你知道的问题时，不要让自己成为那个制约点，学着share出去；当你发现在你所处的团队里有你的知识盲区时，不要让它成为你的制约点，主动求助，消除盲区；当你发现组内有共同的痛点时，及时的提醒，集思广益，避免它成为大家的制约点。

寻找下一个制约点

但我并不认为有制约点的存在就是坏事：人与人本身在能力偏好方便面就有差距，这就决定了每个人的知识体系大相径庭，所谓“术业有专攻，技术有偏好”是也。所以，制约点某种程度上代表着你的一个目标或者方向，解决制约点的过程就是拉平它对你的制约层级，弥补自身的不足，这就是进步。所以没有制约点就是原地踏步，为了更进一步，就得寻找下一个制约点。

因此，解决完“所有”（也许你认为的所有）的制约点并不意味着万事大吉，你应该继续寻找下一个制约点。

写在最后

受“精益软件开发”所启发，个人觉得所谓的精益思想，XP（极限编程思想），Agile（敏捷思想）都只是一种方法论，甚至可以说由它们衍生出的所谓的最佳实践也都是方法论。毕竟，具体到每一公司，每一个项目，每一个团队，这些准则都不可能完全匹配和适用，但若以此作为思想参考，就会不仅在工作中，而且在生活中感受到它的导向价值作用，从而事半功倍。

原文请戳