十九、与其他方法论共存
混合Scrum和顺序式开发
1、三种交互场景
1）瀑布在前模式
Scrum和顺序式开发在项目的开始时就交汇，通常发生在组织有项目批准障碍时
需要一开始就创建需求规格说明书、项目计划等顺序式开发特有的文档
2）瀑布在后模式
Scrum和顺序式开发在项目的结束时交汇，通常是在测试阶段
这种场景比前一种好接受一些，毕竟开发工作已经完成了
3）瀑布两头模式
最难的模式，通常由两个团队协同开发，一个团队使用Scrum而另一个团队使用顺序式
2、冲突的3个领域
可能发生的三种冲突：开发过程、业务过程、人
解决冲突的办法：
1）所做的分析超过Scrum通常所需要的
2）创建一个刚好足够的流程，而不是分拆一个大的流程
3）定义一个划分了Scrum和顺序式方法的系统架构
4）采用那些不管什么流程都能适用的敏捷实践
5）教育项目干系人
3、Scrum和顺序式能永远共存吗？
不能。
让Scrum暂时与一个顺序式过程并存在很多时候是必要的
但敏捷不是目标，敏捷意味着持续的改进
监管
项目监管和项目管理不是一回事，从项目管理中分离项目监管是可以的
1、用非敏捷的监管来运行Scrum项目
1）预先协商和设定预期
2）报告要满足当前的期望——希望甘特图，就提供甘特图，希望燃尽图，就提供燃尽图
3）邀请他们参加你的过程
4）参考成功的例子——尽你所能让前2个项目成功，将减轻或减少监管的检查点
兼容
1、ISO 9001
最痛苦的事情是必须建立一套质量管理系统，这将花费相当长的时间，而且文档需要非常齐全
2、能力成熟度模型集成（CMMI）
Scrum目前允许通过CMMI 5级模型
CMMI和相关的审计并不强制一个特别的方法论，而是尝试帮助团队遵循最佳实践
3、实现兼容
1）在产品Backlog上投入足够的精力
2）将监管相关的工作放入产品Backlog
3）考虑使用检查列表——checklist不要引入新的强制性步骤
4）自动化
5）使用敏捷项目管理工具——索引卡、图表、jira、禅道、钉钉等
6）慢慢而稳定地前进——增量进行
7）跟审计员一起工作
8）引入外部的帮助——引入一名对认证有经验的外部咨询师或者SM
二十、人力资源、后勤和PMO
人力资源
1、管理层次结构
企业结构应该尽量扁平，在团队成员和公司高层之间的层级越多，就越有可能慢慢失去控制
1）向SM汇报
倾向于汇报给职能经理，向SM汇报不应影响绩效
2）向PO汇报
PO的工作的部分内容就是尽量更多地加入功能特性并更快地提交它们
不建议向PO汇报，也不建议SM向PO汇报，但PO是老板另当别论
2、定期的绩效评估
1）评估要尽量消除那些倾向个人的因素——字面意思
2）要包含团队协作的因素——“团队在预算和时间段内有效地管理他们的任务”
3）更频繁地评估绩效，每年超过一次——字面意思
4）广泛收集反馈意见——从其他人收集反馈，范围要大
5）培训人力资源部门并让他们参与——字面意思
3、开除团队成员
团队本身不应有权从团队中开除某人，团队组成的最终决定权必须留在企业领导层手里
4、职业发展
企业实施Scrum后，判断某人的成功不能再用有多少人向他汇报来衡量，而是要根据这个人能承担多少责任来衡量
精力充沛的脑力劳动会造就更高的绩效，最终产出更好的产品
对出色表现的感谢就是更有挑战性的项目
5、只要有人参与，就总是存在与人相关的问题
软件开发本质上是一种天然的人力密集型活动，所以会有各种与人相关的问题
后勤
1、空间
隔间和公共区：一对沙发、一个白板、一个书架
开放区域里的协作精神和内在的能量会让整个团队充满活力
2、将作战指挥室变到整个空间
创建一个大型的、开放的区间，确保有足够空间给团队里的每一个人
这经常需要得到领导层的支持才可以实现
3、家具
开放的空间和可移动的桌子很重要，桌子需要适配结对编程，手机是必要的，SM最好坐在靠近隔间的门口，以便阻止和询问闲杂人等
4、在工作空间里应该可见的东西
1）大的、可见的图表——燃尽图是必要的
2）额外的反馈设备——各种指示灯、测试服务器告警等
3）团队里的每一个人——SM必须，PO可选但推荐
4）Sprint Backlog
5）产品Backlog——堆叠在显眼处，使团队有积极性
6）至少一个大白板——鼓励突发的会议
7）一些安静和私有的空间
8）食物和饮料——小冰箱、咖啡机、小吃、零食
9）一个窗户——自然光非常不错
项目管理办公室
1、人员
敏捷的PMO应该做到如下事情：
1）开发培训课程
2）提供指导
3）选择和培训教练
4）挑战现有行为——主要是指阻止反对者，以及提醒团队戒骄戒躁
2、项目
1）协助报告——每个项目的周状态报告以及会议
2）协助完成符合性需求——比如ISO 9001这种带有数据安全性的标准
3）管理新项目的流入——抵制快速启动项目的冲动
3、过程
1）提供和维护工具
2）协助建立和收集度量——聚焦于在递交价值方面有何表现
3）减少浪费——除非有必要，避免引入文档、会议、批准等
4）帮助建立和支持实践社区
5）保持团队间适当的一致性——确保好的想法在团队间快速地传播
6）协调团队——解决分歧和工作重叠
7）使用Scrum的典范——使用Scrum来运作PMO本身
8）和其他部门协作——与HR和后勤通力协作
4、重新命名PMO
敏捷PMO是一个好名字，不建议取其他的外号，这并不是重点
底线
个体和交互胜过过程与工具
要把HR、后勤和PMO视为需要招募的盟友而不是敌人
