如何将一个编程项目分解为其他开发人员的任务？ [关闭]

#1 楼

一个正确的答案可以填满几本书。我会想到一个流行的项目符号列表，对此我会想到，Google和书籍将为您完成其余工作。




基础知识



不要一个人走。尽量让您的队友参与。

轻装上路。
民主，但不要太多。有时，并不是要满足最多的人，而是要伤害最少的人。

保持（需要做的）事情和（完成的）事情分开。
了解Scrum（“什么”），XP（极限编程，“如何”），看板（“多少”），精益（“什么”）和DevOps（“与谁”）。

精益还与流程有关：对于整体效率而言，流程效率通常比个人效率更为重要。
了解软件的工艺，简洁代码和实用编程。
好的体系结构是使决策数量最大化。
Scrum / XP / Lean / Agile旨在最大化未完成的工作量：YAGNI。
软件的主要价值在于您可以轻松地对其进行更改。做到它应该做的事情很重要，但这只是它的次要价值。
首选迭代式和增量式方法，几乎​​在所有事情（特别是会议）上都使用时间框，因为适用霍夫施塔特定律，所以使帕金森定律成为您的朋友。 >平衡团队结构，同时了解康威定律和塔克曼的团队发展阶段。
编程是一个四方性，它是科学，工程，艺术和手工艺的全部，并且需要保持平衡。
因为Scrum / XP / XYZ对某人（包括我）有好处，但不一定意味着它对您有好处/适合您的环境。不要盲目地遵循炒作，先了解它。

检查并适应！ （咒语）

避免重复-只有一次！ （XP咒语）又名DRY-不要重复自己又名SPOT-单点真理





“什么世界”工作分解过程


将需求作为用户故事/工作故事收集到产品待办列表中。

（用户故事的）用户类似于Actor（在UML中），类似于与角色相似的角色。 br />
基于INVEST（独立，可协商，有价值，可评估，小型，可测试）满足用户团队的“就绪”定义之前，请精炼用户案例。 （Scrum会议：待办事项列表的精简）
按业务价值对产品待办事项列表进行排序。
在故事准备就绪之前（根据准备就绪的定义准备就绪），请勿开始处理故事。
使用规划扑克以评估故事点故事的工作量。使用“三角剖分比较”可确保估计的一致性。

昨天的天气是最佳估计，希望最差。

如果故事太大，则将其拆分。
改进定义为完成的交付文化。
在完成之前（根据完成的定义完成），不接受用户故事的实现。
在同一代码库上的多个团队应该达成共识并共享相同的“完成”定义（尤其是编码标准）。
使用燃尽图检查进度。
定期与利益相关者核对团队是否真正需要什么。 （Scrum会议：Sprint审查）



故事细目


列出并描述用户/角色/演员/角色（产品负责人） ）
史诗->故事（用户故事或工作故事）（产品负责人）
故事->接受标准（产品负责人）
故事->子任务（开发团队）
接受条件->验收测试（规范：产品负责人，产品编号：开发团队）
首先从行走骨架开始，这是一个简约的端到端（半端）。
创建MVP-最低可行产品。
使用SMURFS扩展MVP-专门销售，有用，可发布的功能集。




“如何实现”世界
/>

使用OOA / D，UML和CRC卡，但避免前期设计繁琐。
尽可能同时实现面向对象，结构化和功能化，无论
使用版本控制（最好是分布式的）。
从验收测试开始。
应用TDD，让TDD的三个定律驱使您完成“红绿色重构循环”，使用来自BDD的4 A的Single-Assert-Rule，GWT（那时提供）。 — Michael Feathers
应用SOLID和打包原则来管理耦合和内聚。
示例：SOLID中的S是SRP =单一职责原则，大大减少了编辑次数。团队中的合并冲突。
了解Demeter的规律/告诉，不要问。
使用连续集成，如果适用，甚至可以使用连续交付（DevOps）。
使用基于代码的集体代码所有权商定的通用编码标准（应该是“完成的定义”的一部分）。
应用持续设计改进（fka连续重构）。

源代码就是设计。仍然需要预先思考，而且没有人会反对一些清晰的UML图。
XP并不意味着没有一天是架构日，而是意味着每一天都是架构日。它专注于体系结构，而不是散焦，并且重点在于代码。
保持较低的技术债务，避免出现四种设计异味易碎性，刚性，固定性和粘性。
架构与业务逻辑有关，而不是持久性和交付机制。
体系结构是一项团队运动（体系结构中没有“ I”）。

设计模式，重构和转换优先级前提。
项目代码是ATP三位一体，具有以下优先级：1.自动化代码，2.测试代码，3.生产代码。
定期与团队同仁检查是否可以改善团队的交付。 （Scrum会议：Sprint回顾）
测试应首先进行-快速，独立，可重复，可验证且及时。




上面的列表肯定是不完整的，甚至有些零件甚至可能引起争议！

如果这一切吓到了您-不用担心，因为它会吓到您！在团队中成功进行软件开发项目不是一件容易的事，而且很少有人对此技术进行适当的培训和教育。如果这吓到您，您的直觉工作正常，请听。您要做好准备。与您的老板交谈，获取一些时间和培训。

另请参见


谁在scrum中编写技术性的“用户故事”

进一步阅读（在线）





波特兰模式存储库，沃德·坎宁安（Ward Cunningham）等人

罗伯特·鲍勃叔叔·C·马丁（Robert Uncle Bob）的OOD原理
实用的程序员技巧

进一步阅读（书籍）



干净的代码，Robert C. Martin
敏捷软件开发：原理，模式和Robert C. Martin的实践
实用程序员-从Journeyman到Master，由Andrew Hunt和David Thomas
有效地使用遗留代码，Michael Feathers
重构-改进现有代码的设计作者：Martin Fowler
，Joshua Kerievsky重构为模式
Steven Silbiger的十天MBA（原文如此！）
Eric Evans的域驱动设计
Mike Cohn编写的用户案例
Gray Booch等人的面向对象的分析和设计及其应用
Desig n四人帮的模式
Kent Beck的测试驱动开发
Kent Beck的极端编程
[if Java] Joshua Bloch的有效Java

#2 楼

获取敏捷

我建议以下内容：编辑相同的文件

首先，使用Git（或类似的并发版本控制系统）。只要您编辑同一文件的不同部分，就不会产生冲突。如果您确实遇到冲突，则会将其清楚地标记为此类。

在没有Git的情况下尝试管理多开发人员项目就像在制作没有布丁碗的布丁一样。有可能，但是很快就会变得很混乱。

正如评论中指出的那样，Git不是万能药，但结合自动化测试，它肯定会带来很大帮助。

列出所有功能

其次，将项目分解为用户可见的功能。例如，“当用户注册时，他们应该收到电子邮件”或“用户可以添加项目”。让所有利益相关者参与其中。让每个人都在一个房间里，让每个人大声喊叫。

这些应该是用户可见的功能，您可以稍后讨论实现策略。

在索引卡上写下所有建议，甚至是愚蠢的建议。快速合理化列表以删除重复项，然后将所有卡布置在一张大桌子上，甚至放在地板上。

添加所需的任何其他卡。假设您的应用程序将发送短信提醒。您可能不知道该怎么做，所以您有一个问题。在卡上写“调查SMS门户”。同样，对于其他任何大未知数也是如此。您稍后必须打开包装。这些功能可能不会使它成为您的第一个冲刺。

现在将您的卡片分成几组，随机洗一下，对它们有所感觉。这是您的项目范围。

计划扑克

计划扑克。仍然让所有人在一起，给所有开发人员卡片说“ 1分”，“ 2分”等，最高为“ 4分”。也是“更多”卡。一个点大约等于一个小时。

逐一浏览功能列表。读出功能时，每个人都必须打牌。如果一个人玩1，而另一个人玩4，则那里存在通信问题。一个人理解此功能意味着不同于另一个人。进行讨论并弄清楚实际含义，并在卡片上注明。

如果您同意某个功能是“更多”功能，则该功能太大。您必须分解该功能。按照与以前相同的方式进行操作。

您同意，用不同颜色的笔在卡上写上数字。

积分要好于小时数

使用点数代替小时数消除了开发人员经常从事的“看我能编码多快”的大男子主义。这是一个细微的差异，但是我发现它工作得很好。

现在构成冲刺

冲刺是朝目标快速迈进的一步。确定冲刺时间，可能是5天或10天。将天数乘以开发人员数乘以每天的积分数。

最初假设每个开发人员每天6点。这是可以实现的数字。如果您有5个人，那就是5 * 5 * 6 = 150点。与所有开发人员和管理人员一起，从列表中选择功能，最多150点。那是你的冲刺。

绝对不要试图挤入过多的东西。从长远来看，过度承诺会伤害所有人，包括您在内。

您需要在这里考虑依赖项。例如，环境设置显然必须包含在第一个Sprint中。当每个人都在场时，这实际上相对容易做到。房间里有6个脑袋，所有人都说“这取决于这个”，依此类推。然后，您可以随机播放卡片以演示依赖性。

进行冲刺后，便无法添加任何内容，并且已锁定5天。功能蠕变会给团队造成压力，损害士气并使所有人减速。最终，蠕变将使项目停滞。作为团队负责人，您必须保护您的团队免受功能蠕变的影响。如果有新功能请求，则必须将其添加到下一个冲刺中。如果下一个冲刺已满，则必须采取其他措施。

切勿试图榨取多余的东西。过分有前途让您获得约1天的满意客户价值，然后有4天的团队压力，最终很可能在团队无法按时交付几个不满意的客户。

现在去

分发卡片，问谁想做什么。您对完成的事情有完全的了解，并且可以将滴答作响的点计数为零。每天开始时都要站起来，这样每个人都知道谁在做什么，做什么都做了。

5个或6个积极进取的开发人员作为一个单元，为明确定义的可管理目标共同努力可以实现在5天的冲刺中，大量的东西。

保持可见性

确保每个人都可以看到项目的状态。将所有卡片装到墙上。左侧是尚未使用的卡。右边是完成的卡片。

当开发人员处理卡时，他们将其从墙上取下来放在桌子上。这样既可以保持可见性，又可以防止人们互相踩脚趾。

索引卡可以替代技术，但是在墙上大量显示项目状态的记录无处不在。 />
如果可能，在项目进行期间，让每个人都在同一房间。尽可能多地和利益相关者在一起，最好是每天。

Burndown

您可以在燃尽图上绘制逐渐逼近零的点。如果最适合的生产线在达到时间限制之前过零，那么您很可能会步入正轨。如果不是这样，您可能需要在太接近最后期限之前让您的客户知道。

如果您要失败，请尽早失败。

您可以使用软件进行精简，但是我更喜欢墙上的一大张纸。在其上绘制并编写所有内容。

自动测试

当您有多个开发人员同时处理同一个东西时，他们可能会破坏彼此的代码时。沟通和可见性对此有所帮助，但是您可能希望引入一些技术来帮助发现问题。

单元测试是为代码库的各个部分编写测试的过程（理想情况下）每种方法）。您的单元测试应经常运行，并尽可能进行保存。有很多工具可以帮助解决此问题，例如Karma或Rspec。

端到端测试涉及对您的项目进行整体测试，将内部视为黑盒子。这些测试基于您的高级业务需求，例如：“用户可以注册”或“用户可以看到项目列表”。量角器是端到端基于Web的测试框架的一个很好的例子。

有整本关于测试的书，但是至少进行一些验收测试可以帮助确保您不会遇到任何问题

避免技术债务并完成工作

技术债务是一个概念，它描述了以后必须清理的事情。债务的常见来源是标记为已完成但从未“完成”的功能。完成功能已签入Git，已由利益相关者批准并进行了测试。

在完成功能之前，请不要先对其进行检查。切勿按摩图表。从长远来看，这再次伤害了所有人，包括您。

这是我们最初每个开发人员每天只引用6点的原因之一。完成需要付出额外的工作，但感觉很棒，并为团队提供了动力。

#3 楼

编辑相同的文件本身不是问题。如果您编辑相同的函数以执行两种不同的操作，这只是一个问题。

基本上，我要做的是将项目划分为多个单独的“功能”。一种可能与网络协议处理有关，另一种可能与配置文件有关，另一种与数据库处理有关。功能是大事。

接下来，您要将这些功能划分为任务（故事）。
这些应该是简单的事情，例如“当用户单击按钮时，程序将加载文件”，“在程序启动时，将加载配置文件”等。

某些任务必须按顺序完成（“程序将解析配置文件中的所有字段”必须在“程序将加载配置文件”之后）。其他人则不会（您可以同时在数据库和网络上工作）。

但是很可能，您做错了，这就是经验的体现。您只会一点点（或很多）失败，错误地估计时间，并且您的项目将花费比预期更多的时间。下次您会更好。

我也建议阅读Kent Beck的“极限编程”。当我即将成为项目经理时，很棒的书对我有帮助。

#4 楼

结果是，您必须将应用程序分解为功能模块，然后在不同模块之间引入协定（接口和数据协定）。然后可以将每个模块分发给不同的开发人员。当您将所有内容放回原处时，合同将确保这些模块彼此正确通信。

确保对开发人员实施TDD，以确保所有模块都可以独立工作。

为您提供我的意思的示例：

假设您希望其中一位开发人员构建SQL记录器。

根据以下规范，您定义一个接口并询问您的一位开发人员（或者如果您使用的是Agile，则创建一个故事），您想要使用SQL特定的记录器：

 interface ILogger
{
    void Log(string message, int level);
}
 

我期望开发人员提供的内容如下：



记录器的SQL特定实现

 class SqlLogger : ILogger
{
    private readonly SqlLogRepository _logRepository;

    public SqlLogger(SqlLogRepository _logRepository)
    {
        this._logRepository = _logRepository;
    }

    public void Log(string message, int level)
    {
        _logRepository.CreateLog(message,level);
    }
}
 

任何相关代码，例如SqlLogRepository的实现
根据要求进行单元测试或模拟测试。在上述情况下（我们还有其他外部依赖项）进行模拟测试，或者例如一个简单的实用函数（例如String.ReverseCharacters(string input)），那么我只想看一下可以测试几种不同情况的单元测试。

这意味着：

您和您的团队现在可以使用此界面继续开发。例如

 class SomeModuleThatUsesLogging
{
    private readonly ILogger logger;

    public SomeModuleThatUsesLogging(ILogger logger)
    {
        this.logger = logger;
    }

    public void DeleteFiles()
    {
        logger.Log("user deleted files",1);
    }
}
 

，如果需要在SqlLogger到位之前运行代码，则可以可以简单地创建一个NullLogger：

 class NullLogger : ILogger
{
    public void Log(string message, int level)
    {
    }
}
 

这就是您可以在同时（我建议查看ICO以进行依赖注入）

 void Run()
{
    var someModuleThatUsesLogging = new SomeModuleThatUsesLogging(new NullLogger());
    someModuleThatUsesLogging.DeleteFiles();
}
 

摘要

我不知道您的项目规模，但这可能相当这项艰巨的任务，如果您以前从未做过开发领导，我建议您非常认真地对待这项任务，并在接下来的几周中花更多的时间来阅读有关软件设计和体系结构的文章。并且对您的工作（软件质量等）要非常透明，否则您将很快陷入不知所措的深渊。

我也强烈建议您阅读设计和面向对象的范例。您将严重依赖于OOP进行此项目。

#5 楼

其他答案都谈到了编程方面，但是我只想提及程序管理方面。我将从免责声明开始：我不是程序经理。我已经在研究生课程中选修了一门课程，而且我的工作经验涉及通常在500小时以下且从不超过1000小时的小型项目的竞标时间。

但是我必须帮助定义任务在一个实验室，我不得不让2-3个人忙2-4个月（兼职和全职）。确实对我有帮助的一件事是使用了Microsoft Project之类的项目管理软件（我不确定那里是否有免费版本，但是您的雇主可能也有类似的东西...向您的主管询问使用哪种程序管理软件在您的公司）。特别是，我使用了很多甘特图，这是Microsoft Project中的默认视图。通过定义所有任务以及您认为它们将花费多长时间，您可以获得可视化效果。

甘特图由于其可视化效果而对我最大的帮助。在纸上看任务对我没有多大帮助，但是看漂亮的图片和图表肯定可以。 Microsoft Project还允许您设置前身和开始日期，其主要思想是“找到任务X启动所需完成的最小任务量”。至少在我的小型项目中，“真正的”前辈的数量很少。实际上，在一个项目中，我遇到了一个问题，即几乎所有事情都可以同时完成，并且必须合成两条具有一定凝聚力的并发路径。例如。我试图确保如果开发人员A曾经接触过GUI，那么他们也将从事与GUI接近的任务。

听起来，就笔和纸而言，您已经做了很多工作，但是我总是发现实际查看甘特图真的很有帮助。查看顺序排列的任务确实让我想到“等等，任务X是否真的必须在任务Y之前完成？（到目前为止，根据我的经验，我惊讶地发现答案实际上是'否'）”

#6 楼

您似乎已经从开发人员升级为软件工程师。意识到管理工作不是设计工作，但是两者是相辅相成的。您需要管理正在完成的工作，这取决于您公司的发展方式。如果您有时间和资源，那么请考虑采用一种敏捷方法-互联网上有大量书面材料。找到一个适合您的商品，但请注意，它与其他所有商品一样都是免费的。采用任何技术都需要在成功之前进行培训，学习和失败。如果您没有足够的带宽来采用更全面的技术，那么进行里程碑计划可能是您的答案。如果您有一系列顺序任务，则可能是您找不到可并行化的序列。您也可能需要将开发划分为更多常规任务，例如测试和实施。那本身并不能解决报告问题，但是您正在管理质量。您的进度可能是顺序列表，但是您的角色是并行的。只是一个建议。映射到人们完成的工作的设计称为工作分解结构。

别人提出了很多很好的建议，但请记住您正在管理工作。有时您可以将工作概念映射到设计/体系结构中，有时则不那么容易。始终存在一种使工作结构可跟踪的方法。我建议回到您的经理那里，问他在传达项目状态时对他重要的是什么。这将开始告诉您如何处理自己的工作。如果是时间表，那么您要专注于报告进度。如果质量很好，那么您想报告一套必须要提出的指标。如果需要花费，那么您可能需要考虑一下努力。所有这些东西也可以映射到任务中或从任务中映射出来。