瀑布模式+敏捷模式_敏捷团队成员反模式

瀑布模式+敏捷模式

在这篇博客中，我研究了敏捷团队成员的角色，并解释了我认为对敏捷过程有害的行为或“反模式”。

我的目标是避免产生负面情绪，而是强调这些行为可以改变，从而改善团队。 但是，除非我们意识到它们，否则我们无法更改这些行为。 我们也不太可能更改它们，除非我们了解为什么某些行为可能会对项目的成功产生负面影响。

产品拥有者

不良的用户故事：良好的用户故事对于团队的成功至关重要，因此编写它们可能比人们想象的要难。 通常，对于从其他开发方法过渡的团队来说，要在简洁性和成功条件之间取得平衡是很困难的，但是这为团队提供了功能开发的强大起点。

不愿意换出用户故事：必须对产品负责人进行纪律，以免在该版本已满时不向该版本添加用户故事。 将一个功能优先于另一个功能可能会具有挑战性，但是如果不事先做出这些决定，而将无法完成的工作添加到发行版中，通常会是一个灾难。

开发者

不够灵活：不愿意在自己的舒适区域之外完成任务的开发人员确实会伤害敏捷团队的进度。 尽管使开发人员从事他们最熟练的任务通常最有生产力，但至关重要的是，每个人都愿意在需要时从事他们可能不熟悉的任务。

不能反省：在回顾会议上开发人员的反馈对于继续实施和改进敏捷过程很重要。 如果开发人员不愿意在Sprint期间检查对他们有害的内容，那么团队的总体改善是不可能的。 （ 在此处查看此敏捷回顾性操作方法系列。）

质量保证（QA）

与开发团队没有紧密联系：质量保证工程师需要与开发团队充分合作，以使Sprint末尾有可发布的产品。 从计划到回顾的每个阶段，质量检查工程师的反馈都是关键，因为它消除了将质量检查和开发分开的“敏捷”障碍。

不愿意接受自动化测试：质量检查工程师必须愿意理解并接受自动化测试的作用。 对于一些可能不具备编写自动化测试技能的质量检​​查工程师而言，这可能很困难，但他们可以并且仍然应该与正在编写它们的人员一起工作。

项目经理（Scrum Master）

不会删除阻止程序：项目经理应持续尝试删除/解决阻止程序。 虽然项目经理可能无法直接删除阻止程序，但他们应升级问题或验证问题是否已升级。

将不对回顾性项目采取行动：当团队成员在回顾性会议上提出问题时，项目经理应立即对它们采取行动。 这样做会导致一个非常积极的反馈循环：当项目经理能够向团队报告他们提出的问题已解决时，它鼓励团队与项目经理沟通未来的问题。 相反，如果提出的问题仍未解决或被忽略，则很容易发生通信故障。

忽略状态：要使敏捷项目成功，项目经理必须始终了解团队的当前状态。 不幸的是，一个团队可能陷入陷阱，每天的站立会议变得单调，关于正在发生的事情的关键信息永远不会被讨论或忽略。 尽管不可预见的事件可能会导致Sprint出现问题，但项目经理应该能够尽早发现可能的危险信号，因为他们密切关注团队的问题和进度。

公司管理

害怕改变当前流程：通常很难说服管理层改变流程以支持敏捷开发的风险是值得的。 管理层必须接受存在风险，并了解可以通过敏捷流程有效解决实际问题，解决这些问题将对公司有所帮助，这一点很重要。

代码项目

不愿意接受“快速失败”的方法：管理层通常很难接受敏捷过程有时告诉我们尝试以失败为一种学习机会的理解。 管理层必须接受，敏捷的成功可能看起来与其他开发流程略有不同。

最后的想法

最后，我想重申一下，这些反模式行为是团队成员可以积极改变的。 我认为，促成变革的最佳方法是以团队的形式就这些问题进行公开交流。

翻译自: https://www.javacodegeeks.com/2015/03/agile-team-member-anti-patterns.html

瀑布模式+敏捷模式