本文主要内容是：在看板管理中努力实践以下方法，1、从立项到结项，由一个人完成项目管理和项目开发，2、当前易发生冲突的需求点，均应分配给同一个人。3、允许特殊情况存在，仍允许持续优化。
从传统瀑布模式，然后到看板管理（物理看板到电子看板），最后精益转型，很庆幸一路走来，经历了不少的软件管理方式，让自己也能在各种软件管理方式下，有自己的想法，也希望这些想法为以后带来更好的管理。
目前通过看板管理，我在实践的是如下方法：
1、从立项到结项，由一个人完成项目管理和项目开发；
2、当前易发生冲突的需求点，均应分配给同一个人；
3、允许特殊情况存在，仍允许持续优化。
在过往的实践和自己的学习与持续优化中，我在尝试上述方法，也是基于以下遇到的一些情况：
1、 在传统的瀑布模式下，我们设置了很多关卡，项目人员多，每个关卡都要在多人协作的情况下完成，例如简单的结项操作，都要大家都补齐各种各样的文档才能结项。
2、 即使转精益后，也有以下问题，多人参与的项目，无法避免的还是等待，在开发能力参差不齐的情况下，先完成的开发人员就需要等待后完成的开发人员。
3、 在《看板方法》中，“每个知识工作者同时只在2个工作项上工作是最优的。”虽然书中也不是太赞同这个研究。我也不太赞同，我认为个体本来就存在差异，而且工作项也存在差异，我认为最好的方法就是承认差异，让各个差异独立存在。
4、 独立的完成比在协作的过程中更能发现自己的问题，更能发现自己优势，更能完成自我升华。
因此，我形成一个想法，尽量减少协作的部分，让更多的事情能独立完成，会不会更好？
所以，希望在最大限度的减少需要协作的内容，而产生以下方法：
1、需求澄清中，由产品管理人员、业务人员、测试人员、最终的开发人员进行讨论和澄清（目前会同时澄清多个需求再统一排优先级），从立项到结项，由唯一开发人员（在挑选高价值的需求）完成整个项目管理和项目开发（项目开发完后，就可以准备开展下一个需求点）；
2、当前易发生冲突的需求点（简单判定就是容易出现代码冲突的需求），均应分配给同一个人；
3、允许特殊情况存在（例如需求优先级可以先讨论近期的，再慢慢识别长期的。允许可能的紧急需求发布），仍允许持续优化。
在我看来，独立完成会比协作更好（自己实践仍太少，所以只能自我感觉）。在我们组转型到上述方法后，一年的代码冲突小于10，上线也没有事故，功能点生产效率也提高了10%。（2019年数据）
我也尝试推广到其他部门，我发现并不能：
1、 系统得做更多的解耦，解耦是为了能减少代码冲突，否则。按照方法2，那么一个人将积压很多工作。
2、 组内的需求池尽量够大，像我们组是常年保持50+以上的需求池内容。
3、 组内最好能有多个产品，或者多个发布单元，像我们组是有20个发布单元的。
上述方法也是在不断的回顾改进中实践过来的，但也有以下的一些问题要避免。
1、 在《构建之法-现代软件工程》一书中，就说了要注意带泥的萝卜（做事很快，很多但是总是犯错）和干净的白菜（做事很稳妥，但是做事很慢）。
2、 更偏重且更需要全栈工程师，而且更希望经验稳定。(例如需求涉及客户端到服务端，那么如果一个人开发的话，就要从客户端到服务端都要弄)
3、 更期望于自驱动的开发人员。
4、 一个开发人员休假了，一个模块也跟着休假。
因此，其实所有方法都有自己的问题和弊端，也有自己优势和特点。我觉得需要的还是持续改进，选择最合适自己团队的方法。
网友评论