看板可以用于什么样的软件开发(项目),实现它的要求是什么?我读了很多关于看板的文章,以及它有多棒。但是现在我必须写一篇关于它的论文,重点关注看板的要求,特别是看板不适合什么样的项目。我还想不通。
5 回答
KarlM 给出了很好的概述。
我认为看板可以在任何项目中使用,因为它采用您现有的流程并将其可视化,引入 WIP(多任务)限制,并使用拉动来最大化流程并最小化交付周期。我的团队最近迁移到 Scrum,到目前为止过渡非常顺利。
看板特别适用于标准迭代没有意义的情况。
例如,您可能没有频繁发布。也许您想将您的一个或多个计划、演示、回顾或发布计划解耦。
很好的例子:
- 维修项目。即使您可能希望召开为期 2 周(或其他任何时间)的会议来讨论优先级、回顾等,但您可能不会每 2 周进行一次演示或发布,而且您也不太可能致力于无论如何,在接下来的 2 周内一切都会发生。像这样的情况是如此动态,以至于随着新的反馈来自客户,每天的优先事项都会发生变化。在这种情况下,Scrum 或其他迭代过程没有意义。
- 确实需要比您的迭代长度更长的故事。与 Scrum 一样,看板在小故事中蓬勃发展(更好的流程、松弛等),但与 Scrum 不同的是,它至少在确实需要时允许大故事。
- 发展速度极快。持续部署。迭代不再有意义,因为也许您正在快速响应更改照明,并且可能一天发布多次!
请参阅 code.flickr.com:
Flickr 上次部署是 4 小时前,包括 2 人进行的 8 次更改。上周有 19 人部署了 588 次更改的 85 次。
你认为 Flickr 是在进行 2 周的迭代,还是 1 天的迭代?我对此表示怀疑。看起来他们处于超高速动态流动模式……也许是看板,但绝对看起来他们在精益保护伞中。(看板属于精益思想的范畴,持续部署因 Eric Ries 去年的著作《精益创业》而流行起来。)
它可能不适合以下环境:
- 组织文化无法摆脱预先计划、过度工作/承诺、推动而不是拉动、固定所有时间表、范围和成本等。看板将开始激发组织的持续改进,许多人只是反对除了他们所知道和喜爱的传统的过度工程、过度文档化、孤立、非精益、非敏捷方法(即瀑布式)之外的任何东西。一些政府合同也可能属于这一类,尽管我相信至少国防部现在正试图在其项目中推进敏捷。但是有些公司,如果你告诉他们他们需要做 LESS(即,限制正在进行的工作、有更清晰的愿景、更快地完成更少的工作,但因此总体上完成的工作更多),就会心脏病发作。许多(大多数?)公司都沉迷于过度工作,并认为 SLACK(这是基本的精益原则)是一个 4 个字母的词。不幸的是,排队论和约束论很难被一些人理解。:) 所以看板可能不适合那些地方。;)
要求是,项目中的每个人都同意使用这些原则和实践:
Principles
1. Start with what you do now
2. Agree to pursue incremental, evolutionary change
3. Initially, respect current processes, roles, responsibilities and job titles
4. Encourage acts of leaderships at all levels
Practices
1. Visualise what you do / knowledge discovery
2. Limit work in progress
3. Measure and manage flow
4. Make policies explicit
5. Develop feedback mechanisms
6. Improve collaboratively using models and the scientific method
如果他们不同意这样做,他们就不能使用看板。很清楚。
看板是一种可视化和改进现有流程的工具。如果有一个场景不起作用,那么该场景可能具有两个属性中的一个或两个。
1) 没有现有的流程,或者现有的流程是如此灾难,以至于它根本无法工作和/或以混乱的方式不断变化。
2) 没有改善的意愿或机会。
缺少第二个并不是交易破坏者。看板仍然可以帮助进行沟通和协调,并且提高清晰度可能会导致提高改进或帮助建立授权改进实验所需的信任的愿望。这将是一个低成熟度看板实施的例子,它会导致更高水平的团队成熟度。
看板是一种简单的流程工具。应用得当,它适用于任何项目,而不仅仅是软件 - 任何项目。
在我看来,看板可以在任何类型的组织和任何行业中实施。
但...
- 团队必须为改变做好准备
- 变化必须具有进化特征
- 该组织必须专注于合作,而不是执行日常工作。