将项目分解为多个小任务

Question

我想知道，当一个新的项目到来时，比如说建立一个社交网站，我如何将项目分解为小任务。每个项目通常有2-4个程序员，而且通常没有测试人员。我应该把整个网站从一开始就分成4个小时的任务。我们应该分阶段来做吗？那么测试呢，让程序员测试代码可以吗？

谢谢您抽时间见我。

Answer 1

我们使用一个相当简单的系统。

• 首先，我们将项目拆分成用户故事或“垂直”。例如，"Update Customer".
• Make“是streadsheet.
• Then的第一列中所有垂直方向的列表，位于顶部，您可以放置层或活动。例如，数据层、UI、日志记录。您可以为矩阵中的每个元素分配一个估计，并决定由谁来开发它。
• 将其分解为4个小时的元素是很好的，因为这样每个开发人员就可以在scrum中说：“我今天要做这两个任务”。

对于要在sprint中完成的活动，我们通常会为每个sprint执行此操作。

在测试时，程序员应该通过编写单元测试来测试代码，但测试人员应该执行系统测试。

Answer 2

对于论坛来说，这是一个大问题，所以我将从推荐一本书开始：

Agile Estimating Planning by Mike Cohn

从标题中可以看出，它提出了一种敏捷的方法。

在你购买并阅读这本书之前，这个非常简短的版本可能会有一些用处：

• 首先进行粗粒度规划。例如:我们计划在两个月后部署第一个版本，包含使其真正可用的非常基本的功能。在那之后，我们大约每个月都会有一个新版本。确保你不会涉及太多细节。因为现实无论如何都会扼杀所有详细的计划。您可以将此计划中的步骤视为阶段，但请注意，它们与第一阶段计划的经典阶段分析、设计、实现、测试、部署和部署(deployment
• )并不匹配。使用垂直切片进行规划，即不做规划:首先我们将创建GUI，然后是模型，然后是数据库，但要使用完整的功能，这些功能通常被建模为用户故事。例如：“作为一个用户，我想在系统中输入订单”这将是一个用户故事。用户故事的实现意味着要做从用户界面到持久化的所有事情，也包括测试。(谷歌“用户故事”和“迭代计划”可以获得更多信息。)

对于你的测试问题:开发人员测试他们的代码总比根本不测试要好。但有更好的方法来确保高质量的代码。我推荐以下方法：

• 做测试驱动的开发，也就是先写测试，然后实现。这迫使你和你的团队让代码结构良好，它支持代码的快速更改，因为测试会通知你一些东西被破坏了。
• 至少在部分时间内会进行结对编程(越多越好)。这样可以确保至少有两个人理解每行代码。它还作为隐式训练工作，最后作为代码审查工作，这是一件好事，因为众所周知，代码审查在发现application.

方面比测试更有效。

• 您仍然需要对完整的bug进行手动测试

更多值得阅读的内容和google: agile，scrum，xp，TDD，BDD，Planning Poker，

Answer 3

另一本你可能会觉得有用的书是

Software Estimation: Demystifying the Black Art

作者: Steve McConnell

除此之外，我只能重复其他人所说的话:基本上是“分而治之”。