文章目录
判断公司是否做敏捷转型
VUCA时代的特点是不确定性的，敏捷是应对不确定性的方法。一般C端业务是适用于敏捷转型的。我们从项目需求、执行、交付方式和最终目标这几个维度确定是否适合做敏捷转型。
一、项目的生命周期
项目的生命周期包括五个过程。
- 启动过程：是一个包含了获得授权，并定义一个新项目或现有项目的一个新阶段，然后正式开始该项目或阶段的过程。比如，我们在开始做斗地主第一个手游版本之前，会先论证市场、竞品和用户商业模式，然后形成结论之后输出项目章程。在这个过程中，我们投入的资源会比较少，只有制作人、产品负责人和项目经理，以及几位研发领导。
- 规划过程：是通过明确项目范围和优化目标，为实现目标而制定行动方案的一组过程，使团队工作能够有序发展。比如通常我们的项目会分成四个阶段计划：Demo 阶段、基本功能实现、灰度发布和正式发布，每个阶段都有其范围、资源投入情况等；广州这边很多公司是有开发阶段，SIT阶段，UAT阶段，PRE阶段，PRO阶段。其实质是一样的。
- 执行过程：这个过程重点关注的是信息的沟通和项目进展。
- 监控过程：是指通过跟踪、审查和调整项目进展与绩效。以识别必要的计划变更并启动相应变更的一组过程，使得项目朝目标方向进展。这个过程我们主要控制四个方面：范围变更、质量控制、状态报告及风险应对；
- 收尾过程：这个过程组的主要价值是总结项目过程中遇到的坑，并对此持续改进，帮助我们在今后的项目中完成得更好。
总结出了四种项目生命周期：预测型、迭代型、增量型、敏捷型。我们可以根据自身项目的特点来选择合适的类型，帮助我们更好地推进，也就是说我们可以以此来判断项目是否适合敏捷方法。那么，我们先来看一下这四种项目生命周期的具体内容。
1.预测型生命周期
首先是预测型生命周期，通常我们所说的项目生命周期其实就是指预测型生命周期。
预测型生命周期是以分析、设计、构建、测试和交付为顺序的方式执行的，这要求我们制定详细的计划，什么时候启动项目，什么时候结束项目。在此过程中，我们尽量限制变更，以至于我们需要成立变更委员会这样复杂的机构来处理每一次变更的审批。因为这样项目尽可能地减少了处理变更带来的成本，有利于最小成本地交付产品。
在项目刚开始制定计划时，团队必须考虑到各种项目制约因素，并将这些制约因素加入风险和成本计划当中。这样当我们在执行计划时，可以严格控制对这些计划的影响，尽量少让项目产生变更。
因为预测型项目强调顺序执行，所以通常不会在项目过程中交付产品或服务，这样会产生一个较大的风险，就是一旦对客户需求理解不够，或对需求产生了分歧，那么前面做的很多工作将付之一炬。不建议在项目中使用。
2.迭代型的生命周期
早期的互联网项目大都属于迭代型生命周期。它在项目过程中就会产生交付，我们可以在过程中获得反馈，然后收集这些反馈进行归纳、提炼，随后形成新的需求，再把这些需求放在下一个迭代版本中完成。这样我们就可以通过原型验证或概念验证的方式来帮助我们改进工作成果。这样做的好处是可以减少项目的不确定性。
迭代型的生命周期整个过程包括需求分析、分析设计、构建测试和价值交付，它的特点集中在中间的分析设计和构建测试的过程中，此时我们需要不断快速打磨以完善我们的产品。这样就能通过快速迭代来尽早修复问题，而且修复成本就会变得更小。
如果项目中需求频繁发生变化，或者我们认为客户的需求不是很确定时，就适合采用迭代型生命周期，因为迭代型生命周期更关注构建原型和优化改善，而不是为了提高交付速度。
3.增量型生命周期
接下来就是增量型生命周期，它可以向客户提供完成的交付成果，让客户能够立即使用。许多企业或客户更愿意团队在项目过程中交付，而不必等到所有需求全部完成。当我们交付一部分解决方案时，客户就已经能够使用了，我们把这种少量交付成果的生命周期称之为增量型生命周期。
项目团队在开始之前就会计划好每一次我们要交付的成果，在开始之后他们会尽快完成第一次交付任务，在实际的工作中，有可能第一次交付时间为一周，第二次交付时间为两周或三周不等。
随着项目的继续，团队可能会发现，最终交付的成果可能与刚开始计划的有较大偏差。但是团队不必在意这个结果，因为我们更重视更快交付价值来收集的用户反馈，相比如期完成计划内的需求，我们更看重客户对于交付成果的看法和交付价值。所以，只要结果是为客户创造了价值，我们就不必太在意最初计划的需求是否被全部完成。
4.敏捷型生命周期
最后我们来看敏捷型生命周期，它同时有着迭代和增量的属性，但是注入了敏捷的基因，所以是符合敏捷宣⾔的一种生命周期，它能够更好地应对更频繁的变更和交付项⽬价值。具体来说，它在迭代型的基础上增加了增量型对用户价值的分析，也就是说客户满意度将随着有价值产品的早期交付和持续交付不断提升。
所以在这种类型的生命周期中，我们会对产品进行增量交付，有节奏地迭代交付成果，这样客户能够在固定的周期看到我们的交付成果，并进行反馈，这会让我们团队对是否能满足客户所需变得更有信心，项目也能尽快得到回报。
5.生命周期特性对比
根据项目生命周期的类型，我们就可以来考量是否适合敏捷。我先来帮你区分开它们。在你开始一项项目的时候，我们首先要明确项目的需求、执行方式、交付方式和最终目标这些内容，如果需求非常的明确，也就是说客户的需求在项目之初已经确定，并且不会随着项目的进行而改变，那么此时我们就可以确定，项目采用预测型生命周期来推进。
但是如果我们的项目需求是动态的，而且这个需求比较复杂并且充满了不确定性，需要内部在不断完善中来达成最终的交付，那么此时我们就要选择迭代型生命周期。
如果我们的客户想要根据部分成果来调整最初的需求，也就是说在整个推进过程中要注重客户的反馈，那么此时我们就要选择增量型生命周期。
但在现实生活中，情况往往不是这么简单，我们可能需要在频繁迭代的时候，考虑到客户的反馈，那么此时我们就要选择敏捷型生命周期，这里请你注意，因为敏捷型生命周期注重频繁的交付，所以对团队的要求很高，但是如果遇到大型项目，这样就会很吃力而且不太实际，而增量型生命周期是在固定的周期完成部分交付，就会更加适合。
敏捷方法看重的就是交付成果，所以结合上述分析，我们可以知道，当你的工作场景是预测型和迭代型时，那么你完全没有必要采用敏捷方法；当你的工作场景是增量型和敏捷型时，你就可以部分或全部转型敏捷。这里部分和全部具体指什么呢，在下节课中我将为你讲解。
这里我为你列出了一张表格，从项目需求、执行方式、交付方式和最终目标这四个维度进行对比，而且我列出了应对场景作为参考。要注意的是，每个生命周期所对应的场景都是不同的，不要拿着锤子找钉子，敏捷不是解决一切问题的万金油，所有的情况存在即合理。我们要根据不同的团队、不同的场景，来选择合适的生命周期的方法。
二、如何让敏捷方法适合公司实情
1.敏捷实践方式：基于迭代和基于流程
两种敏捷实践方式：基于流程的敏捷和基于迭代的敏捷。
基于流程的敏捷实践
具体来说基于流程的敏捷，就是建立在流程基础上的敏捷实践，项目开始时，团队会以客户价值为优先级，从待办事项列表中提取优先级高的若干个功能开始开发。它最大的特点是：每次迭代必须要把所有的功能做完。在这种实践中，团队需要评估本次迭代的总工作量，因为每次选取的功能不尽相同，而总工作量也不同，那么每次的迭代时间也不同。如果这样的项目需要频繁交付的话，我们就只能在每次迭代前，尽可能地选择较少的功能进行开发。不仅如此，如果在迭代过程当中一旦出现变更，变更的工作量也会加到总工作量里，迭代的时间也会相应延长。所以团队要做出适当的进度计划，不能因加入功能过多而拉长了迭代的时间，让项目失去了灵活性。
基于迭代的敏捷实践
它的最大特点是：每次迭代的结束是严格被时间框死的，也就是说，针对团队的迭代，我们要根据团队的能力，给定一个固定的可用时间。敏捷中把这种严格的时间节点称之为时间盒。我们要在时间周期内交付完整的功能，这就要求我们把需求相对独立地分开，并且严格按照价值排序，因为这样我们便可以灵活应对变更，一旦变更发生并插入当前的排序中，我们就可以把优先级低的需求从迭代中剔除，以保证固定的迭代周期。这样做的好处是，无论何时，团队当前迭代做的一定是最有价值的功能。
总结：两种方式的区别
这两种方式最大的区别在于，基于迭代的敏捷就是我们平时所说的典型的敏捷开发，它规定了明确的交付时间，也就是交付时间是固定不变的。就像坐高铁一样，错过了时间就只能改签到下一列，这个发版日期交付不了就只能等到下一个发版日期。而基于流程的敏捷，它的范围是固定的，也就是说每次必须完成预定的功能才能交付。
比如腾讯的欢乐斗地主项目，前期研发时还没有正式发版面世，这时我们更注重功能的完成度，所以会采用基于流程的敏捷实践方式，当我们完成主要的玩法功能之后才会开始下一轮迭代。这样做的好处是，可以保证在每一次的迭代之后游戏的主要玩法都是比较完整的。当它上线以后我们要开始注重运营，所以此时我们采用了基于迭代的敏捷方法，因为这样可以定期让用户看到游戏的更新，和玩家建立起反馈的节奏，更加有利于我们产品的稳定。
而在实际开发中，并不是每个项目都很标准地适用我们前面讲过的某一类敏捷，这时就会涉及混合型的敏捷开发方式。
裁剪：混合敏捷实践
更多情况下我们需要结合之前所说的两种敏捷实践方式，组合出适合团队的方案，这种实践方式称为混合敏捷实践。我们要针对团队问题灵活运用敏捷方法，具体问题具体分析。如：
- Scrum为PO（Product Owner）、SM（Scrum Master）以及Team（跨职能团队）的使用提供指导，包括Sprint计划、每日晨会、Sprint Review和回顾会议。
- 看板帮助团队进步提升效率。是将流程可视化，使项目瓶颈更容易被察觉，以及通过调整WIP（在制品限制）来实现流程管理。
- 极限编程XP，运用编程实践如使用用户故事卡片、持续集成、重构、自动化测试和TDD（测试驱动开发），针对开发过程可以提高开发效率。
总之，与孤独地采用一种实践，用不同的实践来解决当前的问题会更有针对性，我们应该以问题为切入点，有针对性地逐步采用敏捷方法，而不是一开始就使用所有的敏捷方法，这样很容易陷入“形式化”，而且在实际推行过程中很容易反感。
针对适用场景裁剪
裁剪后的场景主要有：预测为主敏捷为辅和敏捷为主预测为辅。
首先看预测为主敏捷为辅的。比如京东拼购，和所有电商平台一样，它内部具有首页、分类页、详情页、下单页、支付页和结算页等标准页面，我们在做基础功能的时候就可以先把这些页面做出来，这部分页面已经很成熟了，不需要用户再去验证了，所以京东拼购只需要在它的特色功能“拼购”和“分享”上下功夫，用这些页面去试错就行了。这就是典型的预测为主敏捷为辅。
所以一个产品或项目，可以某一部分采用不同的敏捷开发模式。
再来看看敏捷为主预测为辅的案例，这种模型主要用在一些需要集成组件的工作环境中。比如腾讯广告的推荐算法，它是一套成熟的推荐体系，通常会嵌入到各种浏览器、新闻、小视频、游戏等平台中，对算法本身来说，它的功能需求和框架是可预测性的，但是集成之后，需要根据具体业务场景用敏捷的方式不断优化。
实战案例
如果你的团队是人数比较多的大型团队，那么我们需要把大团队拆分成小型团队，然后利用敏捷方法进行同步和协调，缩小团队的好处是降低沟通成本。腾讯就是通过组织拆分的方式，实现了大团队向小团队的裂解，这样有利于团队间采取“高内聚，低耦合”的工作方式，具体来说，高内聚就是小团队内部间通过频繁的沟通来达成共识，低耦合是指减少大团队间的沟通，这会降低沟通成本而提高沟通效率，腾讯正是这样来进行大型产品的快速研发。
如果你的团队分布在各地，那就可以借助即时通信工具、视频会议和看板来确保通信流畅。面对面交流时更容易建立信任感，提高沟通质量。所以我们应该尽早建立面对面会议让团队彼此熟悉，这样有助于提高后期远程会议的效率。在远程会议当中，因为缺乏面部表情和身体的语言交流，我们可以以点名的方式确定沟通信息是否被对方接收。如果团队有新成员加入，我们需要在会议开始之前，让新成员做自我介绍，增加团队对他的了解。此外，我们可以考虑使用基于迭代的敏捷实践，因为它有固定的迭代周期，所以可以帮助异地团队建立起共同的开发节奏。如果团队成员所在时区差别较大，我们可以取消每天固定时间的晨会，鼓励开展更多更频繁的小型专项会议，最好是时区差别不大的成员参加。
例如，微信支付这种需要国家金融权威机构监管的项目，在内部快速交付价值的同时还需要准备合规性审查文档，并记录项目关键信息以应对合规性审核。
如果你的团队是职能型组织内的职能孤岛项目，也就是说无法与其他部门进行有效沟通，这样就难以形成合力，此时我们应该打破职能孤岛，创建敏捷环境。比如腾讯游戏部门，基本打破了职能组织。游戏工作室制作人为游戏全权负责，组织运营、产品、研发团队共同为项目出力，个人绩效变成了奖金包体现在年终奖当中，而奖金的多少很大程度上取决于业务是否挣钱，这样大家才会形成合力，出色完成项目目标。
敏捷是一套自上而下的方法，落地时必须得到领导的支持，但有的领导可能只是简单地了解了敏捷的好处，没有接受专业的指导就让团队自己摸索并实施，反而会让大家感觉敏捷一些实践环节的增加（如每日晨会），成了团队多出来的负担，这时需要引入专业敏捷教练，帮助大家理解实施敏捷的真正目的。
三、如何拥有敏捷思维
1.敏捷思维的特点
- 快速，雷厉风行，只有跑
2.读入数据
代码如下（示例）：
总结
提示：这里对文章进行总结：
例如：以上就是今天要讲的内容，本文仅仅简单介绍了pandas的使用，而pandas提供了大量能使我们快速便捷地处理数据的函数和方法。