敏捷21天打卡-创建敏捷环境

• 前情回顾

上一节我们讲到生命周期，包括预测型、迭代型、增量型、敏捷型：1.基于迭代的敏捷，2.基于增量的敏捷。

同时也讲到，根据团队现状、项目情况选择适合的开发模式，最终目的为了确保项目时间、成本、质量可控！

方法	特性	动作	交付	目标/成果
预测型	固定	整个项目期间执行一次	单次	管理成本加大
迭代型	变化	重复直到正确为止	单次	正确、有效
增量型	变化	对给定的增量执行一次	频繁部分	速度
敏捷性	变化	重复直到正确为止	频繁部分	将客户利益最大化

wip(在制数)：

最早由丰田提出，并取得很好的成效。如果是工业互联网型的企业，会更了解限制WIP对企业的生产的作用。同样，该模式也适用与IT界。

在敏捷开发中，WIP限制决定了每种情况下的工作流中可以存续的最大工作量。限制进行中的工作数量可以更容易辨识团队工作流中的无效工作。在情况变得更糟前，一个团队在持续交付通道中的瓶颈是非常容易辨别的。

通过聚焦更小任务粒度/时间盒，来提交“完成”数，WIP限制可以让阻碍和瓶颈显而易见。当有明确指示现有工作遇到瓶颈时，团队可以聚焦在阻塞问题上尽快的理解、实施和解决。

举个栗子：高速公路到节假日就会塞车，当稀缺资源被大量占用时，就会引起质量、流动型的下降，故限制团队在制WIP数，聚焦在本次要完成的故事/时间盒（更小粒度）。专注地完成在制品，WIP限制鼓励的是“完成”的文化与敏捷所提倡的核心思想不谋而合。

 --引用腾讯

限制WIP

过程中工作(WIP)，又称为“在制品”，是指已经开始但还未完成的工作，在精益中被视为浪费。库存也属于浪费，因为在购买、存储和维护方面会产生费用。减少库存的一种方法是通过移除系统瓶颈来减少WIP。敏捷提倡通过在开发新的特性前完成所有特性的WIP限制来限制WIP。WIP限制相当于迭代待办事项，在迭代评审时所有的特性都应当完成。

从帕彭迪克的七个软件浪费列表看，WIP本身也是一种浪费，过多的WIP会产生一些问题，包括：

• WIP占用了项目资金但在验收前完全不能让客户获取投资回报率。这意味着投资没有收获。
• WIP隐藏了工作过程中的瓶颈。包括减缓全部工作流(或生产力)和掩盖工作效率。
• WIP存在返工的风险，因为产品验收前都有可能发生变化。如果WIP很多，那么在需要变化时就会有很多废品或者昂贵的返工。

鉴于这些问题，敏捷方法提出了限制WIP。在敏捷中，常规限制WIP做法有以下两种，帮助减少项目中占用资金、返工和浪费的风险。

• 1、限制数量： 使用面板来限制系统中的工作数量并帮助确保限制WIP没有过量。看板面板通过展示在任何给定的时间的当前应该被进行中的工作来限制WIP。
• 2、限制大小： 限制看板面板的大小，只有被选择的任务才能够放入该工件。敏捷团队使用限制WIP的看板面板工具来识别和移除瓶颈障碍，以提升过程利用效率。

从来没有限制WIP的看板面板可以看到很多WIP，也意味着项目团队都忙于工作，但是不能区分那个任务是闲置的、瓶颈在哪里。限制WIP可以向我们展示障碍在哪里。

WIP被用来在人与工作项之间做平衡，限制WIP的目的是优化工作吞吐量，而不是优化资源利用率。而WIP的值是通过调整才算出来的。限制WIP帮助我们识别过程中的瓶颈，并最大化生产率，像某些城市实行单双号的车辆限行，通过限制路上通过的车辆可以让交通更通畅

 书归正传，所谓“工欲善其事必先利其器”，团队向敏捷过度，是需要一定时间，至于长短要根据团队自身的情况而定。

敏捷推行的影响因素：

1. Scrum教练的专业度、情商、控制力、逻辑思维能力和计划策略执行力、业务熟悉度、IT专业指示储备度、部门有限权力等；
2. 团队人员的意向以及对敏捷模式的知识储备；
3. 外在的支持度（公司、客户等）；
4. 是否愿意奉献，即仆人式、导师式、教练式；每一种角色要付出的辛劳和汗水要比组员多很多倍。

在基督教义中，牧师、传道、各学习小组长采用的仆人式的做法，在敏捷中也是如此，对敏捷教练、项目经理、技术经理/主管的要求，无论是从IT专业范围还是情商、责任心等方面有较高的要求。

因素第一条延申：

1.要担当敏捷项目的推动人，获取公司高层的支持，只有自上而下的推定才能事半功倍。

2.“形象好、气质佳、声音甜美”这是企业文员或助理的招聘基本要求，同样“情商高、善于应对突状况、刚柔并济的手段”也是敏捷教练所要必备的条件之一，优点是可以敏锐发现团队不良的气氛，找出原因，迅速消除影响团队平稳的能力。试想，一个火爆脾气的教练，只会让团队人员战战兢兢，其敏捷在组员中的阻力可想而知，这里忍不住说一句“”做事高调，做人低调“会有意想不到的成果哦。
3.专业技能的涉及范围，IT这个行业，高速发展，项目用到的技术也是多种语言混合，非单纯的一门语言。我们要做斜杠青年，尽最大努力拓展自己知识面，优点是可以做团队中的消防员，任何岗位都可以胜任或指导组员，从而获取组员的信任度和依赖度。

4.逻辑思维能力和计划策略执行力，见过一些被断章取义的文章，敏捷不需要计划，提倡自由。所谓自由是指在有限空间里的自由。计划、策略、执行力在项目前期，敏捷教练已经做了充足的准备，只是按照策略和计划稳步向组员推进，并通过不断的刺探、反馈调整自己的计划。再说执行力，笔者一直有一个观念”盯死它“，任何一个项目或任务都要通过这种方式，人是有惰性的，只有通过适当的放手和严格的以结果为导向的收单，才会确保项目/产品的质量和进度。

5.有限的权力是指负责人在部门中，有奖惩权力、财务维度权力。试想一个有功不赏的团队，有过不罚的团队战斗力和凝聚力会有多高。财务维度指调节气氛、化解矛盾中所需的物质基础，别指望在团队氛围不对时空口白牙说服团队组员，化解矛盾。

　　

因素第二条延申：

1.团队人员的主观意识，是否把企业当成一个平台，愿意与企业一起发展。意愿不明确，就没有动力。做一天和尚撞一天钟的间的太多了，也劝各位别在这种人身上浪费时间；要把有限的资源倾斜到有意愿的那群人中，否则就是对大家的不公平，
也是对资源的一种浪费！

2.组员对开发模式的了解以及愿意对新知识的尝试度。缺乏了解不可怕，后期专业指导即可。如果组员畏惧因拓展新知识引起的改变，从而拒绝而改变，建议参照第一条。

　　

因素第三条延申：

外在的支持度，可以来自企业内部高层、客户、跨职能部门；一个好汉三个帮会事半功倍，不多赘述。

　　

因素第四条延申：

重中之重，敏捷思想中的核心。至于如何做，采用哪些付出等，建议大伙到招聘网站上搜索主管级的招聘要求，逐一对照，缺少的努力补上。

 

敏捷团队的组成要素：

1.3-9人，是默契度而定；

2.集中办公，面对面交流；

3.100%专职成员；

4.团队成员的自我管理意识；

5.结对编程；

6.跨职能团队成员，用于调配资源、接收反馈、充当桥梁或纽带的作用；

7.T型专家，可以向下指导组员研发，向上可以从成本、利益等层面指导/建议高层决策者；

8.产品负责人，这项很重要，”背锅侠“是必须的，开个玩笑哈，事实也确实如此~；

9.坚决消灭信息孤岛，要做到信息通畅，敏捷方可更好的推动起来。

啰嗦这么多，送大家一句忠告”任何行动之前，先谋略而后动，以结果为导向。可以采用SWOT分析法、三三分析法做到胸有成竹“。