【敏捷1.4】敏捷开发环境：领导与团队
敏捷开发环境：领导与团队
敏捷中，最重要的是什么呢？基本上所有的教材都会说，敏捷是以人为本的，以团队为核心的。第一，敏捷不提倡加班，第二，敏捷让团队自管理，第三，敏捷中的领导都是服务员而不是命令者。是不是看着很激动呀，敏捷对员工这么友好吗？没错，相比传统的项目来说，在敏捷中做项目是快乐开心的。那么，要实现敏捷，我们的团队需要怎样的领导与团队环境呢？
要敏捷，更得要支持
首先，公司上层的支持是非常重要的一环。没有上层领导的支持，一切敏捷都无从谈起。为什么这么说呢？因为敏捷真的和传统的项目开发非常不同，甚至很多东西都是让人感觉不可思议的。即使是现在的我看来，结对编程这种敏捷方法依然还是无法进入主流。毕竟让两个人去盯着一个电脑屏幕，编辑同一段代码这种美好的事情在国内的互联网公司中还是很难实现的。有这两个人力当然还是需要在996的基础上让他们完成4个人的工作，这样才能更符合老板的利益嘛。
所以说，如果你在这样的一个狼性的公司工作，很多敏捷中的美好实践肯定是无法实现了。但是，它们又很善于利用敏捷中的其它概念，比如迭代周期完了就得发布，你完不成就得加班，事后的迭代回顾又变成了批斗大会。类似的情况简直数不胜数。
说实话，真正的幸福的敏捷公司、敏捷团队，恐怕真的只能是听说、传说了。
当然，梦想总是要有的，万一实现了呢？作为项目经理的我们，在学习到了后续的敏捷实践之后，还是要尽可能的说服老板在公司中多多尝试，多多实践。这也非常考验我们管理干系人的水平和我们的软实力。争取领导团队和老板的支持，是在任何公司中要推行任何制度方法的必经之路。这一点，无法逾越，也是我们要面临的最大的考验。
敏捷需要什么样的领导
虽说项目经理带着经理两个字，但在敏捷中，项目经理还真不如不加这两个字。其实，在 Scurm 中，就正式放弃了项目经理这个称谓，取而代之的是 Scrum Master ，也就是 敏捷教练 。由此也可以看出，在敏捷中，管项目的不一定是个经理，如果不是经理，那么也就避免了一些问题，特别是传统项目管理中的集权命令式项目经理的问题。
在传统的项目管理中，项目经理除了要做规划，要整合各方干系人和资源外，还对项目团队有着一定的权利，甚至一个项目经理可以左右项目的生死。不过，在 PMP 中，项目经理定义的也是以服务团队为主，需要善于运用职位权利、个人魅力、专家权威等各方面因素让团队成员团结在你的领导下。
在敏捷中，完全提倡的是一种服务型的领导风格，就像敏捷教练这个称谓一样，只是教练，给你提供方法而已，除此之外，没有别的了。
敏捷领导力
在敏捷中，我们需要的是一种敏捷的领导力，比如说，我们更加关注的是人，而不是这个人的绩效，对于绩效来说，我们更加关注的是效果。而在控制过程中，我们的领导力体现的是授权，这个授权可能是对整个团队的授权，我们相信的是团队整体的力量。
在整个项目的开发过程中，始终以一种指导的形态出现。不说出答案，只点出问题和提示。发现团队成员做事的原因和动机，理解他们的需求。通过项目目标和任务对整体进行调整以项目要求。
另外，管理和领导是两个概念，管理更偏重于对人和事的束缚，而领导更偏重于对人和事的期待。管理更多的是指挥、命令和控制，而领导 是让人们去做他们想做的事情。这是相辅相成的，在敏捷中，我们不排斥管理，甚至在很多情况下管理是有其重要作用的。但是，我们更看重的是领导力。没有什么比让员工自发自愿的来完成工作更棒了。所以，做为敏捷的项目管理来说，激发团队，创建更多的环境来满足员工对于工作的欲望，是一个好的项目管理者所应该具备的能力。
服务型领导
服务型领导是怎样的一个概念呢？这个还真是敏捷提出的一种领导类型的概念。就像上述的敏捷领导力中所说，敏捷更看重管理者的领导力，而这个领导力中最重要的就是为团队成员创造条件以激发他们的战力。因此，管理者，或者说团队的领导，就要服务于这个团队，也就顺理成章的成为了这个团队的“仆人”。也即一个服务型的领导，具体来说，服务型的领导要做到：
保证团队不受干扰
移除工作中的障碍
沟通项目愿景
为团队带来食物和水（后勤保障）
团队
不管做什么项目，不管采用什么类型的项目管理方式，团队都是一个项目开发过程的重中之重。毕竟没有团队，没有人，这个项目从何做起呢。
在传统的项目管理中，有职能型组织、项目型组织和矩阵型组织三种。一般的项目团队可能会包括在这三种类型的组织中。在敏捷中，其实我们更偏项目型的组织，但它又并不排斥别的组织形式，职能型的项目团队成员也是可以加入的。甚至一些测试工程师也是多个敏捷团队所共用的，这一点在敏捷来说，并没有什么问题。
而在敏捷中，更关注的是团队的组成以及工作的方式。就像下面我们将要讨论的问题。
自组织团队
何为自组织团队呢？
其实这和管理学大师德鲁克还有点关系，因为他提到过：“知识工作者必须要自我管理。他们必须要有自主权。”
对于敏捷来说，它诞生于软件开发行业。众所周知，软件行业本身就是典型的知识工作者聚集的地方，很多业界大佬都是码农出身，试想，如果他们当时在开发的过程中，没有自主的管理和决策能力的话，能成就当前的事业吗？所以说，其实敏捷的基因早就已经出现在了各家公司中，只是被少数的人把握住了，而被另一批人发现了形成了一套理论而已。
自组织的团队，其实就是能够自我抉择如何更好地完成工作，说穿了，要给自组织的团队足够的授权。管理者和敏捷教练都不一定能够有完备的领域知识，团队中的某个人也不一定有，但组成的这个项目团队，应该是要具备这个知识能力的。所以，放手让团队来获得一些权利，让他们能做一些决定，也不失为一种很好的激励手段。这也和前面讲过的 服务型领导 的概念一致。
成员能力
要想达到自组织的境界，对成员的能力其实也是一个不小的挑战。敏捷中最期望得到的是 “T” 型人才。也就说，这个团队成员要对某一个领域有深入的理解，也要对所有的方面都有粗浅的认识。比如说，一个测试人员，在产品人员出现问题的时候，也能够帮忙编写维护一些产品文档。或者说一个开发人员，也可以去做一些测试工作。
不过，这里并不是说每个人都要成为 “全栈” 。很多 “全栈” 工程师，其实往往更多的情况下是什么都懂但什么都不精。这样的人才不是敏捷团队所欢迎的，记住，“T” 中的那一个竖，也就是精通的那个领域也很重要！
至于说在公司组织中，如果找不到这样的人才呢？那就要考验项目经理或者敏捷教练的能力了。要自组织，要这种 “T” 型人才的根本目的，其实是为了实现小团队、实现用户故事的评估、实现迭代规划、实现内部的高效交流沟通的目的。如果实在找不到这样的人才，那么普通的人员只要能够达到真正意义上有意义的沟通，其实也是没有问题的，这些也可以通过各种敏捷工具来实现，大家也不必拘泥于此。
团队结构
团队的具体结构当然是有能够为项目提供助力的人员组成，比如在软件开发中，软件工程师是必不可少的，测试人员也是不能没有的，而在 Scrum 中，也有专门的 Product Owner ，也就是产品负责人。此外，其他的人员就视项目情况而定。
在敏捷团队中，我们推荐的是小而轻的团队，所以团队人数不宜过多。如果是非常大型的项目，也可以拆分成多个小的敏捷团队。这个我们在后面会讲到，每日站会的时候，最好不要超过 10 个人。如果有多个团队，那么就是在每个团队中选择一个人（多为教练或产品负责人）进行多团队间的每日站会，同样，也不要超过 10 个人 。
同时，我们还要区分哪些人和哪些团队对项目有着至关重要的影响。在敏捷的各类书籍中，都流传着这样一个故事。猪和鸡要开一个餐馆，鸡出的主意说我们就卖火腿和鸡蛋，猪想了想觉得不对劲呀，对鸡说：“我付出了全部，而你只是贡献鸡蛋，这不对呀”。以故事的形式来说明一个问题，这在 XP 中就称为 “隐喻” 。这个隐喻说明的是什么呢？其实就是说，项目中的团队成员都是“猪”，是全身心投入的，而一些其他干系人，只要不是在项目团队中的，其实都是鸡，他们只是偶尔参与。我们需要倾听他们的意见，甚至将他们的意见当做是重要的参考资料，但是，别忘了，我们是“自组织”的“全身心付出”的敏捷团队。
总结
今天的内容其实是针对想要实现敏捷的组织或者个人来说，首先需要考虑的一些问题。比如上级领导的支持、敏捷应该如何管理以及敏捷团队是个什么样的。在后面的文章中，我们还会详细的学习这些内容。先有个底子，将来才好更加深入的理解嘛。下一章将会是大家非常感兴趣的内容，也就是几种敏捷框架的介绍，其中会重点介绍 Scrum ，千万千万不要错过哦！
参考文档：
《某培训机构教材》
《用户故事与敏捷方法》
《高效通过PMI-ACP考试（第2版）》
《敏捷项目管理与PMI-ACP应试指南》
PMI-ACP