为我们的开发流程添加更多结构？ [关闭]答案

【问题标题】：Adding more structure to our development processes? [closed]为我们的开发流程添加更多结构？ [关闭]
【发布时间】：2010-11-29 01:25:45
【问题描述】：

我与一个小团队（4 名开发人员）一起为我们的定制硬件编写固件和软件。我正在寻找更好的方法来组织团队并更好地定义流程。

我们目前的设置

开发人员通常一次开发 2-3 个项目。
我们的项目以迭代方式工作，开发人员定期与客户联系，慢慢添加功能并修复错误。
我们也有固定交付日期的项目，而且交付周期长，最终硬件可能仅在交付前几周出现。固定项目通常是对现有产品或实施的微小更改，并且工作以某种方式混合在一起。
我们也在从咨询转向产品，因此我们偶尔会自费添加我们认为会增加价值的功能。

问题

我们每周举行一次会议，为每个项目分配一定比例的时间。 “客户 A 想下周测试功能 X”，因此分配了所需的时间。 “客户B跟Y有问题，开发者P能下车看看吗？”等

当我们忙碌时，这些计划的执行非常松散。问题出现了，低优先级的东西被推迟了。有时，开发人员并不清楚优先级，因此当优先级似乎发生变化时会产生摩擦。下周我们将意识到我们在 Z 项目上落后了，我们都会度过漫长的几天。

有人告诉我，这对于我们行业中的一家小型初创公司来说很常见，但我只是在想办法限制“办公室里的披萨”通宵达旦的人数。

【问题讨论】：

你为什么在这里有一个敏捷标签？是你想变得敏捷还是你认为你已经敏捷了？您遵循 12 条敏捷原则中的哪一条？在您的描述中，我只能看到几个敏捷原则被遵循。

标签： project-management methodology

【解决方案1】：

开发人员通常一次开发 2-3 个项目。

多任务处理非常低效。将大脑从一项任务切换到另一项任务需要时间来换档。

当我们忙的时候，这些计划的执行非常松散。

那为什么还要制定计划呢？

是否可以仅将一名开发人员专门用于一项任务/产品/客户？那么开发人员 P 是唯一与客户 B 交谈的人吗？（当然，开发人员需要准确记录他在做什么，以防他被公共汽车撞到，但无论如何他应该记录问题和路线图。）

下周我们将意识到我们在 Z 项目上落后了，而且我们都会度过漫长的几天。

如果项目 Z 中只有一个开发人员，他就不会因为客户 A 的问题而分心。

不要考虑为一组客户服务的开发人员池，而是为特定客户考虑一个开发人员。（这会使假期计划变得更加困难，但如果你经常熬夜，无论如何你都没有足够的时间离开办公室。）

【讨论】：

客户通常只与一个开发人员打交道，但由于我们是一个做硬件、固件和软件的小团队，几乎每个人都参与了每个项目。
您是否必须为购买您产品的每个人完全定制硬件和软件？这听起来不像是可扩展的商业模式。你需要一些方法来重用以前的工作。
硬件相当固定。但如果客户承诺购买 1000 台，我们将通过附加板添加功能，但会收取开发时间和进一步的硬件成本。与我们打交道的公司也很乐意付费将软件/固件集成到他们现有的系统中，所以我们不能拒绝这项工作！
@Jim 如果客户非常乐意付款，为什么不雇佣更多的开发人员呢？如果您只为每位客户指定一名开发人员，布鲁克斯定律将不适用。

【解决方案2】：

有人告诉我，这对于我们行业中的一家小型初创公司来说很常见，但我只是在想办法限制“办公室里的披萨”通宵达旦的人数。

我们不都是吗。

“客户 A 想下周测试功能 X”，因此分配了所需的时间。

由谁分配？

您是否制定自己的时间表？如果没有，管理层为您制定时间表的唯一回应就是通宵达旦。

现实的非通宵时间表会打扰管理层。除非您能够证明您的客户想要一个更好的时间表和更少的通宵，否则您无能为力。

减少通宵的唯一方法是尽快完成工作。但如果硬件不早点到货，你就无能为力了，不是吗？

【讨论】：

对于基于固定期限的项目，我们通常会很好地参与日程安排。增量项目更加困难，因为“最终游戏”的定义很松散。通常他们已经同意购买硬件，我们正在等待协商软件功能。当我们正在为另一个客户开发类似的东西时，我们将开始使用它。
@Jim：“我们一般都很好地参与了日程安排”，你还有“办公室里的披萨”通宵吗？由于您正在创建自己的问题，因此我不确定您的问题是什么。也许您应该更新问题以澄清您想要做的不同的事情。
我们确实参与了固定期限项目的时间表，但迭代项目只是在进行中，管理层会分配他们认为适合产品开发的任何时间。作为一个年轻的团队，我们的估计可能会变得更好！
@Jim：“管理层分配他们认为适合产品开发的任何时间”。 “对管理层为您制定时间表的唯一回应是通宵达旦”。我不明白你的cmets。请更新您的问题，以阐明您想以不同的方式做些什么。或者，你只是在抱怨？我完全不明白这个问题。请说明您想要更改的内容。

【解决方案3】：

两个想法：提高质量和改进估算。

我在一家生产产品的小型软件商店工作。我们与我工作过的其他类似规模的商店之间最显着的区别是全职 QA（现在不止一个）。这个人在第一天应该带来的价值是在写出测试之前不进行测试。我们使用TestLink。这种方法有几个原因：

重复测试以发现回归错误。你改变了一些东西，它破坏了什么？
提前考虑如何测试功能 - 这是开发人员和 QA 之间的一项面对面的活动，如果没有造成伤害，那么您可能做错了。
让其他人测试和验证您的代码是一个好主意。

在您的估算活动周围放置一些结构。重用一种格式，无论是 Excel、MS Project 还是其他格式（至少以数字方式进行）。这样做，您将开始看到围绕您构建软件的工作重复的模式。一般来说，在您的估计中包括考虑它（也称为设计）、构建、测试 (QA)、修复和部署的时间。另外，阅读 McConnell 的书 Software Estimation，使用任何你认为值得的书，这是一本很棒的书。

质量差意味着开发周期更长。最有效的步骤是质量检查，缺少单元测试。如果它是一个网络应用程序，我还建议使用 Selenium 之类的东西，但你正在处理硬件，所以不确定可以做什么。改进估计意味着能够尝试预测事情何时会糟糕，这听起来可能不多，但提前知道可能是一种宣泄。

【讨论】：

【解决方案4】：

我建议您遵循 Scrum 框架。使用企业产品创建 Scrum 环境。让产品团队为他们自己的单个产品开发功能，这是组合企业产品的一部分。如果你有资源，就有生产/问题支持和基础设施 Scrum 团队。如果问题来得太快，请让基础架构团队尝试遵循看板或 Scrumban。

如果采用得当，Scrum 框架本身将解决您的大部分问题。

【讨论】：