敏捷开发—One Team不怕撕

Posted 2021-04-23 敏捷视界

之前跟大家讲过敏捷开发流程，今天跟大家讲一讲，团队

产品和开发必须是one team

一般的公司都会将产品和开发分成两个部门，做产品的设计原型图，开发的做技术，这也是现在产品经理和项目经理经常撕逼的原因。

不是一个团队，就会遇到一旦出现问题了，谁负责的问题，这个时候团队与团队之间往往就会互相推卸责任。

不是一个团队，产品与开发沟通起来也没有那么方便，经常会出现做出来的东西产品经理不满意，产品又老觉得技术部门的总是get不到点。

one team，强调的理念是：全员共同承担责任，出了问题，是每一个人的问题，别说这是产品设计出来的，我只是按照他们说的做，也别说我们是按照用户需求去做的，只是被他们做成这样，到头来没有任何人去关心为什么产品成了垃圾， 然而用户却从来不会去管，这到底是谁的错，他只知道公司设计的东西不行。

为了避免这种情况，责任共担是很好的方法，one team 就是在面对不好的结果时，大家是一起想办法，一起承担责任，相互沟通，共同面对问题，找出自己的责任，解决问题，避免这样的问题再次发生。

one team 并不是没有分工，什么都要做，而是职责明确，该是谁的事情，提前明确。

一个敏捷开发团队的推荐角色应该是这样的。

PM 1个

UI 1个

CSS/js 1~2个

Java 2~4个

android 1~2个

ios 1~2个

QA 1个

这是一个相对平衡的模板，这样的一个8~10人的小Team，是可以复制的。敏捷开发支持多个Team并行开发。理论上来讲。这种方式，可以支持五到六个小Team同时启动。

那么现在来聊一下每个角色的职责

PM ： PM的职责并不是画原型，而是去分产品的分期，确定产品要做的功能和优先级。 对于产品来说，最大的职责并不是将原型画出来，而是要证明自己要做的功能是合理的。如果你证明不了自己要做的功能是合理的，是值的尝试的，就是产品经理的失职。

可以参考MVP，有无数的办法可以提前验证，如果不能够提前验证，那么就证明这是有风险。做为PM，一定要有这种风险的意识，要知道自己身上担负的责任，PM花了两周时间设计的原型，8人的开发团队要折腾近三周左右的时间。

原型和产品文档都是辅助的东西，我甚至不推荐产品经理去做原型设计，只拆分Story。

原型设计交给传统的UI更合适。然而在真实实施的过程中，因为很少有UI具备原型的设计能力，所以实施起来会有一些难度。这个不算特别重要，慢慢培养。

PM不需要为开发进度负任何的责任，这很重要，不要把PM当成项目管理来使用，如果你让PM去做了项目管理，恭喜你，Game 近乎 Over，产品经理没有时间再去思考如何做功能了。

PM的职责就是把功能设计好，优先级排好，给开发团队讲清楚需求，结合Story优先级和功能实现的大概时间点去做排期。

开发工期交给开发团队去做，Bug会和QA，开发团队一起来定。记着要在开发团队开发项目的时间里，去做好下一个产品迭代的设计。

开发组成员：项目进入真正的开发阶段后，开发组的成员就应该是主动去控制项目的进度，和风险，以及主动去测试项目中存在的问题，在这个阶段，除了一些需求不明，或者是发生变动的情况出现，不应该去打扰产品经理。不要让产品经理做开发团队的保姆。

开发组的成员的目标就是做好项目的进度控制，有风险就及时反馈给Leader，确保自己理解的需求是明确无误的，确保自己的测试是完整和严谨的，确认自己写出来的代码是可以维护的。

一定要理解清楚，一旦PM通过Story讲解，将需求交付给开发组成员，那么开发组成员就应该主动而独立的为这件事情负责。

当项目完工以后，开发组成员应该交叉去做CodeReview，并且出性能测试报告，以及组织Demo。

小组Leader：需求评审会的成员应该包括PM组的Leader，前端组的leader,后端组的leader,测试组的Leader，或者是其他公司的中层骨干。

这应该是一个公司所有应该为这个项目负责的人的评审会，在评审会上的结论，就应该被坚定的执行下去了。不参与评审会的人，不应该再对需求指手画脚。 

需求评审会的目标就是确定原封不动的需求，所以在这里要格外的注意，PM拿出来的方案设计，一定是完整的，而且必须评细节。如果说，一个公司的中层骨干经过需求评审会议，仍然需求乱成一比，那就没什么可说的了，继续努力提升自己的水准，或者是补充真正的中层。

而PM的目标就是吸引需求评审会的意见，尽量让自己的需求和设计通过评审。各个小组的Leader还应该承担的角色就是各个组的方案评审。这是中层骨干必须要起到的作用。

小组的Leader还应该负责项目中风险的调控，考虑是增加人手，安排加班，项目延期，还是调整功能。与些同时，应该去审核最后的性能报告，看看是否达到系统的期望值，遇到了疑难问题如何解决。

测试组成员：测试级成员的职责不是做功能性的测试，也不是做性能测试。而是应该做边界测试和回归测试。功能性的测试主要应该由开发组成员完成，除了一些特别麻烦的，需要各种极端条件才能复现的，正常的操作过程中出现的问题，都应该是有开发组承担。性能测试同样是开发组人员自行完成，各小组Leader只需要知道一件事情，测试报告是否能够通过。

所以测试组的主要做的就是准确的记录，以及bug的统计。也不应该去天催促开发组的成员去改Bug。只需要去反馈给开发组的Leader就好了。整个CTO或者是技术总监应该以此为标准去衡量每个小组Leader的绩效。

回归测试是需要做的，但是也不是完全必须要做。如果能够积累足够多的自动化测试用例，就去正常使用它，如果不能，就尽可能少的减少回归测试。这需要跟开发人员沟通的比较清楚，他们往往更清楚，什么地方容易出问题。

接受线上的反馈并且记录也应该是QA的职责，如果Team足够细，可能会有运营或者是客服统一对外收集，然后交给QA，QA再负责录入Bug系统中。

基本的敏捷开发流程中的角色的职责大致就是这样的了。这不是一件容易的事情，其中的很多小细节，都照顾到了每个角色的职责和义务。理论上来说，如果有一张图的话，可以更清楚的画出来不同角色的功能。

每个人必须学会主动去为自己的事情负责

当有了明确的角色分工，你很快就能发现团队中，谁是能够尽守职责，更主动的人。每个人主动负责很难做到，特别在很多公司，并不注重对于团队凝聚力的培养，也不会注重和他们之间的交流，不知道他们想要什么。

所以这也是我一再强调的，敏捷开发并不仅仅是一个开发流程，更是一种管理的方式，他牵涉到绩效考核，公司福利，上下班制度等等你看不到的东西。

如果说你的团队成员并不能做到为自己的事情负责，那么你需要的就是，要么就是去更换团队，要么就是想办法去激励团队。

这件事情其实也不算难，第一，明确这种职责的分工是合理的，第二，Leader都需要了解自己的团队的状况。第三，不断的去强化和培养这种做事的习惯。

就够了。团队是需要打磨和改造的。这三点是敏捷开发实施的前提，而不是说，有了这三点，敏捷开发就一点能做好了。