想要直接看宣传栏的内容建议，可以略过第一部分“宣传的意义”和第二部分“宣传栏内容选择”，直接看第三部分“我的敏捷宣传栏”。想要了解我的思考过程，那就耽误点儿功夫，看看前两部分。
宣传的意义
我们都知道，宣传栏是宣传的一种手段，每天都能够看到各种各样的宣传栏，典型的就是车站平面广告。我们在看着宣传栏的同时，有没有思考过这样一个问题：“宣传的意义在哪里”？
百度了一通，宣传的意义可以简单概括为：（1）传递信息；（2）引导行为。
这里可以引用一个非常著名的模型——认知过程三角形，来说明宣传是如何起作用的。
认知过程三角形认为：通过开始的被动感受，来触发主动探究，进而与探究对象产生互动，也即行动，通过行动获得价值。
敏捷宣传栏也承载着这样的职责，把必要的信息传递给团队，并期望团队能够产生共同的价值观，进而在行为上求大同，以使团队能够深度协同，行如一人。
宣传栏内容选择
说到敏捷宣传，希望团队感知到哪些信息呢？
历史是一面镜子，前人经过实践，提炼出方法，进而升华成理论。因此，一切历史均可以借鉴，理论、方法、工具、经验教训、历史案例……，均可以作为宣传的内容。
宣传的形式也有很多，比如培训、论坛、知识库、宣传栏、……。那么，哪些信息适合作为敏捷宣传栏的组成部分呢？毕竟篇幅有限，必须抓住重点，又要考虑美观。不能像报纸糊墙一样搞得满墙都是，反而让人提不起兴趣。
对于内容选择，因为是面向大众，个人认为以基础认知性素材为主，由如下几个部分组成：
（1）价值观：这一部分传递的是敏捷世界的世界观，是理念的洗礼，世界观不对或者没有统一，方法论越好可能分歧越大，分裂的力量越大。
（2）方法论：这一部分主要传递敏捷遵循的过程、协同方法，以及必要的基础实践。
（3）工具：工具可以促进敏捷的效果，因此这部分必不可少。
（4）实践：对于重要的具体实践，要提供扫一眼就指导如何操作的引导，这里主要是会议。
是不是和没说一样，那就不多说了。下面就来说说我建议的敏捷宣传栏内容，以及选取这些内容的原因。
我的敏捷宣传栏
1. 敏捷宣传栏内容之“理念篇”
- 敏捷宣言
敏捷宣言是必不可少的，好像看起来平淡无奇，确是前人对敏捷价值观的高度总结，是一切行为的指导方针。
敏捷是为了快速响应变化而生，现实中我们对变化响应的怎么样呢？一个变化可能会触发多个变化，有些变化需要做出决策，当需要我们做出决策时，就以为这我们自身也要变化，我们是否有这样的勇气？毕竟，如果决策失误，谁决策谁就可能要因此而承担责任。
如果我们有了一套科学的变更决策原则呢？是不是决策就没有那么难了？敏捷宣言促使我本人做出了这样的思考，你说他有没有用？
不要再犹豫，把它打印出来，挂在你办公区最重要的位置，要保证大家经常见，天天见，见得多了自然就会有感悟，心理学证实，潜意识会帮助人们进行学习。
- 5种品质
这原是Scrum宣称的5种价值，个人认为，这完整的道出了敏捷团队和个人应该具备的5种品质。
Courage，勇气：每个人要坚持自己认为正确的观点，做对的事情，要敢于接收挑战，敢于辩论，认识到错误要敢于自我否定，在整个组织建立起向正确看齐的分为，不要因外怕辩论就总想着做不得罪人的好好先生，应该要弄清楚，辩论是观点的冲突，不是人与人的矛盾。这里，the right thing应该划重点。
Respect，尊重：这一点和Courage有很大的相关性，不以尊重为基础的勇气，很可能演变为人与人之间的矛盾，是团队求大同、存小异的基础。这里，respect本身就是重点。
Focus，专注：这里的重点，在于Goal，团队必须全体共同聚焦于工作目标，形成合力，而不是相互拔河导致力量损失。没有这个目标的指引，我们的团队实质上正在拔河中，正在无意识内耗。这里，goals要被重点突出。
Openness，开放：概括一下，就是只要工作需要，可以和任何人，沟通任何有必要的事儿。
Commitment，承诺：承诺对团队的贡献，并实际尽最大努力做到。
- Value（价值）第一
越过价值看框架，敏捷太简单了，不就是通过迭代小步快跑，中间应用3355（可参考网上文章：敏捷框架Scrum的核心要点）作为行动指导吗。
事实果真如此吗？开始觉得很简单，做出来的效果确合适差强人意。开发觉得产品没有把需求提前梳理清楚，到了版本要发布还在变；产品觉得开发动作太慢，无法响应快速变化，于是研发只好牺牲质量赶进度；测试更惨，根据需求写好的用例，忽然就失效了，产品的开发质量因为赶进度被牺牲，测试就成了产品上市前的最后一道安全网，压力可想而知。
是不是似曾相识？可能大部分的敏捷团队目前还是这样的状态。正是面临这样的痛点，才有机会深入思考现象背后的原因，直到看到这张图才恍然大悟。之前只是在模仿敏捷的活动，只是徒有其表，本质上还是奉行瀑布思维那一套，或者可以叫“敏捷瀑布流”。虽然把版本开发划分成了多个迭代，内部其实在整个版本范围内还是按照瀑布方式操作的，并没有真正按照敏捷思维的要求，每个迭代交付用户价值（满足质量目标的可用产品）。
价值是敏捷的原始推动力，及早的交付价值是敏捷的精神内核。“敏捷瀑布流”不仅没有使项目更成功，很可能使团队造成我们正在应对变化的假象，而失去了对目标/价值的专注。每个迭代都要交付可上线的产品（至少绝大部分时间），不要妥协，如果做不到，一定是管理出了问题。
价值的诠释应该是多维度立体化的，比如：如何评价产品应该交付何种价值？开发应该交付何种价值？测试应该交付何种价值？运维应该包括何种价值？这些价值应该在何时被定义？应该在何时被交付？应该在何时被检查？应该由谁来检查？
不同项目的不同阶段，其价值的具体定义可能会非常不同，管理的作用就是要抓住其最根本的相对静态的东西，形成诠释和评估价值的基本原则，来指导价值第一这一理念的实质落地。
- 敏捷成熟度
井底之蛙，永远不会知道世界有多大。敏捷成熟度模型，告诉我们敏捷可以走多远，帮助我们识别目前所处的位置，下阶段我们应该向这哪个方向努力。
类似CMMI模型，下面是Thought Works的Agile Maturity Model(AMM)模型，每个级别都有其实践及对实践的目标要求。可以对照着看看，我们自己处在什么水平，然后就知道应该向哪里使劲儿，需要做出哪些努力。
个人建议应用中不能照搬框架，要根据自身需求，对实践进行重新归类和梳理，以服务于自己的敏捷演进目标。下面图形只是个草稿还没有完成，重新归类梳理后把链接发在这里。
同时，既然都上墙了，不如把它作为敏捷演进项目的跟踪看板，哪一个实践达标了，就在后面贴以面小红旗，这样全员可以随时看到需要演进的内容，以及成果和不足，并促使团队探求提升的方法。
- 敏捷流 & 瀑布流
瀑布流：带着明显的计划思维，以自我为中心，事先规划好一切，最后验证产品和市场。成功收获不一定更大，失败的代价更大。
敏捷流：非常典型的市场思维，以客户为中心，快速迭代产品和市场。成功收获不打折扣甚至中间产品也可以面向市场销售，失败的代价要小得多。
2. 敏捷宣传栏内容之“框架篇”
这一篇是敏捷在理念直到下的具体表现形式，包括过程、活动、工件、角色分工等。
- 敏捷框架的23355
过程、活动、工件和角色
下面是一张来自于网上的Scrum Framework，为了便于记忆，这个框架经常被概括为3355（请参考：敏捷框架Scrum的核心要点），对于这3355我不多解释，有大量的网上文章可以参考。我在这3355上，增加了一个2，对，就是要2，而且必须要很2才行。
这个2指什么呢？就是Release Plan和Sprint Plan。大家都知道计划很重要，可是现实中很多时候，我们的Plan都是拍着脑袋做出来的，至于怎么拍的应该说大家都拍过，我用着两个计划说一下，怎么能够减少拍脑瓜。
看看如下的情况，是否似曾相识？
我们的产品在制定版本发布计划时，是否既给研发下达了版本内容的死命令，同时也下达了发布时间的死命令？好要求保证产品质量？
如果研发说完不成，产品就告诉他们，我的要求是合理的，你应该来前线看看市场的炮火，哪有时间给你四平八稳做研发？
如果你是研发，你怎么看？
如果我是研发，在产品提出这样问题的同时，我会要求他回过头去问问自己，我这一期的业务目标是什么？我的所有需求对业务目标都是至关重要的吗？我提供给开发的Story是否已经进行了解耦处理，每个Story都能够独立的被集成发布？我提供的需求是否在迭代过程中能够相对稳定而不是变来变去（敏捷要应对的变化不应该是因为主观不努力而带来的变化）？如果开发无法完成所有的Story，有哪些是可以暂不发布的？
为什么思考这些问题？因为产品和开发都是敏捷团队组成部分，大家应该有一个共同的目标，那就是以产品承载的业务目标作为指引。只产出内容不设定目标的产品工作是不负责任的。
说到这里，就和我们之前说的“价值第一”的理念对上了，制定Release Plan的过程正是我们确定业务目标最佳时机，并以此直到需求的管理和Sprint Plan的制定，以及当最后不能够研发不能交付产品所要求的一切时，为变更决策提供了可行的依据，从客观上解决了如何拍板决策的困惑，和避免了谁拍板谁担责的尴尬。
Sprint Plan就不用说了，大家都在做，定周期、看资源、定需求、拆任务等等。这里至关重要的是，开发团队在每个Sprint完成时，务必朝着交付一个可发布的产品去努力，中间发现任何于此目标有偏差的情况，都应及时与产品沟通，确定需要做出的必要变更。
3. 敏捷宣传栏内容之“实践篇”
这里主要指敏捷的几个主要会议：计划会、每日例会、评审会、回顾会。这些会议应该怎么开？谁应该参加？会议形式有何要求？哪些议题可以在会议议程之内？哪些不应该放在议程里面？
这些内容最好的张贴位置是在会议室，看一眼就是到会议怎么开，不用费劲儿的去想我做对了没有，每个团队的会议都是标准的，也便于复制。
具体内容我就不整理了，自己网上百度吧。
4. 敏捷宣传栏内容之“工具篇”
看板、燃尽图……，自己搞吧，能够引导好的敏捷项目的打开方式即可。
5. 敏捷宣传栏内容之“协同篇”
这一部分的重点有两个：（1）突出各角色职责；（2）明确工作协同时序。明确了这两点，也就明确了团队个体成员间的配合关系和时序。
下图的Business Owner，就说明了，产品要负起责任来，梳理并竖立起全团队的目标，虽然现在有了动车，可火车跑得快，还得靠车头带，不然大家横着走吗？产品要带好头儿，否则从一开始就是乱的。
任何协同，都要谈到时序，时序错了一切全乱，各岗位和个人要思前想后，上游配合不好要反馈，同时要给下游准备好输入。
6. 敏捷宣传栏内容之“质量篇”
这一篇实际不专属敏捷开发，而是对一切研发都试用的内容，就是质量。不多说了，看图吧。
敏捷 & DevOps
待补充
参考资料
本文在写作过程中，参考了如下网上文章，感谢作者的无私分享。
Agile maturity model from Thoughtworks
Difference Between Agile and Devops
4124
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
