高效率软件开发团队的理想组织架构大概是这样子的。首先是一个情商高，懂技术，人品好的开发经理，这个开发经理能够协调好直男和程序媛的各种小情绪和因为开发任务和技术讨论引起的小别扭，他因为懂技术，所以不会瞎指挥，乱发表意见，但是评论往往一针见血，能够抓住问题的核心。能够判断技术能力高低和技术选择的对错，但是这个本领只用在绩效考核上，平时对开发团队的技术讨论不发表意见，只提供输入，并积极聆听。他的rolemodel是刘备。
其次我们需要一个高瞻远瞩，精益求精，善于学习的产品经理，最好有点儿艺术范儿。设计出来的功能不仅好用，还得有颜值（当然颜值我们也可以让UX来帮忙）。这位产品经理要能够积极学习竞争对手的产品，对于用户的需求和市场发展趋势有独到的见解，能够根据用户的需求，对于对手的产品能够扬长避短，设计出能够解决用户实际问题，好用好看还用得好的需求。产品经理兢兢业业，功能实现完毕，马上各种测试轮番轰炸，帮助开发人员挑毛病。小毛病有可能引发大的需求或者发现大的bug，一方面帮助提高代码质量。另一方面也可以检视自己的需求适合合理。通过这种设计，测试，再设计的迭代来不断完善自己的设计。这个产品经理得有追求，不能说就这样吧，差不多。在乔布斯眼里可容不得这种妥协，他一定说找到最好的平衡，代表用户发现最有价值的需求，并以最酷的方式体现出来。
产品经理的需求出来了以后，我们的PO就要上场了。PO对技术要求就比开发经理要更高了，关键是判断力强，对产品的实现具备整体把握能力。PO具有完整产品开发经验，能够将产品经理的需求，分解为更小的功能需求，并合理的安排实现的顺序。对于产品经理的需求，PO基本知道如何实现，粗略知道技术复杂度，然后能够和产品经理一起评判需求的优先级，确定放在合适的sprint进行实现。
经过产品经理讲backlog拆分完毕，就要进入实现阶段了。这时候首先需要的是一个技术博大精深，开发经验丰富的总架构师。第一个runable的最小的原型需要总架构师亲自操刀，当然也许原型的UI需求前端工程师进行协助。总架构师亲自操刀定义个runable的原型可以加深他对产品的理解，有利于架构设计的技术选择和平衡。如果总架构师对于CloudOperation或者软件持续集成也有经验，总架构师还可以把开发环境，测试环境，持续集成，自动化测试等一整套的环境搭建起来。如果总架构师没有这方面的积累，测试和持续集成环境可能需要质量管理的专家进行协助。基于第一runable的原型，总架构师进行总体技术设计，完善第一个原型，最后将完善后的原型作为sprint0的结果，开始进入持续的开发阶段。之后总架构师角色转换为高级程序员，一方面继续写代码，另一方面就像代码评审，帮忙其他开发人员解决技术问题，提供技术指导。
软件开发人员则根据团队的大小配置合理数目的前端和后端工程师。软件开发高级和初级程序员比例大约1；3，这样保证一个高级程序员能够带教3个初级程序员，比例过小，则带不过来，容易导致质量问题。前端和后端工程师的比例则需要根据产品的性质来进行搭配。
SCRUMMaster需要是经过SRUM认证的具备项目管理经验的软件开发工程师兼任，为了降低成本，没有必要设置专职的SCRUMMaster的职位。SCRUMmaster的主要职责是保障开发团队的工作能够按照SCRUM的模式进行运作，不受开发经理的行*命令干扰。SCRUM的另外一个职责就是承担了部分项目管理的职责，跟踪Sprint的执行情况，遇到问题及时提出来，进行警示。
SCRUM不建议专职的QA，但是有QM，QA的工作应该有Developer在QM的指导下完成。Developer对自己的软件质量负责，而不是其他人。但是考虑到开发人员好不容易把功能实现完毕，会有一种懈怠的心心理，可能在单元测试方面就积极性不那么高了。我们可以借鉴结对编程的思路，让两个开发人员互相对对方的代码进行单元测试，确保测试的充分完备，深入细致。
企业软件研发勤思录