《scrum敏捷软件开发》
第四章：渐进敏捷
底层员工发起，取得成功后，企业内广为推广；
改进backlog：
增加使用scrum的团队的数量
增加对自动化测试的使用
使团队能够实现持续集成
想出如何确保每个团队都能有一名产品负责人（product owner）
确定怎样度量实施scrum的影响
增加对单元测试的测试驱动开发的使用
改进backlog过程中邀请团队成员一起头脑风暴 ，结束后询问热情最高的事项，选择其推进。
成功敏捷的推进例子：
清楚表单背景：为什么变革？为什么现在？为什么用scrum？
鼓励对话：美好的东西总在人们的对话中出现。
提供资源：实施scrum需要花费时间、精力和金钱
设置合适的目标：具备清晰定义和确实可达目标的变革尝试有10倍的成功几率。
变革无需强加，它只是需要释放
第五章：试点项目
理想试点项目四个属性：
持续时间：建议3~4个月；（太短会造成大家对scrum的误会没有说服力，太长风险极大万一延期也没有说服力）
规模：试点项目的参与团队，最多不要超过5个否则沟通成本会成为极大的风险；
重要性：一定要选择重要性高的项目，否则不会引起其他的关注；如果项目不重要，大家也会认为转型不是很必须；
发起人的保证：愿意和团队一起工作的人是很关键的；
选择合适的时机启动项目：
完善的序曲文档（用户故事）
濒临失败的项目：只要有足够的时间修正和继续的项目，虽然危险，但必须改变，最后如能交付，往往就视为成功；
试点项目：
团队的组建可以寻找原来熟悉的靠谱选手，所有人要要有主观意愿与能力、技术能力、沟通能力等。
scrum是能够容忍一定程度上需求的更改，但是相对频繁的修改一定影响生产力，毋庸置疑；
总结：
渐进敏捷和试点项目，这个两个维度读完还是感触颇深的，做敏捷项目（或者说原来做过的非敏捷项目）规矩就是规矩属实是不能马虎，如果某些条件未满足，或者投机取巧的方式，项目周期长的，极大可能最终得到的一定是很大程度的失败（损失是不可估量的）;
一个未达到标准的结果，情况好的还可以延期完成，情况不好的就是0，团队成员也会因此受到严重影响（例如：心态、稳定性...等等）;
