敏捷实践之团队
敏捷实践之团队
黄隽 Charlie
2019年01月
序 言
随着近些年敏捷在行业及企业的推广，越来越多的企业意识到了敏捷所带来的好处，并愿意在敏捷上有所投入，从而越来越多的朋友加入了敏捷从业者行列，愿意学习敏捷知识。多年热衷于敏捷的我，参与或主导大大小小敏捷转型项目实战和敏捷圈线上、线下活动，阅读大量书箱文献，活跃于敏捷大咖们的议题讨论事件，以及从事多年专职顾问的经验，有些小热情总结一系列文字内容帮来分享给那些已经或者正准备踏上敏捷之路的朋友们用于个人学习、研究和欣赏，以及非商业或盈利性用途，为在敏捷之路的个人和群体贡献一份力量。
系列文字主要内容来自于个人敏捷转型实践、书箱文献和日常系列活动心得等的提炼总结和创作。此系列文字内容推荐有基本敏捷常识及有一定Scrum理论基础的朋友们阅读，并按实际场景进行参考。
如以上内容涉及版权或原创作者有不同见解之处，敬请及时告知，乐于接受并给予修正。
目 录
1 定义和特性说明
1.1 定义
敏捷开发方式有很多种，这里我们选择Scrum。Scrum给出了一个具体的工作框架，并且是应用最为广泛、成熟的一种敏捷开发方式，业界已经积累了大量的实践经验。结合Scrum框架和具体实施项目特点，打造适合的敏捷Scrum团队尤为重要。
Scrum团队是一个完整的团队。Scrum团队是基于功能开发而组成的跨职能、自我管理团队，在组织方式、管理模式和开发过程等方面与传统的开发团队有着重大改革。Scrum团队与传统团队的简单对比如图1-1。
图1-1 Scrum团队与传统团队对比图
Scrum团队中没有传统意义上的项目经理、产品经理、开发经理，而是引入了产品负责人（Product Owner）、Scrum Master和开发团队（The Team）,开发团队中包含了多个职责的成员，例如需求设计人员、开发人员、测试人员等。
传统开发团队通常由项目经理做任务分析（WBS）并下达和分配工作内容，而Scrum团队提倡自我管理、自组织，按兴趣和能力挑选自己喜欢的任务。
传统开发团队通常是接到任务后独立完成，个人英雄主义突出，而Scrum团队需要在工作中相互配合，协作完成任务。
传统开发过程中，通常是经历一个非常大时间段的开发过程才能完成一次产品的发布，中间过程客户不能试用产品成果，不能快速反馈，而Scrum开发过程中，产品是迭代增量发布的，通常是在每个冲刺（Sprint）结束时交付可发布的软件，客户可以试用每个冲刺产品成果和快速反馈。
1.2 特性说明
开发团队的大部分时间都花在冲刺执行上。在冲刺执行期间，开发团队完成设计、构建、测试PBI(Product Backlog Item),生成潜在可发布的产品增量。开发团队的冲刺执行活动包括：每日检视和调整（站例会）、梳理产品列表（PBI）、冲刺规划（迭代计划会）、检视和调整产品与过程。下面一起总结团队都有哪些特性。
1.2.1 由5至9人组成
如果开发团队需要一个大型的Scrum团队，比如如果有43个人，不大可能会组成一个43个人的Scrum团队，而是分成5个或5个以上的Scrum团队，每个团队建议不超过9个人，常用的方法为scrum of scrums。
1.2.2 一个整体，跨职能
开发团队必须具备所需的全部技能以构建高质量、可工作的产品增量。技能单一的专职团队最多只能完成工作的一部分。所以一个专职团队做完自己的工作后，工作产品就被移交给其它团队。例如，开发团队把代码移交给测试团队。移交代表着极有可能产生误解和高成本的错误。拥有跨职能的团队可以减少移交次数，节约成本。开发团队由搭配合理的资深员工和资历浅的员工来实现团队多样化。
1.2.3 开发团队是自组织的
没有人告诉开发团队如何把产品代办事项列表变成潜在可发布的产品增量。开发团队自己确认采用哪种最佳的方式来实现产品负责人设定的目标。自组织是系统自下而上、自发的属性，没有传统的自上而下、命令与控制的管理方式,即便是Scrum Master也不应该冒昧干预。这样的自组织拥有非凡的稳定性和产生惊人的新颖性。
1.2.4 由T型技能的员工组成
T型技能的意思是即要有深度又要有广度。团队成员拥有适合的技能，覆盖各个专业领域，并且总体上技能有一些重叠，团队有额外的灵活性。有深度的专家型的员工，可以分配到数量合理的产品团队中，但不能让他们成为瓶颈（接力棒掉地）。然而，一开始就能找到想要的团队技能组合，是不太可能的，理想的技能组合需要在开发过程中日益成熟。
1.2.5 具备“人人为我，我为人人。”的态度
在开发团队中不会有人说：“我那部分做完了。你那部分没有做完。因此我们失败了。”开发团队的成员必须充分意识到他们必须合作才能冲刺目标承诺，失败是团队中每个人的问题。
1.2.6 广泛沟通
开发团队成员相互之间以及他们和Scrum Master、产品负责人之间需要进行广泛的沟通，快速、高效交换有价值的信息。广泛的沟通提高了信息分享的频率和质量。信息的经济价值是有时效性的，所以加快信息分享的速度可以快速进行检视和调整，做出更好的决定，同时可以快速识别浪费，避免开发团队在错误的方向上花更多的资源。Scrum团队广泛的沟通，就是用最小的成本快速有效地沟通。
1.2.7 沟通透明。
沟通透明使开发团队成员都清楚目标状态，不会意外，另外还可以帮助建立互信。简而言之，开发团队成员需要坦诚、靠谱，才有利于自组织和达到冲刺目标。
1.2.8 目标专注
开发团队成员需要对团队目标保持专注、有责任感。大量数据表示一个普遍的共识：做多个项目或者跨多个团队会降低生产力。建议团队成员尽可能专注于一两个产品，当然专注于一个产品开发工作时，更容易做到专注、有责任感。
1.2.9 持续的工作节奏
开发团队必须以可持续的节奏工作，不在进行死亡行军，这样做可以维持一个健康、有趣的环境。采用顺序开发时，我们把像测试这样的重要活动放到了最后，此时临近项目交付，通常有大量的问题需要快速解决。结果，在开发后期，工作强度陡然上升，高工作强度会把团队成员压垮。作为组织，我们要问：“为什么必须在晚上和周末工作，哪些地方可以改进？”采用Scrum，每个冲刺我们一直在开发、测试和集成可交付的特性，为了确保团队可以频繁、定期交付价值特性，不至于忙到吐血，每个开发团队成员都应该使用良好的技术实践，比如持续集成和自动化测试等。
1.2.10 人员稳定
开发团队需要人员稳定。开发团队成员的稳定更有利于提高生产力、效率与质量。团队是组织的资产，团队才是敏捷的“价值源泉”。这里并不是说相当长时间内始终应该保持团队稳定。例如，如果有一个团队不像我们想象的那样有凝聚力，或者团队出现功能失调，那么解散团队危害更小而且经济上更合理。再例如，为了在组织内进一步推广Scrum，可以有意识的打散一个高效率Scrum团队，把优秀的团队成员作为“种子”策略的一部分。新的Scrum团队都有一个Scrum经验丰富的种子比保留原来的团队更有价值。
2 案例说明
2.1 常见问题
1) 敏捷开发提倡先做市场收益率最高（最高价值）的工作，它容易导致敏捷开发团队过于看重眼前的短期利益，而忽视了产品发展的长远目标；
2) 敏捷项目管理中，对敏捷开发团队成员的素质要求非常高，要求每位团队成员都非常专业并且拥有积极主动的自我管理。而现实中，团队成员的现况往往是水平参差不齐，积极主动的态度因人而异，往往达不到敏捷开发团队成员要求的标准。
2.2 解决方法
1) 敏捷团队需要放眼中、远期目标，不能仅仅局限于关注眼前收益率大的目标；
2) 敏捷的价值观提倡谦逊和勇气，团队成员之间互信互助，而不是互相指责批评和推卸。团队成员能够认识到自己的不足，并且主动改进，遇到困难的时候主动寻求团队帮助。团队成员努力做到自我管理和自我驱动，承担多项职能的工作。
2.3 主要收益
1) 团队成员的自我管理能力、责任感和主观能动性增强；
2) 团队成员不再各自为战，工作透明，协作和联系更加紧密；
3) 团队成员满意度提高，工作氛围更加和谐；
4) 每个Sprint都将成果（潜在可交付产品增量）与客户做确认，避免了后期较严重的需求变更风险；
5) 团队成员不断地自我反醒、自我激励、能力提升。
- 点赞
- 收藏
- 关注作者
评论（0）