我花了十年时间才意识到我讨厌敏捷/Scrum
我花了十年时间才意识到我讨厌敏捷/Scrum
°我讨厌发展！
这是你的东西 可能 倾向于在另一个 sprint 之后思考。
一个痴迷于持续学习的热情开发者根本不应该考虑这个，对吧？
果然，这可能是长期敏捷/Scrum 软件开发方法的效果。
现实是， 我爱发展 ！
简要介绍一下我是谁和我做什么，所以你知道这篇文章中提到的很多观点都有真理的种子。
我是一名软件工程师，专门从事所谓的“全栈开发”，它以自我为中心，然而，它代表了我多年来慢慢积累的技能，能够胜任这项工作。
我住在第三世界国家，我的教育结束了我必须照顾家人的时间。我很幸运在实习 恩达瓦 从那时起我的旅程继续。
自从我全职工作或作为世界各地各种软件开发团队的承包商以来，已经 10 年了。无数次让我的家人失望，因为目标、截止日期和紧急生产问题优先于所爱的曾经。我在周末花大量时间学习以弥补知识的缺乏，至少可以说是不健康的。这样做的回报是养活我的自我，当然还有我的口袋
我也没有朋友，因为我一直把我的工作放在首位 疯狂 ，我不怪他们离开我，因为他们绝对正确。
坦率地说，自从我开始，我没有为任何个人项目取得任何实质性的成就，我为之自豪的一切都带有 NDA 的面纱， 所以你可能会对这篇文章持保留态度。
但是，是的，前言已经足够了，我们走吧！
我手上没有足够的手指来计算我参加了多少次团队试图找出问题的会议 做敏捷的正确方法 .
喜欢 婊子 , 我们可以从 敏捷宣言 并遵循文档？
在一个完美的世界里，通过书，总结；
- 我们有一个发布的路线图，主要、次要、补丁、实验。
- 我们根据项目类型向版本添加版本，遵循语义版本控制或功能版本控制。
- 我们通常将大型应用程序功能分组为 史诗 ，我们稍后用它来分组相关的 用户故事 或者 技术任务。 如果这还不够 **** 我们工作的粒度，我们可以更深层次，将它们中的每一个分解成 子任务 如果需要的话。
然后我们用明确的方式抽出每个故事 验收标准 所以测试人员或其他人实际上可以证明我们做了正确的事情。我们可以添加技术讨论的简短大纲作为 开发说明； 无论开发人员资历如何，这是一个很好的做法。
我们创造正确的 依赖项 之间的故事，所以我们知道什么必须首先开始或不应该完全触及。还可以加 标签 给他们，这样我们就可以按他们的域有效地对他们进行分组和过滤。
正在做 积压改进 不时会帮助我们更新故事或添加缺失的故事。完善板子并使其整洁
大部分应该完成 ** 事先的** 开始一个 ** 规划会议** ， 接着…
在会议本身期间，我们根据史诗和故事对客户的重要性和紧迫性来优先考虑它们，从而产生 冲刺。
我们每天花足够的时间来评估工作量，描述故事，这样所有的未知数都会消失，每个团队成员都完全理解它们。
通过民主、公平、上瘾的过程，每个故事都被赋予了有形的价值， ** 故事点 ,** 因此可以比较故事之间的复杂性，近似于 团队速度 可以在未来的冲刺中进行计算，让管理者在睡觉前感到满足和成就感。
该标准当然可以适应某种工作方式，但核心保持不变。
声音 真的很棒的概念 ，但是是吗？让我们看看这听起来是否熟悉！
◦ 计划会议发生在团队没有足够时间提前完成故事的情况下？
◦ ⏳ 计划会议对于团队中的人数来说太短了？
◦ 给你的故事描述是一个完全的混乱，必须通过不断询问细节来解开？
◦ 给你的故事完全没有描述，只有标题，显然在计划过程中错过了。无论如何，它仍然对你强制执行，因为它有故事点，你必须通过很多人来获得你需要的所有细节并更新故事。
如果它支付账单，为什么不呢？只要经理两天没来问你为什么还在进行中……
◦ 如果它可以是偶数呢 更差？ 想象一个超级详细的分步描述 单行代码 由长期在那里工作的技术负责人撰写。它只是通过阅读技术细节让你大吃一惊，但你设法通过它。然后你开始发现矛盾，不时打扰他的陛下几分钟宝贵的时间？在你放弃这样做之前，你会相信多少次会关注这些故事？你会多少次给他发信息，直到你得到 ** 那个表情** 从那里开始依靠自己？
更不用说著名的：
有需要可以私信或电话联系我
任何技术主管，永远。
◦ 有多少次，故事指向过程受到单个 10 倍开发人员或在公司工作多年的一组此类开发人员的影响。他们使用自己尚未适应的自定义实现和模式。甚至可能会感到羞耻，或者在这个过程中催促你？
◦ 有多少次故事点的有形价值没有被普遍理解或在短期内被理解。团队中有多少次在“故事点应该代表什么”方面存在分歧？时间、精力或介于两者之间的史诗般的战斗。
◦ 有多少人在讲故事时感到冒名顶替综合症？尽管您的经验包袱，但如果您对某张票的估计过低或过高，每个人都会盯着您？如果运气在你身边，并且团队足够友善，可以忽略它或微笑，你就中了彩票，否则你 ** 其实感觉** 他们死死的眼睛盯着你。你需要提醒他们，它被称为 估计 因为某种原因
◦ 有多少次你成为你的领导者做出的短视规划和建筑决策的受害者，这使你的生活复杂化了十倍，而与此同时，他们不愿接受诚实和建设性的反馈，这表现在给你贴上责备的标签，即使你当时没有任何想法。
◦ 由于不正确的估计和害怕因为对自己的无能而受到责备而不得不做多少小时的无薪加班？不正确的计划、错过的开发缓冲、不可预见的开发问题、经验差距和使用工具的信心可能是很好的候选人，可以减轻您的一些责任并减轻压力。
◦ 有多少次你被项目经理忽视了，他对微观管理非常着迷，无法理解他的角色超出了每 40 分钟检查一次你的范围。
◦ 在回顾期间，有多少次你沉默或觉得没有人想听到你的意见或反馈，很多专栏要么只是为了精英，要么只是为了“成为”。你有多少次给出反馈，直到你因为没有任何改变而停止关心？
◦ 设定了多少次不切实际的最后期限，而您或整个团队必须工作 真的很难 去见他们？我们在这里谈论有偿/无偿加班、在发展中偷工减料、精疲力竭、全队抑郁、疲劳？
不幸的是，这个列表可以继续下去。核心问题是团队和个人的人为因素。
一些可以帮助您度过敏捷地狱的关键建议
主要角色 （技术主管、项目经理、开发主管、架构师）
- 扼杀微观管理， 信任你的员工 .
如果您有信任问题（这是可以理解的），请默默地检查它们 经他们同意 （屏幕跟踪器、活动跟踪器等）。
无需每 40 分钟用您的原件惹恼他们
“嘿！你好吗？好久不见，那票怎么样了？” - 在致力于敏捷仪式的日子里花费你需要的任何时间。分解故事，为您的工单添加描述、屏幕截图、验收标准、开发说明。做茶歇、讨论、头脑风暴。
在 30 个故事点上花费超过 30 分钟。 - ⚡ 不断检查故事内容的相关性，确保门票的上下限非常清晰。
- 只在描述中添加这么多，以使整体方向清晰。无需深入到单行代码的逐步实现，否则，请自己动手。
- 在故事中，突出显示尚未最终完成的设计元素。对于 API，请确保指定确切的所需输出，如果开发人员的工作或多或少超出预期，请不要责怪。让猜测的空间变窄。
- 在估算时，选择真正的民主，不要让单个开发人员决定整个团队的故事指向。总是有一个缓冲区并选择更高的估计。
如果你简短地问另一个人“你对 3 还好吗？”而不是 5，确保他们理解为什么每个人都选择 3。
正式员工 （任何资历开发人员、QA 等）
- 坚如磐石，努力工作，不要让你的情绪发泄。尝试忽略：
*内部戏剧
- 截止日期
- 故事点
- 路线图
- 微观管理
- 项目经理烦人的 ping
专注于你的工作，始终做到最好，专注于你编写的代码，最终，这就是你表现的证明。您运行的测试例程，就是您作为测试人员效率的证明。
2. 对任何谈话都足够友好，不要走极端。
3. 尽量保持积极的态度，尽管你已经被置于其中。
不要过度投资于任何这种敏捷的废话， 相信我，它会让你筋疲力尽。永远记住你很容易被替换，达到建筑师的水平，所以尽量不要让自己筋疲力尽，直到你达到你的计划目标。
最后，如果没有任何工作，总有办法......
可卡因！！ ooor 找到一个做看板的项目 😃
说真的，不要吸毒，做看板！
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明
