哪种编程方法最适合我们？

不幸的是，有人教会了我们的高层管理人员“敏捷”这个词，现在他们希望我们朝着它迈进。我对敏捷有一定的了解（原则上），但从未在实践中使用过。据我所知，这将不适合我们的组织。眼下，事情还很繁琐。这是这样的；

我们是一个非常小的团队-两名开发人员，一名DBA，一名设计师。我工作的公司赚的钱相对于公司规模来说不成比例，其中近95％是纯在线销售。

从开发的角度来看，我们在通常的一天中会遭受很多桌面入侵（我们既是技术支持人员又是开发人员），如果销售团队成员向某人承诺某件事，工作可能会突然间突然消失。我们也承接大型项目，而它们却是不断间断的噩梦。我们中有些人开始把头发扯下来！项目计划是由非技术经理在excel电子表格中制​​定的，他们在其中尝试将任务分解为一口大小的句子，他们可以理解这些句子，并在每个句子旁边放置一个日期。这些日期总是可怕地不切实际，常常被错过，而且我们的会议（大约每周举行一次）经常充满尴尬的时刻，人们问“为什么还没有这样做”。

我很确定敏捷不是我们的理想选择。现在，考虑到（并且我已经尝试过）这家公司不会改变其方式，只有开发团队愿意改变，是否有一种我们可以采用的开发方法，该方法很适合节省一些理智？

敏捷实际上是为解决您遇到的许多实际问题而设计的。如果管理层真的买断了，并且不会破坏这一过程，那么您会看到很大的进步。让我逐点解决您的问题。我的经验是使用Scrum，因此我将以这种观点进行讨论，但是我确信其他实现也有类似的好处。

• 工作突飞猛进这些故事被搁置在待办事项列表的底部，直到产品负责人和团队能够见面并同意将其升级为止。相对于您团队的所有其他承诺，确定其优先级，并且该优先级对于每个有兴趣查找的利益相关者都是可见的。在sprint的中间添加新功能是非常罕见的，并且应该只允许优先级最高的bug中断sprint。令人惊讶的是，有多少“紧急情况”可以等到下周结束，这是正常的期望。
• 进行较大的项目您将可以看到短期优先级如何影响您的长期项目。如果人们不断将用户故事转移到您的长期项目之前，那是可以的，但是为了做出决定，每个人都将知道它将对长期项目的进度产生影响。
• 项目计划是由非技术经理制定的。应该从非技术角度来编写用户故事，但是应该授权Scrum团队进行估算和确定实施细节。
• 日期令人难以置信，因为您是知道自己在做什么的人，因此您的团队会处理所有估计。如果这些估算值不能为企业所接受，则必须确定如何确定功能的优先级。如果他们需要的工作量超出了您的承受能力，那么显然需要雇用更多的人。
• 通常会错过日期 首先，您的估计会更切合实际，应该会有所帮助。另外，您要剔除较小的块并实际完成它们，这有助于企业感觉，即使功能不完整，您也会产生有用的东西。
• 充满尴尬时刻的会议 敏捷具有更高的可见性和更快的反馈周期，并且产品所有者参与其中。您的阻止问题和延迟原因也就不足为奇了。
• 也提供技术支持 与普遍的看法相反，敏捷并非与分散的时间表不兼容。混乱是影响团队速度的因素。如果您通常将一半的时间花在技术支持上，那么您将获得一半的速度。

管理和销售必须意识到的是，敏捷不是一种对开发团队进行更严格控制的方法，它赋予了团队更多的自主权来做自己擅长的事情，同时帮助企业在分配工作时切实考虑其所有优先事项。团队。

我想说的是利用您的管理异想天开！听起来他们在帮您一个忙，并给您一些可以改善您的工作方法的优势。

对他们说，好的，我们将采取敏捷的措施，其中包括：

• 发展与支持的分离
• 正式的需求收集流程-在IT团队的控制下。“故事”等听起来都很模糊-但实际上是一种“正式”的方法，看起来看起来很非正式。
• 调度受IT团队的控制。

如果他们不接受这一点，请告诉他们您不能敏捷。

敏捷不是编程方法，敏捷是项目管理方法。如果高层管理人员真的希望您尝试他们发现的这个新流行语，那么他们需要能够理解敏捷方法是从头开始的，并涉及到管理的所有步骤。如果您需要给他们一些现实的想法，也许组织一次有关敏捷的30分钟Powerpoint演示文稿来给他们一些教育。经理们喜欢Powerpoint。

但是，正如您所说，如果开发团队是唯一愿意改变的人，那么没有开发方法能够为您提供帮助。如果不减轻您的其他职责，中断将继续发生，并且将继续要求您遵守您根本无法满足的期限。

在这种情况下，我的建议是教育（而不是指责）管理该技能的实际情况。

在销售人员决定日常时间表的组织中，没有任何软件开发和项目管理方法可以帮助您。在如此混乱而分心的工作周中，您应该如何管理项目？

如此众多的高级管理人员看到了敏捷的价值，并希望获得它的好处，但是他们几乎永远无法做出必要的内部更改以确保这一举措成功。我所知道的唯一成功的敏捷商店就是以这种方式开始的。从我在销售管理或瀑布式软件开发商店进行此举的专业经验中，我无法回忆起一个实例，因为这需要对文化进行根本性的改变。

文化的这种改变可能吗？是的，但您的情况几乎可以肯定不是。

竞争者通常威胁要改变公司的存在，或威胁公司成败或其他类似情况，以证明重组需要改变文化。在您的情况下，您的公司位于频谱的另一端，那里的钱现在很容易，每个人都在发胖。

当钱很容易的时候，公司从不改变内部。 他们为什么要成功，尽管软件开发失败，而不是因为软件开发成功。

我的最终建议是，如果您是我，我会寻找更好的东西。在这里的人有很好的建议，但我以前看过这首歌和舞，但在您的情况下这是行不通的。

请查看extremeprogramming.org -XP是一种敏捷形式，具有易于理解的方面，您可以选择并选择手推车；一个很好的起点

从交互的声音来看，客户承诺在交互过程中不改变主意将是您的环境的一个良好的起点；-)

如果考虑传统方法和当代方法论的前景，人们就会意识到“敏捷”更多地是一种“反方法论”而不是一种方法论。模式旨在描绘特定上下文中给定问题的“最佳情况”解决方案。直接违反这种解决方案或模式的尝试通常称为“反模式”或更坏的情况。同样，虽然真正的软件开发方法试图在开发解决方案时规定最佳案例实践，但“敏捷”（Scrum，XP等）试图直接违反软件开发过程中的任何和所有结构，而倾向于无序，混乱方法-（最近）似乎也要求（天真的）围观者鼓掌。

话虽如此，应该牢记敏捷哲学产生的背景。尽管当时存在着复杂的迭代方法（例如统一过程），但是主要的方法仍然是旧的瀑布方法，它规定了完整需求分析的“最佳实践”，然后完成设计，然后开发/编码解决方案，然后实施解决方案。显然，这种用于软件开发的工程方法是不明智的-导致在（有时甚至从来没有）看到可执行解决方案之前产生了大量文书工作。

但是，它仍然不能保证像敏捷魔术师那样将婴儿洗澡水扔出去。敏捷方法几乎强制执行对之前使用过的任何操作的直接否定-可能是解决方案的实际编码除外。显然，这表明其创建者的见识有限，或者仅仅是“没有像不想看到的人那样盲目”的情况。

尽管如此，敏捷的优点是它鼓励简化流程并专注于可执行代码-这不可避免地是您最终的交付物。

现在，直接回答您的问题：

考虑到您的环境概述，建议您首先选择一个敏捷实现（即Scrum，XP等）。然后自定义适合您的环境的方法，描绘出团队工作方式的清晰流程，例如：

• 接收用户的请求；

• 优先考虑用户请求；

• 增强功能对现有系统的量具影响（可能在您的每日/每周站立会议中）；

• 估算每个增强功能的开发时间-并将其传达给各个请求用户；

• 在现有系统上执行实际的增强功能（即编码）。

• 进行用户测试-并获得用户的承诺（例如，通过电子邮件），该请求的更改已成功实施。

这应该提供一些结构（和顺序），同时还要保持某种类似的敏捷方法。

鉴于以上所述，请记住，并非出于没有理由就创造了古老的英语言辞“像猴子一样敏捷”！

我要说的是，您需要像敏捷这样的方法对您的团队至关重要。由于您的公司是如此杂乱无章，因此您需要在自己的开发团队中进行更有条理的组织。我不认为您的非技术经理应该与此有任何关系。

如果您要推销您的销售人员并要求现实的截止日期，则需要使用有组织的计划来证明这一点。

另外请注意，如果在没有咨询技术人员的情况下向您提供估算，则请拒绝它们，并使其空白。

也许您的团队和天才的利益相关者都需要专注于增量/迭代方面，才能定期且一致地交付服务。随着时间的推移，销售团队和管理层将对他们提出新的功能请求充满信心，他们可以确保您的团队将在适当的时间范围内交付产品。

当然，您需要投资进行单元/系统/回归测试，自动构建，跟踪测试等，如果还没有的话，要达到目标。

首先，我建议收集一些数据。在安静的时间坐下来，弄清现状到底是怎么回事。如果管理层在实现他们可以称之为敏捷的事情上全力以赴，那么找出对您的团队有用的事情，草拟一份文档，在名字上加上“敏捷”字样，您就可以这样做了。请记住，他们对敏捷的真正了解只有一词，而且它通常用英语来定义，它与敏捷之间存在一些模糊的联系。因此，我提倡的是您的团队走在问题前面，找到适合您的口味，然后以敏捷（tm）的方式向您的管理层展示。否则，一些PHB会拿起一本书，尝试将方钉插入圆孔中，没有人会高兴。

如果您采用“纯粹”的敏捷形式，那么您的团队也必须履行支持职责可能会很困难。面对现实，您的老板可能很难接受说“让我创建一个积压项目，我将在（冲刺结束时）几周内完成该任务。”

最大的障碍是金钱。如果一切都是绿色的肉汁，那么很难说出问题了，需要改变。

祝你好运。

相反，在我看来，敏捷方法正是您所需要的，以便应对错过的截止日期，不切实际的期望以及计划不周的项目。

您的管理层已表明他们对这个新的Buzz单词感兴趣。他们很可能会希望使用它来炒作您产品的营销。这不一定是一件坏事，但是如果您想使Agile方法为您工作，则需要非常小心地对其进行管理。

一半的努力是从管理层那里获得支持。让他们接受敏捷的想法是大部分的战斗。剩下的就是要确保他们的期望得到管理，以便他们继续希望您保持敏捷，并避免他们在您的经理觉得他们对项目管理的控制权在很大程度上滑倒时变得迷惑不解。

在您的公司做出任何决定之前，我建议您聘请一位敏捷教练来进行为期半天的研讨会和讲习班。让所有人（包括经理和开发人员）一起思考关于敏捷的意义，即感觉对您有用，而感觉对您没有用。另一方面，如果管理层信任您的判断，那么您将需要非常熟悉许多敏捷实践和方法，并创建一个研讨会或您自己的研讨会。就个人而言，我会争取聘请经验丰富的教练，这样您就不会浪费很多时间并保持动力。同时，拿起几本优秀的敏捷书籍作为参考，仔细阅读它们，还让它们悬挂在您的办公桌旁，管理层可以看到它们。在您所描述的情况下，潜意识心理学可以创造奇迹。

我至少建议阅读以下内容：

• 精益软件开发 -Mary＆Tom Poppendieck
• 敏捷软件开发 -Robert C. Martin

并且要额外加分（因为我认为这是我提到的其他书籍的绝佳伴侣）：

• 清洁法规 -罗伯特·马丁