代码之家 › 专栏 › 技术社区 › Tim

为我们的开发过程添加更多的结构?

methodology project-management

4

Tim · 技术社区 · 14 年前

我和一个小团队(4个开发人员)一起工作,为我们的定制硬件编写固件和软件。我正在寻找更好的方式来组织团队,更好地定义流程。

我们目前的设置

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

问题

我们每周都有一次会议,会上为每个项目分配一定比例的时间。”客户A希望下周测试功能X”,因此分配了所需的时间客户B和Y有问题,开发人员P可以开车过去看看吗?”等等。

当我们忙的时候,这些计划执行得很松散。出现问题,低优先级的东西被推后。有时,开发人员并不清楚优先级,因此当优先级出现变化时会产生摩擦。下周我们会意识到我们在Z项目上落后了,我们都会度过一些漫长的日子。

有人告诉我,这在我们这个行业的一家小型初创企业中非常普遍,但我只是想办法限制通宵“办公室披萨”的数量。

4 回复 | 直到 14 年前

1

3

chrisaycock spacemanspiff 14 年前

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

一心多用是极其低效的。将大脑从一个任务切换到另一个任务需要时间来切换档位。

当我们忙的时候,这些计划执行得很松散。

那为什么要制定计划呢?

是否可以只为一个任务/产品/客户指定一个开发人员?那么开发人员P是唯一一个和客户B交谈的人?(当然,开发人员需要准确地记录下他在做什么,以防被公交车撞到,但无论如何,他应该记录下问题和路线图。)

下周我们会意识到我们在Z项目上落后了,我们都会度过一些漫长的日子。

如果项目Z只有一个开发人员,他就不会被客户A的问题分散注意力。

不要把开发人员看作是为客户提供服务的人员,而要把一个开发人员看作是为给定客户提供服务的人员。(这可能会让度假计划变得更加困难,但如果你经常通宵加班,那么你就没有足够的时间离开办公室。)

2

S.Lott 14 年前

有人告诉我,这在我们这个行业的一家小型初创企业中非常普遍,但我只是想办法限制通宵“办公室披萨”的数量。

我们不都是吗。

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

谁分配的?

你有自己的日程安排吗?如果没有,管理层为你制定时间表的唯一反应就是通宵工作。

现实的非通宵时间表将困扰管理层。直到你能证明你的客户想要一个更好的日程安排,减少通宵,你没什么可做的。

减少通宵工作的唯一方法就是早点把事情做完。但是如果硬件不能早点到达,你就无能为力了,是吗?

3

1

orangepips 111111 14 年前

两个想法:提高质量和改进评估。

我在一家生产产品的小软件商店工作。我们和我在a工作过的其他类似规模的商店最大的区别是全职QA(现在不止一家)。这个人在第一天应该带来的价值是在测试被写出来之前不测试。我们用 TestLink . 这种做法有几个原因:

重复测试以查找回归错误。你改变了什么,它打破了什么?
考虑如何提前测试功能——这是开发人员和QA之间的一个即兴活动,如果没有影响,那么很可能是你做错了。
让其他人测试并验证您的代码是 好主意 .

在你周围放置一些结构来估计活动。重用一种格式,不管是Excel、MS-Project还是其他什么(至少要用数字方式)。这样做,您将开始看到围绕您所做的构建软件的模式重复。一般来说,包括在你的估计时间考虑它(设计),建筑,测试(QA),固定和部署。再读麦康奈尔的书 Software Estimation ,使用任何你认为值得的东西,这是一本好书。

质量差意味着开发周期更长。最有效的步骤是QA,而不是单元测试。如果它是一个web应用程序,我也会建议像Selenium这样的东西,但是你在处理硬件,所以不确定能做什么。提高估计意味着有能力尝试预测什么时候事情会糟糕,这听起来可能不多,但提前知道可能是一种宣泄。

4

-1

sjt 14 年前

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

如果采用得当,Scrum框架本身将解决大多数问题。