传统项目和敏捷项目的区别?项目管理有哪些痛点?

出于解决具有高变化率、不确定性和复杂性的项目相关问题的需要,敏捷方法应运而生。敏捷项目中经常遇到的痛点,是可以有效解决的。


序号

痛点

解决痛点的可能性

1

团队目标或任务不明确

敏捷章程中关于目标的部分:愿景、使命和使命测试

2

团队工作协议不明确

敏捷章程中关于一致性的部分:价值观、原则和工作协议

3

团队环境不明确

敏捷章程中关于环境的部分:边界、承诺资产和前瞻性分析

4

需求不明确

帮助发起人和相关方制定产品愿景。考虑使用实例化需求、用户故事地图和影响地图来构建产品路线图。让团队和产品负责人一起来明确需求的期望和价值。逐步将路线图分解为具有更少具体需求的待办事项列表。

5

用户体验不佳

开发团队的用户体验设计实践应在早期就让用户经常参与。

6

估算不准确

通过分解故事来让故事变小。让整个团队使用相对估算进行估算。考虑通过敏捷建模或刺探来理解故事。

7

工作分配或工作进展不明确

帮助团队认识到要自我管理工作。考虑用看板面板查看工作流程。考虑利用每日站会,根据看板查看工作进展。

8

团队面临障碍

仆人式领导能帮助消除这些障碍。如果团队不知道他们都有哪些可选方案,就要考虑聘请教练。有时,团队或仆人式领导无法消除障碍,团队就需要上报故事。

9

由于产品待办事项列表不够完善,导致工作廷误/超时

产品负责人和团队—起研讨故事。为故事创建—个准备就绪的定义。考虑分拆故事以使用更小的故事。

10

缺陷

考虑对特定环境有效的技术实践。它们可能是:结对工作、产品集体负责制、普适测试(测试驱动方法和自动化测试方法)以及稳健的完成的定义。

11

工作未完成

团队确定故事完成的定义,包括验收标准在内。另外,还要为项目补充发布标准。

12

技术债务(代码质量降级)

重构、敏捷建模,普适测试、自动化代码质量分析、完成的定义

13

产品复杂性过高

无论是软件项目还是非软件项目,都要常常鼓励团队思考:“最简单的有效方法是什么?”,开应用“简洁,即尽最大可能减少不必要的工作,这是一门艺术”的敏捷原则。这样做将有助于降低复杂性。

14

团队合作过程进展缓慢或没有改善

在每次回顾中,选择的改进项目不要超过三个。让仆人式领导帮助团队学习怎样整合这些待改进项。

15

前期工作过多导致返工

不要做过多的前期工作,而要考虑让团队通过刺探来学习。另外,在项目开始时衡量在制品(WIP),看看哪些部分团队并不需要设计,只需要交付价值。缩短迭代,并创建一个稳健的完成的定义。

16

错误的开始,前功尽弃

让产品负责人成为团队不可分割的一分子。

17

产品待办事项列表杂乱无序

按价值排序,并考虑延迟成本按持续时间(CD3)和其他价值模型划分。

18

仓促/等待,不均匀的工作流程

计划要对应团队的能力,而不是超出能力所及。要求人员停止多任务,为一个团队专注工作。请团队利用结对、群集或群体开发等方法,平衡整个团队的能力。

19

相关方要求无法满足

仆人式领导与这个相关方(可能是产品负责人)一起工作。

20

意想不到或不可预见的延误

让团队更频繁地检查,使用看板面板检查工作流和在制品限制,了解需求对团队或产品的影响。也可以在障碍板上跟踪障碍和障碍消除情况。

21

孤立的团队,而不是跨职能团队

让项目人员作为跨职能团队自我组织。使用仆人式领导技巧帮助管理人员理解为什么敏捷需要跨职能团队。

 

传统项目和敏捷项目的区别?项目管理有哪些痛点?



相关推荐