为我们的开发流程添加更多结构？

Question

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

我们当前的设置

• 开发人员通常一次只处理2-3个项目。

• 我们的项目以迭代的方式工作，开发人员经常与客户联系，并且功能会慢慢添加并修复错误。

• 我们还有固定交货日期的项目，并且交货时间很长，最终硬件可能会在交货前几周出现。固定项目通常是对现有产品或实施的小改动，并且工作以某种方式混合。

• 我们也正在从咨询转向产品，因此我们偶尔会自费添加我们认为会增加价值的功能。

问题

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

当我们忙的时候，这些计划非常松散。出现问题，低优先级的东西被推迟。有时，开发人员不清楚优先级，因此当优先级出现变化时会出现摩擦。接下来的一周，人们会意识到我们在Z项目上落后了，而且我们都会在很长一段时间内完成任务。

我被告知这对我们这个行业的小型初创公司来说非常普遍，但我只是在寻找方法来限制“办公室里的披萨”的数量。

Answer 1

  

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

多任务处理非常低效。将大脑从一个任务切换到另一个任务需要时间让齿轮转换。

  

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

那为什么要制定计划？

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

  

接下来的一周，我们将意识到我们已经落后于Z项目，而且我们都会拖延很长时间。

如果项目Z上只有一名开发人员，他就不会被客户A的问题分心。

不要考虑为服务于客户群的开发人员池，考虑给定客户的一个开发人员。 （这可能会使度假计划变得更加艰难，但如果你经常拉扯所有人，那么无论如何你都没有足够的时间离开办公室。）

Answer 2

  

我被告知这对我们这个行业的小型初创公司来说非常普遍，但我只是在寻找方法来限制“办公室里的披萨”的数量。

我们都不是。

  

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

由谁分配？

您是否创建了自己的日程安排？如果没有，对管理层创建时间表的唯一回应就是全能。

现实的非全能时间表会打扰管理层。除非你证明你的客户希望用更少的全能者做更好的时间表，否则你无能为力。

减少全能者的唯一方法就是尽早完成任务。但是，如果硬件没有尽快到达，你可以做的并不多，是吗？

Answer 3

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

我在一家生产产品的小型软件商店工作。我们与其他同样规模的商店之间最显着的差异是我的全职质量保证（现在不止一个）。这个人在第一天应该带来的价值在测试结束之前不会进行测试。我们使用TestLink。这种方法有几个原因：

1. 重复测试以发现回归错误。你改变了什么，它破坏了什么？
2. 思考如何提前测试功能 - 这是开发人员和QA之间的一个逐步的活动，如果它没有受到伤害，你可能做错了。
3. 让其他人测试并验证您的代码是 好主意 。

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

质量差意味着更长的开发周期。最有效的步骤是QA，缺少单元测试。如果它是一个网络应用程序，我也建议像Selenium，但你正在处理硬件，所以不知道可以做什么。改进估计意味着能够在事情发生时进行预测，这听起来可能听起来不多，但提前知道可能是一种宣泄。

Answer 4

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

如果采用正确的方法，Scrum框架本身将解决您的大部分问题。