敏捷中常见的陷阱
上一篇 /
下一篇 2014-10-16 14:47:12
/ 个人分类：敏捷
以下这些，往往是一个
敏捷团队会不知不觉中犯的错误，而不是一个非敏捷团队因为不懂而瞎做的。因为他们本质区别在于：一个是因为上一个成功的迭代没有涉及，从而忽略其中一些；一个是强行的去执行，以为自己就是敏捷。
Adding stories to a sprint in progress
往进行中的Sprint添加新的故事
敏捷的团队有时候因为需求更新或者细化后发现新的/隐藏的用户故事。这是因为在计划会议中大家忽略了。
非敏捷的团队习惯了在制定好计划后，觉得有些东西需要提高优先级，强行添加，从外部打断了敏捷过程。
Lack of sponsor support
缺少领导层的支持
敏捷的团队因为过于自组织，对于一些外部环境未必能够及时感知，比如和其它团队形成了竞争，浪费了资源。
非敏捷的团队认为自己能够管理自己，对领导成的风险控制反感，强行封闭自己，认为必须遵循不能干扰的原则。
Insufficient training
缺乏充足的培训
敏捷团队中有些成员能够完成一些任务，但是如果有更好的培训的话，能提高团队的生产率。
非敏捷团队往往就是随意根据需求抓人，连很多背景内容都没有讲解就强行开发。
Product Owner Role is not properly filled
Product Owner角色没有充分发挥自己的职责
敏捷团队中的PO因为信赖团队，降低了验收力度和沟通成本，从而带来风险。
非敏捷的团队的PO很多时候过多的干预了团队的既定任务和计划。
Teams not focused
团队缺乏统一的目标
敏捷的团队的统一目标很多时候因为减少了日例会的效率，从而出现信息不一致。
非敏捷的团队只有一个最终目标，没有个人目标和团队目标的契合过程。
Excessive Preparation/Planning
过多的准备和计划
敏捷的团队因为过于习惯了充分考虑一切，从而浪费了产品上线的最好时机。
非敏捷的团队因为没有良好的团队合作，从而在执行过程中不断的重新储备和修改计划
Problem-Solving in the Daily Scrum
在日例会中解决问题
敏捷的团队经常将几句话能说明的事情放到例会中讨论结束
非敏捷的团队直接将例会变成了讨论会。
Assigning Tasks
分配任务
敏捷的团队因为对某些人的信赖，不自觉的将一些任务推送给了特定人员
非敏捷的团队是直接分配任务给每个人
Scrum Master as a contributor
Scrum Master参与交付
敏捷团队的Scrum master有时候因为了解过多，不自觉的参与了交付过程中的某些任务。
非敏捷的团队习惯性的在团队中指定一个人作为Scrum Master
敏捷团队习惯性的认为保持了代码的稳定，通过结对编程增加了bug排除率，所以自动化规模较小。
非敏捷的团队只是对功能进行了自动化，甚至是GUI层面，缺乏深层次的自动化代码检查。
Allowing technical debt to buildup
允许技术型的债务积累
敏捷团队经常喜欢研究更新的的技术，越级更新，缺少了中间的稳定版本。
非敏捷团队很少去更新技术和框架。
Attempting to take on too much in a sprint
试图在一个sprint里交付很多
敏捷团队经常在成功的累积产生足够的信心，想增加一部分，或者偶尔加班。
非敏捷团队完全不知道优先级和产品战略，直接就拼命的堆功能。
Fixed time, resources, scope and quality
限定时间，限定资源，限定范围，限定质量要求
敏捷团队认为能够在四限下完成交付，缺少风险管理和应对手段。
非敏捷团队往往目标是四限，最后只是去cover限定时间。
收藏
举报
TAG:
