项目管理之敏捷方法--敏捷环境创建

敏捷环境创建

• 首先要做的是人的敏捷思维要建立。
    一个团队中不用角色对敏捷价值有要一个统一的认识。一个项目顺利推行敏捷方法，首先就是公司相关领导要有敏捷思维。在Agile Practice Guide书上叫仆人式领导，我更愿意叫服务型领导。

• 这位服务型领导在敏捷项目能贡献些什么呢？

  1. 让团队知道什么是敏捷，想办法传播敏捷思维
  2. 与团队建立项目目标，促进团队围绕项目目标进行合作互动。
  3. 鼓励团队创造一个人人能成功的环境。要求每个成员在项目中做出贡献。这里其实讲究的是团队的自我组织，自我驱动能力。
  4. 不要想着项目过程是否完全遵循敏捷方法。结果更重要，只要提供了有价值并客户满意的产品，并不断反思产品及开发过程。每个项目情况不同，对方法采取不同裁剪，所以不必拘束于是否100%对齐agile理论规则。

• 服务型领导应用的特征

  1. 提升自我意识
  2. 倾听来自团队的声音，以更好了解团队敏捷成熟度，并做出相应调整及训练
  3. 帮助他人成长
  4. 引导与控制
  5. 促进安全、尊重与信任。营造一个人人受尊重的环境，让团队成员感受到被信任，团队会有安全感。
  6. 促进他人能力得到提升

• 服务型领导职责

  • 组建跨职能团队是首要任务，怎样让团队成员尽可能100%投入当前项目，集中办公，确保有必要的技术能力去可持续交付有价什的产品给客户。这是正确敏捷的第一步
  • 服务型领导促进合作（组织与团队、跨职能团队，外部团队与团队内部之间的沟通与协作）
  • 牵线搭桥找到可以做决策的人和团队而不是代替他人做决策
  • 帮助agile 团队清除项目阻碍
  • 激励团队，帮助团队成员成长
  • 培养团队成一个自组织、自驱动的团队
  • 敏捷思维训练
  • 为他人贡献铺路，让团队尽其所能
  • 庆祝团队成功，是营造积极团队、相互欣赏、有合作意愿氛围的关键

• 项目经理在敏捷环境
    传统项目的项目经理通常是组织指派项目的负责人，具备绝对的项目管理控制权，项目的中心。而在敏捷团队中，大家的普遍意识是不需要项目经理，敏捷团队一起为项目负责，项目经理的工作被分散到各个成员头上了。项目团队是自组织的，自我驱动的，是积极主动的，进度是透明的，问题是公开的，业务人员或客户是可以直接与团队对接的。这时项目经理再插进敏捷团队就显的尴尬了。
    在我看来，这有点绝对。当然每个项目或组织情况不同，你的项目你觉的没必要有这么个人，可以不要。但有些项目，比如在一个大型传统企业中，正处于数字改革的浪潮中，项目通常是混合型生命周期，一个大项目分成很多个小项目，很多时候大项目与小项目，项目与项目之间沟通协作采用的是传统项目管理方法，进度或项目问题由项目经理定期汇报协调，尤其是在大型跨国企业，子项目成员分散在不同地方，没办法做到天每天协调的频率，项目经理担着更重的责任,他必须要非常确定的汇报进度,以免所依赖的项目无法按时开工（这就有点相反于敏捷项目的不确定性了）。当然当一个公司或企业完全过渡到敏捷方法后，项目经理可以过渡到服务型领导。把原项目经理的职责分配给那些完成任务所需知识的团队成员。这样也正好鼓励了团队成员积极超越原有的专业知识，学习新的东西，沟通管理，直面业务人员。此时的项目经理的价值更多的促进团队成员自我驱动起来，服务与帮助他们成长，提供解决问题的方向和桥梁。让整个项目团队变的更好。

• 敏捷团队建设

  • 基本属性

    • 敏捷宣言中的一条个人与交互胜过过程与工具,在这里足以说明敏捷项目里团队成员人的重要性。
    • 就强调了人的合作，一起快速完成优先级（最有价值的）最高的工作。
    • 根据实践证明，优化的敏捷团队通常由3~9个人组成。
    • 工作场地最好是集中在一个场所，便于面对面交谈。
    • 团队成员最好100%专注于当前项目工作。
    • 鼓励自我管理团队，每个团队成员都。
    • 每个Sprint范围有团队成员决定能做多多，能交付多少。
    • 服务型领导与团队成员一起成长，领导支持团队的工作方法。
    • 团队成员拥有完成项目工作所有必要的技能技术。相比I人才，更喜欢T型人才

  • 敏捷角色

    • 跨职能团队成员：
      包括开发人员，测试人员，业务分析师，架构师以及相关领域专业技术人员。完成高质量任务，快递交付工作的所需无外部依赖的所有人员。
    • 产品负责人：
      也可以业务代表，代表客户一方，对产品商业价值取向，产品开发方向非常熟悉的人员，对产品验收和产品范围界定，任务价值排序，提供产品反馈。
    • 团队促进者：也叫服务型领导。也可以称项目经理，Scrum Master, 团队教练。见[#服务型领导职责].

  • 通才型专家
      跨职能团队成员通常是可领域的技术专家，往往是I型人才（只对某一领域深耕），在敏捷中，我们鼓励I型人才往T型(对某一领域深耕的同时，同时还具备其它领域知识，如有培训新人，开发能具备测试能力，Scrum master不在时，临时兼职Scrum Master)人才成长。当团队中某一个领域人力资源不够时，部份成员能切换过去帮忙当在本领域工作还有缓冲的情况下。

  • 克服组织孤岛

    • 组织孤岛是指信息封闭的团队，或一部份团队成员,尤其是不同区或的成员，需要双线汇报，造成管理混乱。不能很好的发出自已的意见和拿到最新的反馈。这在我们平常项目很常见的问题。一个是团队领导没有很好的去宣杨敏捷交互透明公正精神，另一方面团队成员，过于关注自已的任务，不去积极沟通合作。对于双线管理，最好的办法就是团队领导要去协商达成一致，怎么赋权让成员专心于项目工作，而不是被不断工作汇报和不周的绩效考核困扰。这样会造成极大的风险，甚至交付失败。这和闭门造车类似。
    • 构建一个基本信任和安全的环境是组建团队的一个好的开始。确保所有团队成员有平等话语权。每个人的意见都听被听到，这就是为什么项目启动大会(Kickoff meeting)要求所有项目成员都参加，人人可以发声，才是一个平等公正的开始。任何问题或阻碍，只要开诚布公的去谈，相信相应的风险和挑战都会解决。

  • 敏捷工作场所
      敏捷提倡的是集中办公，独立安全的环境，方便面对面交谈，团队协调，开例会，看板任务状态更新，建立团队成员之间的信任，信息公开透明，加速交付进程。对于大型跨区域公司，无法避免成员分布在跨时区和地域办公，可以通过工具虚拟上的集中办公，如视频会议，网络看板共享屏幕，远程结对，如碰到时区差异，可以Follow The Sun,协商好工作交接点，通过邮件再加视频会工具交接,还有必须及时做好任务在项目工具中的更新

  • 专职团队成员
      理想情况下，鼓励敏捷团队成员专职于一个项目，这也符合敏捷精神高效可持续稳定的交付有价值的软件。但有时不会那么理想。往往组织决策者想要“人力成本下降，高效应用”，会把人员拖入几个项目，实际上这样多任务处理带来的问题是效率下降，会影响团队预测交付能力的一致性，交付周期考核不稳定。根据实践证明，工作效率的损失在20%-40%之间，随着任务数据的增加，损失会指数级增长。如果实在不可避免，团队在评估人员可用工作时间时，相应的减去损失部份时间。