敏捷的十二大原则
我们最重要的目标，是通过持续不断地及早交付有价值的软件使客户满意。
欣然面对需求变化，即使在开发后期也一样。为了客户的竞争优势，敏捷过程掌控变化。
经常地交付可工作的软件，相隔几星期或一两个月，倾向于采取较短的周期。
业务人员和开发人员必须互相合作，项目中的每一天都不例外。
激发个体的斗志，以他们为核心搭建项目。提供所需的环境和支援，辅以信任，从而达成目标。
不论团队内外，传递信息效果最好效率也最高的方式是面对面的交谈。
可工作的软件是进度的首要度量标准。
敏捷过程倡导可持续开发。责任人、开发人员和用户要能够共同维持其步调稳定延续。
坚持不懈地追求技术卓越和良好设计，敏捷能力由此增强。
以简洁为本，它是极力减少不必要工作量的艺术。
最好的架构、需求和设计出自自组织团队。
团队定期地反思如何提高成效，并依此调整自身的举止表现。
敏捷的最佳实践
我们是通过这些具体的内容来评判是否是最佳实践的：
稳定的团队：我们需要稳定、有默契的团队，即在很长一段时间内团队成员是固定不变的。
可预见的速率：我们需要在一个迭代当中形成团队的速率，方便知道下一个迭代我们可以做完哪些工作。
单件流：我们需要集中精力一次做好一件事情，所以不欢迎并行任务。
质量内建：我们需要在每一个环节保证好自己的质量，不让质量问题留到下游。
日事日毕：我们需要把任务粒度拆分成至多1天，以方便每天知道我们的工作进展。
设有紧急停车带：我们需要给紧急任务加上紧急停车带，以便分析紧急任务的插入情况。
滚动迭代：我们需要通过迭代交付来完善我们的产品。
持续改进：我们需要通过回顾和总结，不断强化我们的团队能力。
尽早交付：我们希望尽早交付版本，更快得到用户反馈，以便于更快满足用户所需。
敏捷实践方式：基于迭代
每次迭代的结束是严格被时间框死的，也就是说，针对团队的迭代，我们要根据团队的能力，给定一个固定的可用时间。
敏捷实践方式：基于流程
每次迭代必须要把所有的功能做完。如果在迭代过程当中一旦出现变更，变更的工作量也会加到总工作量里，迭代的时间也会相应延长。
混合敏捷实践
Scrum 为 PO（Product Owner）、SM（Scrum Master）以及 Team（跨职能团队）的使⽤提供指导，包括 Sprint 计划、每⽇晨会、Sprint Review 和回顾会议。
看板帮助团队进⼀步提⾼效率，⽅法是将⼯作流可视化，使项目瓶颈更容易被察觉，以及通过调整 WIP（在制品限制）来实现流程管理。
极限编程 XP，运用⼯程实践如使⽤用户故事卡片、持续集成、重构、⾃动化测试和 TDD（测试驱动开发），针对开发过程可以提高开发效率。
让敏捷思维在实践中成长
- 建立干净透明的环境
- 负责人发挥灯塔作用
- 从快速交付中尽早获得反馈
- 整个团队根据所有的任务建立产品待办事项列表（Product Backlog）；
- 产品经理从产品待办事项列表中选取价值高的需求列入迭代待办事项（Sprint Backlog）；
- 研发人员用 1—2 周的时间快速迭代；
- 测试完成后发布；
- 产品经理收集用户反馈后整理成需求，并重复第 1 步。
清晰团队及团队外成员的职责
每日站会
团队人数不超过 10 名。因为沟通的路径是 N*(N-1)/2，这就意味着人数越多，沟通效率越低，所以我们应当尽量保持 10 人以内的小团队。
需每天进行。敏捷的核心是小步快跑，因此我们把任务粒度拆分到1天内，每个人每天至少可以完成1个任务，这样团队每天都有新的进展，但是也会遇到新的问题，所以需要每日开展站会同步信息。
固定的时间且每次不超过15分钟。我建议在每天上午上班15分钟后开始，团队成员可以用 15 分钟梳理昨天完成的工作。Scrum Master 要控制会议时间以保证效率。
固定的地点。团队在固定的时间就可以到指定地点集合，更加快速、直接。
需站立，这样容易集中注意力，大家在潜意识里容易想赶紧结束会议，所以就会提高效率。
不解决问题。如果站会过程中解决问题，会让这个会议主题发散，我们把问题抛出来，在站会之后 Scrum Master 可以安排专项会议解决问题。
相关人员都需出席，所有与项目相关的人员都需要出席会议。
团队以外的人不能发言，以免不熟悉团队的外人干扰团队正常工作流程。
可以使用“发言令牌”，如网球，毛绒玩具等，随机抛向团队成员，拿到“发言令牌”的成员才可发言。这样使得团队成员要随时准备下一个发言，大家会更专注。
擅用信息同步工具
白板
议题的清晰度与会议的连贯性是视频会议成功的关键，我们需要事先协定好会议规程以避免混乱。规程包括发言的时间、用哪个统一的通讯平台。
规定写得越清楚越好， 除非团队事先就已经定义好，否则少用一些英文缩写或专有名词。
不要给团队发过多的信息，在发送之前，自己要仔细斟酌要表达的内容，避免产生歧义。
注意团队中性格内向的人，这些人比较擅长书面沟通，远程沟通实际上是为那些不喜欢在集体中发言的人提供更公平的竞争环境
最后，找一些远程庆祝和社交的方法，比如发微信红包、举办远程生日会等，增强团队的凝聚力和合作能力。
0-1导入敏捷
第一种是 与加速交付相关 的转型。企业往往都是从百人以下的小团队开始发展，随着成长人数会越来越多，曾经的工作方式愈发不合适，组织效率就会越来越低，尤其是人数过千以后，管理者意识到要提高交付效率，加速交付过程，而敏捷可以帮助企业达成此目标，所以他们就想导入敏捷。这种状况多发生在互联网行业或传统软件行业，他们一般会以业绩成果来度量敏捷导入的产出。
第二种是 与敏捷方法相关 的转型。敏捷在中国已经推广了十几年，已经有很多公司导入了敏捷并取得不错的效果，比如腾讯公司。这就引起了其他大型企业的关注，如果敏捷能够使公司发展得更好，那为什么我不试试呢？所以他们也想导入敏捷，而且通常以改变协作方式为切入口，因为他们希望敏捷能帮助自己的团队与其他部门、供应商之间更频繁地交流与协作。他们比较重视敏捷过程的度量，比如某些环节的效率是否提升，跟同行业佼佼者比较还有多大差距。这种状况多见于银行业中。
消极因素
工作被分解为部门孤岛，从⽽创造出阻碍加速交付的依赖关系，而不是构建在能⼒中⼼指导下的跨职能团队，也就是说，部门墙越厚就越不利于敏捷转型；
短期交付型的项目不适合用敏捷。比如我们承接甲方的需求开发，甲方要求交付的产品特别明确，其间产生变更也会以补充合同进行说明，交付时间也会清楚地写进合同中， 因为这个项目不存在频繁的变化，所以并不需要敏捷；
团队优化的依据是部分效率而不是端到端的项目交付流或整体优化情况， 因为如果只想着提升研发效率，那么敏捷转型带来的效果是有限的，而敏捷可以带来的是全方位的优化，所以在导入的过程中，我们要着眼于全局；
员工属于特定领域人才，实现技能多元化的工具或激励有限，不重视培养T型专家⼈才。因为敏捷是跨职能团队，每个人除了自己的领域之外，最好还有其他领域的专业知识，比如开发工程师具备产品思维。 敏捷鼓励 T 型专家人才，即 在某一领域具有专长，同时又能在其他多个领域有一定的经验和见解的人 。 如果团队只是强调培养特定领域人才，这就只是在培养螺丝钉， 并不能为跨职能团队带来很多收益；
分散化项目组合即使员工同时分配到过多的项目，而无法专注于单个项目。敏捷宣言提到“可工作的软件胜于面面俱到的文档”，说明敏捷团队提倡简化文档。正是因为这点，所以我们要使团队保持稳定，主要就是团队成员相对固定，如果员工分配到过多的项目，就会打破这种稳定的团队结构，敏捷转型也就很难获得成功。
积极因素
管理层具有强烈的转型意愿。任何转型都是自上而下的，敏捷转型也不例外，管理层的转型意愿越强，企业的敏捷转型也越容易获得成功；
员工的认知和改变意愿。如果员工在认知上认可敏捷，认为 敏捷转型能解决自己目前的问题，且愿意在工作方式上作出改变。比如开始组建跨职能团队、开展晨会和回顾会，认知和改变的意愿越强，也就越容易获得成功；
组建跨职能团队。如果领导愿意把原来的组织结构调整为跨职能团队，为敏捷提供天然的适合生长的土壤，那么团队更容易转型成功。比如腾讯，就是按照跨职能组织的典型，产品、开发、测试和运营以项目为单位组织，大家共同背负业绩 KPI，树立共同的目标。除此之外，员工的涨薪并不直接由自己的职能领导给出评价，而是由通道委员会决定员工的职级 ，HR 再根据职级进行调薪。这样的团队只为达成产品目标服务，非常敏捷；
专注于短期目标而不是⻓期目标。敏捷团队需要不断试错以获得短期利益，所以敏捷团队更关注短期目标的达成，如果团队属于这种特性，那么更适合敏捷转型；
⼈才管理成熟度和能力。敏捷对于团队的要求是比较高的，一是由于敏捷鼓励自组织型团队，所以团队得有自我管理的能力，这就对团队成员要求较高；二是敏捷需要团队有很强的自动化能力，例如自动化测试、自动化构建和自动化部署。团队自我管理能力越强，团队的自动化能力越强，敏捷转型也越容易获得成功。