《Scrum是一种糟糕的项目管理方法运用需谨慎.docx》由会员分享，可在线阅读，更多相关《Scrum是一种糟糕的项目管理方法运用需谨慎.docx（11页珍藏版）》请在金锄头文库上搜索。
1、Scrum是一种糟糕的项目管理方法，运用需谨慎全文共3777字，预计学习时长11分钟图源：Unsplash团队近况不太理想，我们心情非常沉重。距离我们最新支付产品的推出已有一月，但这一切似乎看起来是一场灾难。这款支付产品非常不稳定，用户体验极差。其实这也是我们预料之中的事。但更糟糕的是：我们服务面向全球。即使是在夜间发生的事故，也需要迅速解决。 这样缺乏睡眠和身负巨大压力的工作方式是无法持续的。至少在一次例会中卡尔大吼道：“我们不能再以这样的方式工作下去了！我们究竟在欺骗谁？”图源：Unsplash决定卡尔是正确的。我们需要做出改变，所以我们决定停止使用Scrum这一项目管理方法。这个决定让我
2、们整个团队焕然一新，我建议读者也做出同样的改变。Scrum通常会给人希望，比如说，“事半功倍”（由Scrum的创建者之一杰夫萨瑟兰 (Jeff Sutherland) 提出）。但是使用Scrum却让工作停滞不前，是时候取消Scrum项目管理方法了！在继续阅读本文前的一个提醒：悦纳自己，即使现实真的很残酷。迭代计划先从迭代计划谈起，以我们项目中的第8个迭代计划为例。其实也可以选取项目中任一阶段的迭代发展阶段，因为这些计划本质都是一样的。项目组的Scrum大师展示了为项目成员安排的工作，而这些工作直接从项目经理创建的甘特图复制而来。显然，在几个月前，我们在项目初期就提出了完成该项目所需的所有工作。
3、接着很快发现，在做计划时，我们对工作的复杂性一无所知。这比预期的要困难得多。因此，在第8次迭代中，进度远远落后于预期，不得不努力“争分夺秒”。最重要的是，我们现在会觉得当时对必做工作的初步评估是过时的。随着时间的推移，我们根据销售情况来了解用户的其他需求。但是这些必须等到项目的第二阶段才能实行。如果未顺利过渡到第二阶段，仍然停留在第一阶段，就意味着可能无法实现预期价值，这是多么令人沮丧。但我们并不能为此做什么。我们已经制定了一项计划，而且必须遵循它。改变计划很难，所以指导委员会不可能同意更改计划。老实说：我们很幸运，因为我们只有一个项目。报告团队必须同时处理四个项目。优先级由（项目）经理的级别
4、和影响力决定。这种情况也可能发生在迭代 (Sprint) 中期，那这个团队真的很倒霉。计划会议的好处是耗时短，谁知道需要多久才能收到未来两周的计划通知呢？图源：UnsplashStand-up（站立会议）这是最短的会议，但也是最耗力的会议。即使只有5分钟，编码例程却被迫中止，我们不得不交代前一天做了什么，以及当天的规划。接着，我们必须提出所遇到的困难，好似它们能够马上被解决掉。举个例子，这是我经常需要处理的事情。我按照计划中所告知的那样写代码，但Scrum质量团队的简不断打扰，说她发现了需要解决的错误。可我不能更改，因为那样做必须重新写代码。同时令我困扰的是，我以前迭代 (Sprint)中的代
5、码有错误。除了提出所遇障碍还需做什么？把这些障碍集中放到一堆，没有任何人会关注它，直到我再次提及。很肯定的一点是，我是不会主动再交代遇到的麻烦。在站立会议中，每一个人的基本流程是相同的，在5分钟过后，我们继续写代码。只是我们需要耗时回到编码状态，这让我们丧失了额外的30分钟生产力。但报告团队的站立会议每天都会持续一个小时，因为他们必须在迭代 (Sprint)期间应对所有变化，并不断地努力应对以避免事态进一步升级，这基本上是不可能完成的任务。演示演示是另一种无效的练习。通常，没有什么好展示的，因此会取消该演示。有时我们有新奇的工作代码，就会向项目经理展示此代码。读者可能想知道为什么是这样。项目经
6、理只对项目的完成进度感兴趣，而对在两周内的停滞进展漠不关心。如前所述：演示根本一文不值。回顾会议回顾会议是最有趣的活动，因为它使我们释放压力。除非项目经理参加会议，否则我们便可以畅所欲言。但这种情况很少发生。除非项目经理必须以项目成员为代价释放压力。但回顾会议也有糟糕的地方，因为它不断重复。我们一遍又一遍地讨论了同样的事情，没有任何改变。关键时刻每一个项目都有一个关键时刻：在这几周或几个月里，必须交付项目，并处理软件的不稳定状况和用户投诉带来的严重后果。在这些时日中，我们或多或少地背离了Scrum管理方法。在工作时间长达80多个小时的那几周中，我们经常有意避免这些例行活动。那几周，我们濒临极限
7、。我们说：“停止Scrum项目管理方法！”正如之前所说，这样的工作模式是不持久的。我们需要做出根本性的变革，停止使用Scrum项目管理方法。这是迄今为止所做的最佳选择。以下是原因。图源：Unsplash全新的工作方式我们明白，为了公司的生存，我们必须改变。目前公司成长陷入停滞，面临一系列麻烦。我们从评估公司所处环境的性质开始，来确立最优的行动方针。产品环境的性质我们开始意识到，自己的产品环境是完全不可预测的。很明显，我们无法提前几个月制定详细的计划，因为在这个几个月中，事情总是在变化。例如:关于如何解决特定主题的新思路，从已有的软件中学到了什么，市场发展状况我们承认自己的产品环境是复杂的。小举
8、措已知产品环境很复杂，所以只应该采取一些小举措，评估我们做了什么，然后确定下一步要做的事情。我们选择了一种迭代方法。迭代可能是一天到一个月之间的所有事情，具体取决于团队认为怎样是最好的。团队构建工作产品所必备的能力我们认为需要具备所有相应能力来在一个团队中构建有效的产品。我们不再设置特定的业务分析团队，编码团队和质量检查团队。而是将这些技术人员全部集中在一个团队中，这具体取决于构建产品迭代所需的条件。一个人专门负责管理待办事项的优先级很幸运，我们的团队有一位项目经理，但其他团队却没有。我们决定，有且只有一个人负责管理产品积压。这将有助于防止团队迷失方向以及帮助团队重新集中注意力。从项目到产品我
9、们放弃了确定项目的范围，预算和期限的想法。取而代之的是，我们开始追求产品愿景，并为实现这一愿景开始了迭代的旅程。在这种情况下，某些职位和会议就变得过时了，例如项目经理和指导委员会。通常，我们可以为参与人员找到其他职位，但是他们也必须学会适应新的工作方式和公司文化。每一次迭代都有一个目标迭代都应该确立一个目标，并选择要添加到迭代计划中的事项来促成目标实现。通过制定目标，团队可以专注于要做的事情，这也将有助于团队内部的协作。举个例子，目标可能是：“让我们构建我们的第一个完整的端到端功能，以便从中学习并向我们的受众展示它的含义”。每日讨论目标站立会议也有了调整。首先：团队可以自主确定是否开展站立会议
10、。不过，更重要的是：站立会议的内容是关于迭代目标的进展，并且将其转化为真正的团队合作。突然间，每个团队成员都致力于实现同一目标是不切实际的。新的见解可能会改变待办事项，淘汰过时的事项，增加其他有助于达成目标的事项。团队预测可承担的工作量以及确定工作方式规避其他人告诉团队应该做什么的情况。结论是，团队成员非常了解自己可以承担多少工作。他们可以最好地预测自己的成效，因为他们是这方面的专家。我们同时也认为，团队可以找到自己的方式来实现迭代目标，而无需他人的指示。演示：不仅仅是展示软件演示也有所改变，变成了交互式会议。我们在演示中仍然展示了已构建的内容，还讨论了迭代的目标以及为实现该目标所做的工作。我
11、们也开始与利益相关者讨论下一步的计划，因为这不再是预先确定的。演示变成了进行战略讨论的会议。各种新见解都可能改变待办事项的优先级，从而影响下一次迭代。回顾会议带来的改善我们也对回顾会议做出了改变。回顾会议不再是投诉大会。相反，团队成员从各个方面讨论如何去改善团队的工作方式，从团队互动到影响团队的公司文化，从团队级别的编码标准到公司制度和法规，以及任何可能有助于改善团队的事项和当下紧急事项。图源：Unsplash主要成果在放弃了原有的工作方式而转向迭代的工作模式后，我们终于取得了进展。相比从前，我们能提供更多让利益相关者满意的功能。我们掌握了事半功倍的诀窍。顾客的满意度也在上升，团队和管理层也更
12、加融洽！我们东山再起了！建议读者可以效仿我们所做的改变：评估产品环境并决定是否要对产品进行更改。我敢保证，如果能做到上述所说，就会为自己所取得的成就震撼。结语笔者承认，将以前的工作方式称为“ Scrum”是因为团队认为自己拥有适合的业务流程。但事实是，我们的业务流程根本不合适。最重要的是，我们根本不知道Scrum的本质。在此之后，团队成功转向了秉承Scrum精神的另一种工作方式。我们成功从僵化的Scrum模式转型成为真正的Scrum模式，为此，我们非常开心。留言 点赞 关注我们一起分享AI学习与发展的干货欢迎关注全平台AI垂类自媒体 “读芯术”（添加小编微信：dxsxbb，加入读者圈，一起讨论最新鲜的人工智能科技哦）
