我的工作方式应该如何在敏捷的工作场所进行改变？

Question

在我的工作场所，我们“遵循”敏捷方法。但是，我们所做的只是站起来。我怎样才能改变我作为开发人员的工作方式，遵循敏捷？

由于

Answer 1

Agile实际上是一组基于迭代开发的软件开发方法，其中需求和解决方案通过自组织跨职能团队之间的协作发展。你自己很难做到。

也就是说，你可以做些让你更敏捷的事情，并且你的队友在看到优势后可以选择效仿：

• 小块工作。您希望将任务分解为可在合理时间内完成的部分。 （我工作的团队通常以半天为单位测量东西。因此，你可以每天完成2个单位的工作，一周完成10个单位。）
• 提交正常运行的代码。当您正在工作时，您希望经常提交代码，但只有在代码编译时才能提交代码，并且在不破坏单元测试的情况下工作。您不希望成为提交破坏构建的代码的人。
• 编写单元测试。您的团队正在为其代码编写单元测试，对吗？如果没有，那么现在就开始吧。编写单元测试将迫使您构建代码以使其可测试，这也将迫使您改进实现和设计。它还会检测回归错误，通过检查有人进行更改时过去工作的所有内容。
• 单元测试所有错误。每当您需要修复错误时，首先编写一个单元测试，导致您的代码以与错误相同的方式失败。然后修复你的代码。如果修复良好，您的单元测试现在应该通过 - 并且所有其他单元测试应该继续通过。
• 单元测试所有新代码。当您构建新代码时，您应该构建一个规范。确保规范良好的最佳方法之一是使用规范为代码编写单元测试。一旦你有足够的测试来验证你想要编写的代码，就去工作，根据测试测试代码。一旦您的代码通过测试，您就可以提交到团队存储库。
• 使用持续集成。这是团队本身应该做的事情，但是如果你可以使用额外的PC（它不必很快，只需要足够的内存和磁盘空间来构建您的工具并构建您的软件）。在其上加载CruiseControl.net或Hudson，将其指向存储库，并将其配置为等待新提交，签出工作区，构建软件以及运行单元测试。为什么？因为在变更传播给整个团队之前，当有人忽略了所有变更时，它会被捕获。
• 自动构建。在使用持续集成之前，您需要能够无需人工干预即可重复构建软件。如果您使用的是Visual Studio，请了解如何使用MSBuild或Nant进行构建。如果您正在使用Java，请学习如何使用Ant或Maven进行构建。通过自动构建，可以避免与手动步骤相关的构建和释放问题。 （我曾经从笔记本中减少了一个项目的构建过程，该笔记本每周需要2名专业人员完成，到一组需要大约一个小时才能运行的脚本 - 你最好相信这会提高版本的质量。）

Answer 2

这听起来像是每天开会的瀑布。实现敏捷是一个巨大的差异，你不能自己从瀑布变为敏捷，你需要其他人跟随它来工作。

我认为最大的变化是停止在“项目”范围内思考，并开始以非常小的工作量来思考。例如，当项目“创建网站X”出现时，您需要在逐页的基础上将其分解。确定需要做什么，我们如何获取，存储，更新，显示数据。编写执行此操作所需的不同代码需要多长时间？一旦确定了（根据我的经验，敏捷计划涉及更多），那么你可以开始说“到星期三，我将向你们展示我可以保存在第X页上，我将展示第Y页的数据“。

通常会有一个“计划”会议。这可能需要一个小时或者可能需要6个，这取决于您的标准传达的程度，团队中有多少成员以及您正在使用的sprint有多长。每个人都选择他们将要做的工作，并对其进行估算。在您的冲刺（大多数人建议为一到两周）后，还有另一次会议。理想情况下，在这次会议中，每个人都将演示他们过去一周所做的事情，并且它将完美地运作。之后有一些反思，什么效果很好？我们错误地估计了什么吗？

这是一个“周期”，做到50次，网站X完成！ ：）

Answer 3

首先，没有像“ 敏捷方法”这样的东西，敏捷是一个总括性的术语，描述了几种敏捷方法，如果你的所有工作场所都在做是站起来的，我已经可以告诉你，这不会让工作场所变得敏捷。

其次，虽然您可以在个人层面采用一些“敏捷实践”（尤其是工程实践），但这永远不足以让您变得敏捷：1。敏捷在我看来更多是关于推动产品开发的方式而不是工程实践2.敏捷是一个集体的团队游戏。

所以，我的建议是潜入例如Scrum and XP from the Trenches并为你的同事，老板或潜在的赞助商获取一些副本。

Answer 4

祝贺你站起来。这是一个很好的第一次改变。

你要问的是你或者团队希望在这方面做得更好。在这种情况下，您可以采用以下两种方式之一：

• 巨大变化，或
• 增量改进

如果您决定要做出巨大改变，那么您可能需要一些书籍，培训以及教练或经验丰富的从业者。如果组织中的高层人员也投资于变革，这通常是成功的。

如果你决定要逐步提高，那么为了获得一些想法，值得阅读敏捷。我推荐“XP Explained”。那里也有很多博客，以及这里的帖子。你需要做的两件事是：

• 尝试提供一些软件，或者至少从利益相关者那里获得反馈
• 弄清楚为什么这很难以及你可以做些什么来使它变得更容易。

我们通常首先使用showcases，第二次使用回顾。我建议至少每两周进行一次回顾，即使展示工作代码真的很难。

我经常看到的问题很快就会出现问题，包括：

• 团队不在同一地点（“团队”包括BA和QAs）
• 环境不适合
• 缺乏对正在进行的工作或总体目标的可见性
• 正在进行太多工作 - 事情已经开始但尚未完成
• 正在进行的项目，没有人真正关心
• 项目进展显然不值得做
• 代码库真的很难改变
• 责备文化阻碍了合作。

无论你发现什么，你都不会是第一个。

请注意，敏捷是一种透明的方法，无论您使用哪种版本。许多人因透明度而感到害怕。这个是正常的。有时高层管理人员不允许事情变得透明，从而产生既得利益。这也很常见，此时您可能需要外部帮助。但是，提供工作软件非常有说服力。

祝你好运！

Answer 5

如果你想从头开始做到这一点，那么你所需要的只是敏捷宣言和每周重复的回顾。但我想这还不够，所以这是我的创业名单：

1. 将现有项目任务/积分/待办事项转换为用户故事
2. 对所有事情进行配对。经常切换对！
3. 使用测试驱动开发。力争100％覆盖！
4. 使用一周的迭代。重复就是学习！
5. 在每次迭代中为客户提供有价值的软件。

Answer 6

即使整个团队不能以敏捷的方式工作，也很少有您可以采用的实践作为开发人员。您可以从CI，TDD，自动部署开始。作为一个团队，您可以尝试回顾会议。