以下内容学习、摘录自《技术管理之巅》
4.1 玩转互联网敏捷开发
4.1.1 玩转产品敏捷、项目敏捷
敏捷开发已经成为现在最为代表性的开发方法论，并且在世界范围内得到了广泛的应用。大多数互联网公司以产品敏捷为主，项目敏捷作为补充，很好地解决了产品和大项目的开发管理问题。（介绍敏捷开发的相关书籍和资料都比较普及，可另行参考。）
产品敏捷，就是一个产品小组，围绕着软件产品进行的敏捷开发过程，是最常见的敏捷开发模式。
项目敏捷，只的时大项目在项目经理的领导下，有多个敏捷产品开发团队一起协同开发的过程。项目敏捷可以理解为一个大的迭代，里面包含了多个小迭代。
书中还提到了“分布式敏捷”的概念，主要是指导异地开发团队开展敏捷开发。
4.1.2 看板适合哪些技术团队
“Scrum”和“看板”是敏捷体系中不同的实践方式。
首先，它们的共同点是：
两者都符合精益和敏捷思想；
都使用“拉动式”安排日程；
都限制开发中中得工作数量；
通过透明度来驱动过程改进；
都致力于可交付的软件产品；
都基于自我组织团队；
都要求把工作细分；
发布计划都基于经验数据；
都持续优化。
其次，它们的不同点是：
在迭代周期上，“Scrum”要求固定迭代周期，“看板”没有固定迭代周期；
在工作任务细分上，“Scrum”要求细分任务，并在一个迭代内完成，“看板”没有规定任务大小；
在是否允许插入任务上，“Scrum”不鼓励在迭代开始后插入任务，“看板”允许随时掺入优先级更高的任务；
在指定角色方面，“Scrum”要求有Product Owner、Scrum Master等角色，“看板”没有指定任何角色；
在任务优先级上，“Scrum”要求任务有唯一优先级，“看板”不要求任务优先级。
从上面的对比可以总结出：看板能够功能更快地响应需求变化，适合创新型、需求变动大的产品开发。但看板对开发团队的整体素质要求比较高，所以建议实施看板的团队，至少有比较懂敏捷开发的人作为教练，或者团队已经实施过Scrum、且成熟度较高，才可以尝试看板模式。
4.3 开发需求堆积如山，怎么破
4.3.1 建立以价值为导向的需求管理机制
为什么要对需求进行管理？因为面对源源不断的业务需求，如果开发团队不分轻重缓急、全盘接受的话，技术团队就会疲于应付，结果就是做了一堆对生意促进小的需求，而一些对生意促进大的需求没有被及时受理。缺乏对生意本身的思考，就很难发挥技术应有的价值。
何为“价值”？凡是能使企业往好的方向发展的事情都是有价值的，比如：生意增长、运营效率提升、成本下降、用户体验改善等。
价值是可以量化的，且必须明确为具体的度量指标。“极大提升客户转化率”是不能被接受的需求价值，而应该是“提升客户转化率5%~10%”。（需求价值的度量在实际工作中并不是一个简单的事情，不仅业务部门，连信息人员都多次感叹“这个需求咋个说得清效能嘛”，还需努力。）
4.3.2 价值有预估，达成有回顾
需求的价值有两个用处：一是通过判断价值大小来对需求进行优先级排序；二是跟踪需求价值是否达成，达成就增加业务需求提出部门的信用分，反之亦反。
如果某个业务部门的“信用分”高，说明该部门的需求靠谱、对生意的帮助大，在同等条件下就应该优先考虑多投入开发资源。
通过公示“信用分”，营造一个以价值为导向的需求提报氛围，进而得到更多有价值的需求，形成良性循环，使得需求得到有效地治理。
4.3.3 建立需求管理闭环
在提交需求时，业务人员需要估算这个需求带来的价值，价值必须是可量化的；
排期开发阶段，业务人员和技术人员一起对需求池力的需求进行价值PK，决定哪些需求先做；
上线运行后，验证预估价值的达成情况，评判信用分；
需求调整阶段，根据实际结果调整需求和价值，然后整理成新的需求，加入到需求需求池中，不断迭代。
4.4 自动化测试，让测试飞起来
4.4.1 从零搭建自动化测试
自动化测试的优点：测试速度快；测试准确度高，不受人为因素的影响；测试可以反复执行。
但什么样的技术团队适合做自动化测试？首先，开发团队有规范的测试流程，并且软件质量比较好；其次，有足够的人力投入，即有专门的测试团队；最后，想更高效地开展测试工作，进行测试人员的转型。
一个小型的自动化测试团队，主要有以下三种角色：
测试框架设计师：根据测试业务，评估自动化测试的可行性，并进行工具的选择；进行自动化测试用例的编写和测试脚本的开发及结果处理分析；组织自动化框架和自动化用例脚本验收评审工作；制定并推广自动化测试的流程和规范；对测试团队进行自动化测试技能培训；指导自动化测试的实施。
测试用例设计人员：分析手工测试用例是否具备可制动化，对不符合要求的用例进行调整维护；负责自动化测试用例的设计开发及今后的维护工作；负责自动化测试脚本的验收工作，监督测试脚本业务逻辑是否与设计好的自动化测试用例一致；由团队中对业务和手工测试情况最熟悉的人担当。
自动化测试脚本开发人员：根据自动化测试用例要求，负责自动化测试脚本的设计与开发；负责脚本合并联调工作；负责后期的脚本维护工作；对测试用例的设计不足提出改进意见。
4.5 私有云，走进运维云时代
4.5.1 企业私有云的构建之路
私有云的构建，大致经历三个阶段：
流程和工具的建立，指的是系统运维工作中，基本流程制度的建立和维护工具的建立，流程制度包括：服务器申请和回收流程、数据库操作流程、IDC设备维护流程、域名管理流程、IT变更流程等，并建立一些小工具帮助提升效率、降低人为操作失误。
自动化管理和快速交付，重在建立更高效的自动化管理工具，包括：虚拟机管理、存储管理、自动化装机、智能流量调配、缓存管理平台、自动化监控预警平台等，这需要一支运维系统开发团队，把运维工作全面自动化、智能化。
私有云，最终将各类资源进行虚拟化和服务化，实现资源的动态管理，按需分配，最终目标是“全自动化为主、人工干预为辅”。
