我应该如何推广到敏捷/迭代开发周期，并强制进行3周的部署？

Question

我是一支四人小组的一员，我是非官方的领队(基本上，除了头衔之外，我是所有球队的领头羊)。我们在很大程度上是一个“牛仔”的环境，没有建筑或结构，每个人都在做自己的事情。在此之前，我们的生产部署将每隔几个月进行一次，而不会按设定的时间表进行，因为每个开发人员的任务列表中都添加了/删除了这些内容。最近，我们的CIO (半技术性的，但不是真正的程序员)决定每三周进行一次部署；正因为如此，我立即认为，采用迭代开发过程(不一定是完全成熟的敏捷/XP，这将是说服其他人去做的一件大事)将有助于正确地管理预期，因此没有这样一个牵强的想法，即任何新特性都将在三周内完成。

国际海事组织最大的障碍是，我们目前没有任何开发方法(包括没有CI或任何自动化测试)。我们甚至不使用瀑布，我们使用“告诉开发人员X完成一项任务，期望他做所有的事情并完成它”。

有什么建议可以帮助我开始简化迭代方法，A)让其他开发人员参与其中，B)让管理层了解迭代是如何工作的？到目前为止，我的想法包括尝试设置一个CI服务器，并使我们的构建过程自动化(现在只需10到20分钟就可以将应用程序构建到我们的开发服务器上)，因为推送测试和/或TDD在这一点上会遇到很多阻力，并且不断地迫使我们将较大的项目分解成更小的块，这些小块可以在三个星期的周期内迭代完成；我唯一担心的是，除非我误解了，否则敏捷/迭代过程可能会发布软件，也可能不会发布软件(取决于项目范围，您在三周后可能会有“工作”软件，但没有足够的软件可以让用户使用)，而我认为管理层的期望是，在三周内总会有“准备就绪”的东西，而断开连接可能会导致问题。

在这一点上，是否有从业务角度解释敏捷/迭代方法的文献或参考？我所看到的一切只关注于开发人员，以及如何做到这一点，但似乎没有什么能从实际从商人那里获得购买的角度来描述它。

Answer 1

注意。首先，为什么你的首席信息官要求三个星期的周期？看看你是否还没问过。这一点至关重要，因为他可能是在用错误的解决方案解决问题。找出他想要解决的具体问题。你被认为是缓慢但准确的吗？送错东西了？送错东西了吗？等。

如果你是非官方的团队领导，现在是开始吸引其他人的好时机。首先，为老板准备一份建议，详细说明你将如何解决具体问题。做一个能干的人在这里很重要。

CI构建将是一个很好的起点。让其他开发人员来做这件事。如果让另一个开发人员做一些事情的想法没有吸引力，我们需要解决这个非正式的团队领导在实践中的意义。这可能意味着你被利用了，我的意思是尽可能礼貌。

最后和开发人员谈谈。在你和他们谈话之前，他们不会买任何东西。找出他们对当前系统的不喜欢之处，然后根据如何改善他们的问题，向他们推销一种更敏捷的方法。

一切都是关于交流的，我会讲完的。如果你没有在世界上最好的意愿下，在各个层次上进行沟通，敏捷就不会对你起作用。它是90%的通信和协作，10%的其他比特。

Answer 2

Craig的敏捷和迭代开发:管理者指南是一个很好的基于敏捷和迭代开发的经理/业务概述。我高度推荐它。

除此之外，我还和你的首席信息官谈谈这个问题。

Answer 3

韦恩，作为敏捷应用方面的专家顾问，我必须说，推荐的方法是雇佣一位导师:一个曾经经历过这个过程的人，因此知道该期待什么，以及事情是否顺利。通常情况下，事情进展顺利:但是，如果这是第一次，敏捷的轻量级特性会让您感到紧张。

迈克尔·达兰特给出了一些很好的建议。它是关于“人民”的。但是，您也正确地确定了对流程的需求。所以，韦恩，选择一个并收养它！就这么简单。关键是，任何过程都比没有过程好。并且，一旦您采用了一个过程，您就可以评估它的工作效果。只有这样，你才能决定要调整或改变什么。敏捷是关于大胆的；然而，由于您将在短时间的迭代中运行，所以很容易纠正任何错误。敏捷适用于调整流程，也适用于调整您正在开发的软件。

至于从三周的迭代周期中产生“可用”的软件。是的，这是可能的。您需要专注于可测量的需求。这样你就能传递一些有意义的东西。然而，你不会用零敲碎打的方法产生一个完整的软件套件--迭代开发是关于复杂发现(探索)和风险管理--但是，正如你的直觉所告诉你的，它不仅仅是把迭代堆在一起。另外，在使用XP时，不要忘记项目未来的文档和培训需求！

大多数敏捷的采纳咨询公司，比如Gatethorn，都会给即将上市的人提供一些免费的建议。别害怕给他们打电话。毕竟，通过在论坛上回答问题或接电话，我们只知道客户需要什么帮助。所以，韦恩，如果你需要帮助的话，继续回到这个论坛。

祝你一切顺利，理查德(CEO盖特霍恩敏捷思维)