阅读笔记《廖为民2018年11月在科技创新实战沙龙的分享》

原文链接

一、以下是要点的理解、记录：

传统软件开发&敏捷开发 VS 古典油画&印象派画
古典油画就是追求画得像，而敏捷开发方式注重用户综合感受（不局限于看着像不像的单一视觉感受）；敏捷的发展与持续集成、持续交付、自动化测试等基础技术的发展有关。

2001年敏捷宣言：

以人为本：个体和交互，胜过"过程和工具"；

价值导向：可以工作的软件，胜过”面面俱到的文档“；

客户为先：客户合作，胜过“合同谈判”；

拥抱变化：响应变化，胜过”遵循计划“。

时间、范围、成本三角形：团队确定，则成本确定；时间和范围之间进行权衡，权衡的核心依据是业务价值。

敏捷过程的结束是写故事，而不是业务说明书，是基于用户画像实现价值传递。

用户故事表达的核心：作为<某类用户>我想要<某个功能>以便<达到某个目的或实现某种价值>

敏捷适合市场一线面向市场的应用团队； 对外包人员不适合做敏捷，外包人员更习惯于按需求完成任务。

看板与敏捷（scrum)：可以借助看板把传统项目的流动效率提高，取得流动效率和资源效率的平衡；而在需要响应快的领域，需要积极响应市场的方面，对应的团队相对是比较固定的，我们可以这部分投入SCRUM模式。

二、阅读点评

这篇回答了《廖为民：将精益思想应用于项目集管理的相关思考》遗留的一个问题：如何应对变化？

上篇中重点阐述的基于看板的精益项目管理，更侧重的是提升传统项目的效率。拥抱“变化”则需要更侧重于SCRUM模式。对整体需求做分层时，靠近市场一线的应用，可以归入“快速响应变化”的SCRUM模式层面。

建立一个敏捷响应变化的”敏捷作战区域”？ 作为IT主力开发队伍与业务一线需求之间的一个缓冲带，是IT开发响应市场需求的第一道防线。该“敏捷作战区域”中有相对常驻的一些团队，其日常开发工作大概率属于以“快速”交付价值为首要诉求的，因此常驻“敏捷区域”；同时，允许其他团队的动态入驻和撤出该区域。

经过“敏捷作战区域”第一道防线的筛选之后，剩下的需求就归入更加主流的IT项目管理中去，实施精益化、效率化管理。