我是一个网络开发人员，由三个开发人员和一个设计师组成。现在，我们已经实施了五个月的敏捷Scrum软件开发方法。但是我有一种奇怪的感觉，我只是想在这个网站上分享。
人类生活中的一个重要因素是决策过程。但是，您做出的决定有很大的不同。有些决定只是内部力量或外部力量的结果，而其他决定则完全基于您的自由意志，而某些决定只是介于两者之间。您拥有更大的决策自由度，您的工作将变得更加自我驱动。这似乎是规则。因为我们倾向于自己塑造自己的生活。
决定做什么或被告知要做什么之间有很大的区别。在做出与开发，分析，确定实施优先级等相关的决策时拥有更大的自由度。我感觉自己正在决定自己在做什么。 ，现在许多决定完全来自产品负责人。他优先考虑PBI，他分析软件应如何工作，甚至有时应如何实现UI和功能。我知道这是Scrum方法的一部分，并且我也知道这可能会在将来导致更好的产品销售。但是，我现在感觉总是被告知要做某事，而不是决定做某事。现在，这种综合症使我对工作更加被动。
我倾向于减少搜索以找到更好的解决方案，方法或技术
希望工作愉快的早晨。相反，我感觉自己被迫为了生存而工作
下班后我更渴望去做自己的业余爱好项目
我不会再推动团队达到更高的技术水平
我现在在晚餐或下午茶时间上花费更多的时间，并且对恢复工作的热情降低了。 />最大的问题是，我也在同事中看到并诊断了这种行为。是混乱的结果吗？ Scrum真的使开发团队感觉自己没有参与整个软件的形成，从而使项目变得被动了吗？
如何克服这种感觉？
#1 楼
但是，我现在总是觉得总是被告知要去做某事，而不是决定去做某事。铁轨。敏捷项目不应该是这样。 “过程中的人员过多”的措辞应包括“我们不强迫我们的人员做令人讨厌的事情”。这里有一些想法：
你在做“ scrum but”吗？也就是说，一部分是混乱，一部分是其他事情。 （即：“我们正在做Scrum，但是我们所有的故事都必须来自我们的PMO，而不是产品所有者。”）这些天很多疯狂的废话被称为Scrum。
您个人吗？ ，没有参与您应该在哪个过程？我知道许多人对故事的内容感到不满，事实证明，只有故事在sprint待办事项列表中，他们才会参与其中。在故事发展过程中尽早与产品负责人交谈，并获得您的反馈。（作为采购员，他们拥有最终决定权，但这并不意味着他们必须独自做。）
在Scrum中，团队应该拥有流程，并且期望流程会随着时间的推移而变化，以适应团队的需求。在回顾中提出您的问题。如果您可以提出一个流程调整建议，这往往会使某些团队更容易出售。
评论
+1 Scrum（与所有敏捷方法一样）在交谈中比在指导上重。采购订单应描述最终结果需要完成的工作，然后让设计人员和开发人员就达到目标的方式进行互动。
– StevenV
11年8月16日在12:17
“人们超过流程”：有趣，那么为什么要实行SCRUM流程而不是让人们使用自己的流程呢？为什么所有这些以透明性的名义采取的措施（结对编程，频繁的进度审查）都可以更加紧密地监视开发人员的工作？
–乔治
2014年6月27日下午4:56
@乔治：因为结构化的开发使团队可以一起工作，而不会一直踩着对方的脚。我们只是还没有想出如何完美地做到这一点。
– Ph子
14年6月27日在8:16
@Giogio，这通常是敏捷的问题。尽管目标是让人们超越流程，但实际上敏捷却在宗教上受到追捧-这又将流程置于人们之上。就个人而言，我认为精益在此方面比敏捷做得更好，尽管精益并未尝试强制执行严格的团队横向结构-它确实允许开发人员更好地选择任务。假设您的团队不会改变，除了您现在正在做的事情外，看板还可以使管理层高兴，也让您高兴，从而使您可以自由选择故事/任务。
–乔诺
2014年11月7日，下午2:32
#2 楼
您的问题不是Scrum（正如评论中的Jarrod Roberson所说，这不是Scrum所描述的）-这是产品所有者的微观管理以及您（和团队）缺乏自信的原因。由于使用了scrum方法，现在许多决策仅来自产品所有者。他将PBI划分优先级，分析软件应该如何工作，甚至有时应如何实现UI和功能。我知道这是scrum方法的一部分。”你误会了。只需对Scrum的Wikipedia页面进行简单浏览，就可以看到：“团队，一个跨职能的小组，负责实际的分析，设计，实现，测试等。”看到？产品负责人会告诉您该怎么做，但是要由团队来决定如何做。听取产品负责人的意见，但最终决定权取决于您（或团队）。
BTW微管理确实将主动开发人员转变为被动开发人员。
评论
最后一行
–维瓦尼
2011年8月16日14:33
“产品负责人会告诉您该怎么做，但是由团队来决定如何做。”对于开发人员来说，这正是一个问题：缺乏创新。大多数时候，客户会想要更快的马，而不是汽车。但是我绝对同意微观管理。
–MaR
11年8月16日在19:11
+1 @Lukas，因为有什么区别和如何区别。谢谢哥们。
– Saeed Neamati
2011年8月17日在7:56
“产品负责人告诉您该怎么做”-我不太同意。他们应该告诉您他们需要什么。微小但重要的区别。换句话说：他们描述了问题/问题，您提供了解决方案。
– DanMan
2014年5月3日21:16
@MaR这就是为什么开发人员不与客户交谈的原因。客户与产品负责人交谈，并要求更快的产品，即P.O。可以看到所有客户的问题，对其进行组合并确定优先级，在此过程中，汽车比快马更好
–伊兹卡塔
2014年6月27日12:31
#3 楼
您所描述的不是SCRUM如果您的产品所有者告诉您如何从技术上讲您的工作，那么您的产品所有者就越过边界，这根本不是SCRUM的意思。
SCRUM旨在使开发人员有更多时间专注于开发问题，并使他们有能力确定事情需要多长时间以及如何处理。
SCRUM是关于协作的，即Sprint计划会议的目的是促进所有利益相关者之间的协作；产品负责人，开发人员和测试。
是，产品负责人应优先考虑功能，首先要根据客户需求交付哪些功能，但开发人员应进行工程设计，而不是产品负责人。
我不同意开发人员应该设计GUI和工作流程，除非他们经过专门授权并受过培训，可以与客户合作并直接与客户哈希功能。程序员在真空中完成的GUI很少能满足客户的需求。
SCRUM旨在实现一种轻量级的过程，该过程在敏捷宣言中是可预测和可重复的。
这让我伤心地听到的故事，很不错的东西被扭曲了这个样子。
评论
人性总会找到从胜利的the口中夺走失败的方法。
– Warren P
13年10月17日在1:54
至少在大多数公司中，应该有SCRUM的概念，而最终有它的含义。 SCRUM本身并不是邪恶的，但是它是一种很容易被管理人员用于邪恶的工具。
– AresAvatar
2015年4月7日，0：33
没有真正的苏格兰人。
–奥塔维奥·马塞多（Otavio Macedo）
19/12/14在23:26
#4 楼
听起来您进入敏捷的冒险已被Scrum破坏了。我发现，在所有敏捷方法中，Scrum的敏捷性最低。它更像是微型瀑布和其他项目管理。当然，这使它成为最受管理层欢迎的管理人员，他们感觉他们正在从那些讨厌的开发人员那里收回控制权，但是您当然看到了这种情况的现实。敏捷不是要遵循规定路径，它旨在使您更具生产力和动力。声明（释义）说的不是人为过程，而这在您使用的系统中已经丢失。
所以改变它。向管理层提出来，并说这是一个倒退的步骤，您的生产率比以前要低，并且您都对它的工作方式不满意。向您展示敏捷宣言（及其邪恶的孪生兄弟），并证明您不仅从该实验中学到了东西，而且还希望将其中的一些好点发展成一个更好的系统（就像您以前所拥有的那样，它看起来运作良好）给你）。
评论
我？是的-我们曾经工作得很好，然后管理层认为敏捷是未来，并施加了混乱，这极大地限制了我们。我们过去不费吹灰之力就陷入了程序和官僚主义的泥潭。我曾经从筹码板上拿了3张卡！灯光闪烁，警报器因违反“乱码方式”而哭了，我曾经把这张卡带回到我的桌子上。项目管理警察来找我。而且我曾经坐在每天的聚会上，那也不好。所有琐事恕我直言，但被做成山。
– gbjbaanb
11年8月16日在10:54
您是否认为您的情况是Scrum的自上而下的不良实施导致生产力下降？您说您陷入了“流程和官僚主义的泥潭”，这很奇怪，因为Scrum是世界上最简单的最不官僚的方法论……实际上，整个Scrum框架只用一张纸或两张纸。不是框架的一部分。但在Saeed的情况下，我确实认为问题在于他工作的组织类型（对开发人员具有极大的自由和决定权）与Scrum适用的组织类型之间存在差距。
– guillaume31
11年8月16日在15:16
@ ian31：是的，那个项目特别糟糕，但是Scrum吸引了那些经理。您根本看不到他们选择看板或Crystal。当这些人掌握了Scrum时，它们很容易变成“ scrum but”。可怜。
– gbjbaanb
2011年8月16日16:19
我认为任何公司都可以将Scrum变成一场宗教仪式是很有趣的。嘿!站在我们假装敏捷的仪式上！嘿!在我们假装听您说话的同时微笑，然后愉快地继续做我们想做的事情！
– Warren P
13-10-17在1:56
我完全不同意这个答案的意图。我认为某种“小瀑布”可能会非常有益，特别是对于没有经验但很聪明的开发人员，他们有责任一次完成5项不同的工作，而不会完成其中的任何一项。实际上，在Scrum中训练我的人说，如果愿意，您仍然可以在Scrum中进行“小瀑布”操作，但理想情况下，它们应该持续几天甚至几小时。我以为，时间太短了。您不能总是在几个小时内设计->实现->测试一个故事。拆分故事以使您也不一定总是最佳的。
–罗宾·格林（Robin Green）
2014年1月5日，12：19
#5 楼
我猜是在Scrum之前，每个人都只是做了想要的事情：yippee ki-yay mf'er。用户是您的恩人，他们会推动故事发展并支付账单。产品负责人确保故事完成。您的小组以某种方式得出结论，产品负责人应告诉您如何编程。您想编写代码或制作出您认为很棒的简洁小应用程序？ “我想先做A而不是B，这样我才能保持选择的自由。”寻找其他的恩人，而不是新的开发方法。
您陷入了“项目所有者”标题之类的问题。如果您有充分的理由不同意这个故事，请说些什么，然后提出自己的观点。您可能不会总是赢。返回用户并让他们知道请求存在有效问题是他们的工作。让我们面对现实吧，如果故事要求您全天随机删除数据库，没有备份，没有数据丢失或停机时间，那么您就有问题并有责任将故事弄清楚。
#6 楼
我认为，只是你们已经习惯了拥有更多所有权，而且我认为每个人都更喜欢它的人性。是为开发人员而非客户编写的。您的新方法应该减少这种情况，但要以牺牲主人翁感为代价。评论
100％同意。您现在与产品负责人更加保持一致，但这意味着您拥有更少的自由去做自己认为正确的事情。我也经历过这一点，这很糟糕，使我的工作变得不那么愉快了。但这意味着我可以更好地与业务和产品经理的目标保持一致。企业支付账单-包括我的薪水-是的，他们可以在详细级别上说出他们想要的东西。我认为他们实际上并没有告诉您如何编码。如果他们知道如何自己做。
–迈克尔·杜兰特（Michael Durrant）
13年7月19日在1:46
该企业不付钱给开发人员做他们想要的事情。他们向开发人员支付了良好软件环境所提供的生产率收益。如果您让业务部门“详细地”告诉您该怎么做，您是否真的认为他们会获得他们所寻找的良好软件环境？
–安道尔
2013年11月25日14:56
@Andomar-这是一个平衡。双方都有自己的理想，假设和缺点。忽略任何这些都会导致危险。
–尊诺
13年11月25日在22:38
#7 楼
您是否以“作为角色-我想要-目标/愿望-这样-受益-”的形式获取用户故事？听起来您的产品负责人想要进行设计工作，但他/她可能不是这样做的最佳人选。使用用户故事模式可以帮助确保产品负责人坚持业务利益，并且软件开发由软件开发人员完成。评论
作为开发人员，我不想再看到这种用户故事，这样我就永远不必再因内心的痛苦而吟了。
– Warren P
13年10月17日在1:57
@WarrenP是的，无论是样板代码形式还是样板要求形式，样板都会令人痛苦。我认为关键是应该陈述或理解所有这三个元素，但是更重要的是，每个人都应该清楚真正想要的是什么，而样板化的要求实际上可能会阻碍这一点。特别是如果开发人员开始认为在该模板中填写几个简短的单词总是足够的。
–罗宾·格林（Robin Green）
2014年1月5日，12：24
#8 楼
在Scrum中，开发人员有足够的空间来做出贡献，并就新功能，UI，可用性等方面提供建议。Scrum中需要业务人员与开发人员之间的协作和对话，并且允许。但是最终，产品所有者将拥有最终决定权，因为他是负责使sprint之后（即ROI）sprint产生的软件增量的商业价值最大化的负责人。敏捷宣言：
我们的首要任务是通过尽早并持续交付有价值的软件来满足客户。
产品所有者告诉您必须如何实现UI和功能的做法是不可接受的。在这种情况下，您应该拥有最终决定权，因为您要对所生产软件的内部质量负责。 。但是，大多数敏捷方法将业务领域人员与负责生产软件的团队（开发人员，测试人员...）之间明确区分，这是大多数地方最常见的工作部门。如果我的假设是正确的，我可以理解您的感觉，即您不再能够“对全局产生影响”，但是随着公司的发展，我想不管怎么说还是Scrum都是这样。 br />
关于您提到的分析，设计和其他元开发活动（同样不应由产品负责人完成），敏捷团队应具有跨职能且无孤岛的能力。没有人应该拥有围绕一项特定开发活动的所有知识，因此也许有机会让您多样化，而不仅仅是“代码猴子”。
#9 楼
相反，我发现让产品负责人对功能进行决策可以使我将更多的时间用于生成高质量的代码。另外，如果有合理的顾虑，我总是可以质疑产品所有者的决定，这通常会导致富有成果的讨论。#10 楼
我们在这里练习Scrum。我们每两周召开一次计划会议，提供当前业务优先级，上一个冲刺的成功和失败的信息，并作为一个团队确定下一个冲刺要解决的问题。我们执行此操作的方法之一是按垂直方向上的复杂性和水平上的业务优先级对板上的待办事项进行排序。在那之后，产品负责人得到了他的意见，因此由团队来选择我们想要做的事情。显然，承担起高复杂性，低优先级的任务是很不容易的，但是我们将作为一个团队来决定。它使计划会议时间更长，但这是值得的，并且是敏捷过程的核心部分。
有时候我们确实有微观管理，但这是一个不同的问题。
#11 楼
当团队采用方法论时，您要描述的真正问题是一种常见的病态：他们会闭上大脑。对于新式敏捷系统和旧式重量级系统，情况都是如此。我们应该做什么？A：优化x的实现。也许完全停止这样做。方法论不是您的老板！在这种特定情况下，听起来产品所有者可能做得太多。您能和他谈谈吗？如果您不“做争吵”，您会感到很舒服吗？如果产品负责人对建设性反馈不敏感，则不是方法论问题，而是产品负责人的问题。
#12 楼
我真的不适应整个Scrum事情，因为已经有一段时间了。但是，老实说，这听起来更像是管理人员问题而不是项目管理技术问题。在这种情况下，基于人员的人数要多于基于技术的人数。
评论
没有@temptar，我们的关系真的很好。没有冒犯，没有仇恨，什么也没有。一切都很好，除了我们对工作的感觉之外，其他一切都很好。
– Saeed Neamati
11年8月16日在10:01
#13 楼
我在Scrum上也有过同样的经历，喜欢称之为“故事的暴政”。从我的经验来看，与从事后端工作的人员相比，在创意/设计/前端方面的开发人员遭受的痛苦似乎更多。要么放弃Scrum（通常是不可能和/或适当的，因为毕竟它有其优势），要么引入Google 20％的时间来为开发人员提供创造性的渠道，除了“您可以自由选择如何实施登录页面”，因为实际上您并不受现有代码和系统体系结构的约束，除非您认为在“ for和while循环”之间进行选择的自由是一种自由。
#14 楼
根据我的经验，Scrum可以深入地观察您的工作。它只是坐在你的肩膀上，看着你在做什么。尽管它有自己的优势，但我讨厌使用scrum方法。它期望计数，而不是质量。 Scrum方法论正在损害质量。评论
“质量随着Scrum方法论而受到损害。”：说质量受到损害可能有点极端，但是，是的，项目的可控制性比质量具有更高的优先级。
–乔治
14年6月27日在5:04
令人惊讶的是，有些人对混乱或敏捷知之甚少，却又像当局一样发帖。一个人给人的印象是，一个人在一个功能失调的小组工作了几周，他们说他们在做“混乱”，并得出结论认为应该是混乱的。在这种情况下，这是一个完全匿名的人，在4年内只有一个帖子或评论，并且没有关于该主题的专业知识的证据。这就是为什么我们不能非常认真地对待其中许多评论的原因。
–柯蒂斯·里德（Curtis Reed）
18年2月20日在19:22
#15 楼
领导者在自组织团队中的角色将是一篇博客文章，内容似乎是您的文章中缺少的内容。团队在哪里决定在sprint中完成什么工作？团队在流程和工作中的主人翁在哪里？您是否有足够了解Scrum的人正在执行Scrum而不是它的某些变态版本？#16 楼
您决定做什么或被告知要做什么之间有很大的不同。
根据我的经验，被告知要做什么才有很长的路要走。要做决定的事情。
这种方法的最后结果通常是，我们受指示不是因为他们喜欢权力，也不是因为他们无事可做。相反，在这种方式结束时-当他们对我们的团队获得足够的信心时-他们似乎松了一口气，并高兴地将我们能控制的控制权交给了我们（如果他们的信任确实坚定，他们甚至会尝试通过不仅如此）
哦，以我的经验，这基本上与Scrum /敏捷无关。发生了Scrum，迭代，瀑布之类的事情。似乎信任问题与过程无关。
评论
您确定您不是只是在很多时候犯了功能障碍吗？不错的博客文章。
您描述的不是SCRUM
@乍得我在这里讨论的并不是对我工作状况的抱怨。我只是想知道这种情绪是否是混乱的结果？以及其他开发人员是否也在经历相同的事情？
@Saeed-抱歉，直言不讳，但您的心情是决定如何应对工作环境的结果。它也可能会受到其他人意见和态度的影响，但您也可以选择采用此方法。它使您免于承担设计决策的责任，并让您可以解决特定的问题。它不会消耗您所有的精力，并且可以让您从事更多的家庭项目。您有更多时间发展自己。这些不是坏事。使您快乐不是您雇主的工作。您可以找到其他工作，也可以接受。