在启动 Scrum 项目之前,我们需要了解项目成功的几率,敏捷领域专家 Androw 和 Phuong 在“ Scrum in Action ”中从组织、基础设施、团队、技术、过程和业务六个方面提供了自我评估的标准,对于 Scrum 项目团队有很好的借鉴作用。
组织方面
主要评估不同部门和团队是否熟悉了 Scrum 的价值观和实践。组织内部对 Scrum 越熟悉,Scrum 过程越顺利。
- 不同的部门之前在 Scrum 项目曾经成功合作过吗?
- 公司内部是否存在强烈抵制 Scrum 的现象?
- 公司内的不同部门是否强烈支持 Scrum?
基础设施方面
主要是评估测试基础设施是否准备就绪,帮助你的团队执行所有需要的测试。
- 自动化是否准备就绪,并且已经成为共识?
- 持续集成测试是否准备就绪,并且成为共识?
- 每日构建环境是否准备就绪,并且成为共识?
团队方面
主要评估项目团队成员之间的关系水平,是良好合作的关键因素之一。
- 团队对 Scrum 完全是新手吗?
- 团队成员之前是否成功合作过吗?
- 团队成员彼此了解和欣赏吗吗?
技术方面
主要评估团队是否对所用的技术了解。虽然对 Scrum 项目本身不是个问题,但是这会有助于你了解团队的状态,从而用到评估当中。
- 开发团队是否对所用的编程语言非常熟悉吗?
- 开发团队成员对所用的技术非常精通吗?
- Scrum 生产环境已经就绪了吗?
过程方面
主要评估公司是都已经对 Scrum 具备了充分的了解和实践经验。
- Scrum 是公司已采用的过程框架吗?
- 公司内支持 Scrum 吗?
- 公司内部强烈反对 Scrum 吗?
业务方面
主要评估你的业务伙伴是否 非常熟悉 Scrum 需求和实践。你可以想到,他们越熟悉,你会受益越多。如果业务层对 Scrum 非常了解,那么对你的第一个好处是,你会得到一个非常权威的、全职的、知识丰富的产品负责人。
- 产品负责人已经做好准备了吗?
- 产品负责人熟悉 Scrum 但是没有实践经验吗?
- 产品负责人之前成功实施过 Scrum 吗?
关于产品负责人(Product Owner),Androw 和 Phuong 认为,敏捷项目需要每个人的努力,但是如果没有一名出色的产品负责人守卫产品愿景和目标,那么敏捷项目无法成功,因为敏捷或者 Scrum 项目的重点是交付业务结果和价值。他们特别强调了其需要具备的七个特质:
- 知道如何成功地管理利益相关者的期望和偶尔的优先级冲突。因为你没有足够的时间来与利益相关者周旋,所以我们建议你学会如何根据他们对项目成功的影响力来区别对待。
- 对产品有清晰的愿景和了解。如果产品负责人对产品具有清晰的愿景,会帮助她容易地设置目标和优先级,同时在团队尝试创建良好的发布和 Sprint 规划时受益良多。
- 知道如何收集需求把产品愿景转化为良好的产品 backlog。虽然具备产品愿景很重要,但是产品负责人为产品 backlog 准备好用户故事的能力可能更加重要。
- 全身心地投入到团队中,包括 Sprint 阶段和发布和 Spring 规划阶段。产品负责人应该和团队同在,每天与团队交流,出席每一个回顾会议。如果你发现自己的公司没有这样一个产品负责人,那么你应该积极地向管理层解释,团队需要一个兼顾业务能力和定期与团队交流并为业务作出决策的人。
- 出色的组织者,积极参加各种活动,同时具有前瞻性和保持沉着。除非你很幸运在一家小型公司工作,那么产品负责人拥有大量的时间,否则她会忙于处理各种优先级的事情,从与市场部门合作,到在自己部门处理业务问题。如果是这种情况,你应该讲究策略,积极提醒产品负责人,她的积极参与作为过程的一部分至关重要。
- 知道如何与团队和业务部门沟通产品愿景,确保在项目的周期中业务部门始终信任开发团队。需要积极地与管理层和用户合作,帮助他们理解团队的状态,这些与目标和业务价值相关。
- 出色的领导者,能够在团队需要时提供指导、训练和支持,同时确保业务部门从 IT 部门获取了他们所期望的价值。产品负责人应该知道如何做一名出色的服务型领导,可以指导、支持、训练团队逐步实现项目愿景和目标。
每一个问题都需要回答,根据问卷答案的好坏,得分范围在 0-2,当你把所有得分相加,会得到一个 0-36 之间的分数。如果你总分为 0,那么这意味着你的项目环境如此糟糕,在交付你的项目时会非常困难。如果总分为 36,那么这意味着你的项目成功几率最大。你的得分超过 18(平均值),那么你高于平均水平,Scrum 项目可能会非常成功,但是你需要处理一些问题来改进团队的交付能力。如果团队成员彼此陌生或者在之前项目里有过节,那么促使项目成员精诚合作。如果你的总分低于 18 分,这意味着成功几率小于 18。你仍然可能会成功,但是必须努力解决项目环境的一些问题,提高团队的交付能力。
Androw 和 Phuong 认为,自我评估背后的意义在于,一旦你知道自己的处境,那么可以努力改进弱势方面的分数,直到达到较高的分数,从而提高 Scrum 的胜算。你会更接近以下目标:
- 频繁的软件交付。
- 业务团队和软件团队之间的定期协作
- 固定时间的工作和会议,避免事情拖得太久。
- 频繁的检查和适应周期。
- 团队自我管理和授权。
- 一切都以持续的节奏来运转(团队不会被榨干)。
读者在评估 Scrum 项目准备程度时采用了哪些方法?Androw 和 Phuong 的问卷调查是否值得借鉴,你在自我评估时能够得到多少分?哪些方面需要进一步改进从而提高项目成功的几率?
评论