你如何开始将你的项目分成更小的部分？

Question

我见过这个帖子：

Breaking down the project into small tasks

这很有帮助。我不知道从哪里开始。我是否只是阅读了一本关于敏捷的书并将该方法用作项目经理？敏捷是一个从绝对开始到结束的完整系统吗？任何建议的软件也欢迎任何平台。

这是一个适度复杂的Facebook应用程序，如果这很重要。我正试图“做对了”而不是我的裤子座位。我知道每个人“做得对”可能会有所不同，但我需要一些系统化技术。

我不认为完美的项目管理只是正确的总体方向。我知道，除非我打破这种局面并保持热情，否则我永远不会交付。它会很快变得压倒一切 - 只是想到它。

谢谢。

Answer 1

您可以阅读有关敏捷开发的书籍，但不会为您编写代码。我会坐下来离开电脑，在你的项目中写出大约5-10个小任务的清单。它们应该足够小，你应该能够在一两天的工作中完成它们。接下来，为他们写一个时间估计。然后尽可能多地做那些。当你回顾你的时间估计时，你可以反思你的时间管理。

随着时间的推移，请尝试专注于隔离项目中存在的关键功能和抽象。如果您有自己的客户，请在每次迭代时与他们交谈，看看他们对项目的看法。

当你这样做时，你也可以阅读敏捷开发。敏捷开发试图解决在团队工作时遇到的许多问题。如果可以，那么我也会让一位朋友参与其中，你可能会发现你的学习方式更多。

Answer 2

以下是基于Scrum的一些建议步骤。

1. 创建应用程序将执行的功能列表（“产品Backlog”）。理想情况下，这应该由客户完成。

2. 在开发人员完成工作的情况下为这些功能分配总体估算值（可能只是你）。

3. 优先考虑这些功能。再次与客户（如果有）。

4. 将这些功能分配到30天的水桶（Sprint）。

5. 使用分配给Sprint的功能，创建一个任务列表（Sprint积压），可以8-16小时为增量完成。
   
   以下是一些示例：
   
   

   • 为特征X创建数据表。
   • 为屏幕1创建UI布局。
   • 创建事件（s） ）对于屏幕1上的控件
   
   您也不必限制编程任务。只要取得最终结果，任务还可以包括研究等内容。防爆。研究Facebook的API并确定一种界面方法。

6. 在Sprint结束时，根据您/您的团队完成任务的速度（您的速度）进行评估。这可能需要调整产品和/或Sprint Backlog中的估算值。

Answer 3

我的方法是在任何项目上取得进展，这样我就会有很多里程碑，其中有些东西可以运作，并且已经完成了某些定义的点。

我可以在一个简单的命令行应用程序中实现我的应用程序的细节，只是为了看到它与文件系统或网络对话;我可以从文件而不是键盘读取输入，因此我可以快速完成可重复数据的操作，而无需手动重复。

我可以单独处理GUI。我可以调整HTML和CSS，直到我有一个令人惊叹的美丽GUI，而不用担心它的功能。

然后我将构建一个项目，我将前两个子项目结合在一起。然后，我选择两个工作子项目，并创建一个单一的，工作更大的项目。如果需要更多的东西，我可以做到。

优点是我可以更快地处理代码，并且我可以更早地识别风险。项目的较小块更容易测试，我可以单独开发它们。这也让我的编译时间缩短了。

Answer 4

我的工作方式首先是我与非技术人员坐在一起，我们创建了产品中的功能列表。功能列表优先考虑最顶层的功能。一旦我们有了清单，我们就会与技术人员会面。对于我们所拥有的每个功能，我们将其分解为较小的任务，开发人员将提供每个任务完成所需时间的估计。我们计算估计的总时间量并选择第一次迭代的任务。我们的第一次迭代通常在14到21天之间，我们在开发人员之间平均分配工作。这个过程也有助于我们找到依赖关系，我们通常有3个团队：

1. 核心团队 - 致力于api;
2. gui团队致力于图形部分
3. 测试团队 - 为每项任务进行肌动蛋白单元测试。

我们还举行每日站立会议，以了解每项任务的进展情况。通常在迭代结束时，我们有一个工作和测试版本的产品。
在迭代结束时，我们召开会议，了解开发人员遇到的问题。 希望这种关于我们如何使用敏捷的小视图是有帮助的。