我最近加入了一个开发项目，突然被任命为首席开发人员。我的主要职责是将项目的编程部分分解为任务，将这些任务交给其他开发人员，然后确保各个部分协同工作。

但是问题是我不知道如何执行此操作。我花了一个周末用铅笔和纸试图弄清楚这个问题，但我不断提出要按顺序而不是并行进行的任务清单。我曾经考虑过将其拆分为功能，但是最终您需要执行需要编辑相同文件的任务，由于我们开发的早期时间，可能需要完全重写整个任务。我可以让一些开发人员等到程序更完整，更轻松地为其创建任务时，然后让人们坐下来，他们知道多少周。

我和老板就我的资格进行了交谈，但我没有选择的余地。我不知道自己在做什么，因此朝正确方向的任何提示和微调将不胜感激。

一个正确的答案可以填满几本书。我会拿出一个流行语的项目符号清单，我会想到这些，Google和书籍将为您完成其余工作。

1. 基本

   • 不要一个人去。尽量让您的队友参与进来。
   • 旅行轻巧。
   • 民主，但不要太多。有时，关乎人数最多的不是什么，而是关乎最少人数的是什么。
   • 将什么（需要完成）和如何（完成）分开。
   • 了解Scrum（“什么”），XP（极限编程，“如何”），看板（“多少”），Lean（“不”什么）和DevOps（“与谁”）。
   • 精益也与流量有关：对于整体效率而言，流量效率通常比单个效率更为重要。
   • 了解软件制作技巧，简洁代码和实用程序设计。
   • 好的架构是要使未采取的决策数量最大化。
   • Scrum / XP / Lean / Agile 旨在最大化未完成的工作量：YAGNI。
   • 软件的主要价值在于您可以轻松更改它。它做了它应该做的事情很重要，但这仅仅是它的次要价值。
   • 最好采用迭代 和 增量的方法，在几乎所有事情上都使用时间框，尤其是会议，使帕金森定律成为您的朋友，因为适用霍夫施塔特定律。
   • 通过理解康韦定律和塔克曼的团队发展阶段平衡团队结构。
   • 编程是一个四方，它同时是科学，工程，艺术和手工艺，并且需要保持平衡。
   • 仅仅因为Scrum / XP / XYZ对某人（包括我）有好处，并不一定意味着它对您有好处/适合您的环境。不要盲目跟随炒作，首先要了解它。
   • 检查并适应！（咒语）
   • 避免重复 - 只有一次！（XP咒语）又名DRY-不要重复自己又名SPOT-单点真相

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

   • 将需求作为用户故事 / 工作故事收集到产品待办列表中。
   • 用户（用户故事）相似，演员（在UML）类似假面类似角色。
   • 优化用户故事，直到他们达到您的团队基于INVEST（独立，可协商，有价值，可评估，小型，可测试）的就绪定义。（Scrum会议：待办事项细化）
   • 按业务价值对产品积压进行排序。
   • 在“故事准备就绪”（根据“ 准备就绪”的定义为“准备就绪”）之前，请勿开始编写故事。
   • 使用Planning Poker估算故事点故事的效果。使用“ 三角剖分比较”可确保估计的一致性。
   • 昨天的天气是最好的估计，希望是最坏的。
   • 如果故事太大，请分割故事。
   • 用完成的定义改善交付文化。
   • 在完成之前（根据完成的定义完成），不接受用户故事的实现。
   • 具有相同代码库的多个团队应达成共识并共享相同的“完成定义”（尤其是“ 编码标准”）。
   • 使用燃尽图检查进度。
   • 定期与您的利益相关者核对团队是否真正需要什么。（Scrum会议：Sprint审查）

3. 故事细目

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

4. “如何世界”的实现

   • 使用OOA / D，UML和CRC卡，但避免前期的大设计。
   • 无论采用哪种编程语言，都应尽可能同时实现面向对象，结构化和功能化。
   • 使用版本控制（最好是分布式）。
   • 从验收测试开始。
   • 应用TDD，让TDD三个定律通过驱动你红-绿-重构周期，具有单断言规则，4 A的，GWT（鉴于然后当）从BDD。
   • “ 单元测试是运行速度很快的测试。” -迈克尔·费瑟斯（Michael Feathers）
   • 应用SOLID和封装原理管理耦合和内聚。示例：SOLID中的S是SRP =单一责任原则，大大减少了编辑响应的次数。团队中的合并冲突。
   • 知道得墨meter耳定律 / 告诉，不要问。
   • 使用持续集成（如果适用）甚至持续交付（DevOps）。
   • 根据约定的通用编码标准（应该是“完成的定义”的一部分）使用集体代码所有权。
   • 应用持续设计改进（fka连续重构）。
   • 源代码是设计。仍然需要预先思考，并且没有人会反对一些很好的澄清UML图。
   • XP并不意味着没有一天是架构日，而是意味着每一天都是架构日。它专注于体系结构，而不是散焦，并且焦点在代码中。
   • 保持较低的技术债务，避免四种设计气味脆性，刚性，固定性和粘性。
   • 架构与业务逻辑有关，而不与持久性和交付机制有关。
   • 架构是一项团队运动（架构中没有“ I”）。
   • 设计模式，重构与转换优先前提。
   • 项目代码是ATP三位一体，具有以下优先级：1. 自动化代码，2. 测试代码，3. 生产代码。
   • 定期与您的团队同仁检查是否可以改善团队的交付方式。（Scrum会议：Sprint回顾）
   • 测试应该是第一项 -快速，独立，可重复，自验证且及时。

上面的列表肯定是不完整的，甚至有些部分可能有争议！

如果这一切让你害怕-不要担心，因为它应该吓唬你！在团队中成功进行软件开发项目并非易事，而且很少有人对此技术进行适当的培训和教育。如果这使您感到恐惧，则您的直觉工作正常，请倾听它。您要做好准备。与您的老板交谈，获取一些时间和培训。

也可以看看

• 谁在S​​crum中撰写技术性的“用户故事”

进一步阅读（在线）

• Ward Cunningham等人的《波特兰模式资料库》
• 罗伯特·“鲍伯叔叔”·C·马丁的OOD原理
• 实用程序员技巧

进一步阅读（书籍）

• 罗伯特·马丁（Robert C.Martin）的清洁代码
• 敏捷软件开发：罗伯特·C·马丁（Robert C. Martin）的原理，模式和实践
• 务实的程序员-安德鲁·亨特（Andrew Hunt）和戴维·托马斯（David Thomas）从《旅人》到《大师》
• 通过迈克尔·费瑟斯有效地使用遗留代码
• 重构-改善Martin Fowler的现有代码设计
• Joshua Kerievsky对模式的重构
• 史蒂文·西尔比格（十大MBA）
• Eric Evans的域驱动设计
• Mike Cohn应用的用户故事
• 面向对象的分析和设计及其应用by Gray Booch等
• 四人帮的设计模式
• 肯特·贝克（Kent Beck）的测试驱动开发
• 肯特·贝克的极限编程
• [如果是Java] Joshua Bloch撰写的有效Java

敏捷

我建议以下内容：

编辑相同的文件

首先，使用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天的冲刺中实现大量的工作。

保持可见度

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

当开发人员处理卡时，他们将其从墙上取下来放在桌子上。这样可以保持可见性，并防止人们彼此踩到太多脚趾。

索引卡有替代技术，但是在墙上大量显示项目状态的文档无所不能。

如果可能的话，在项目进行期间，让每个人都在同一房间。尽可能多地和利益相关者在一起，最好是每天都有。

烧掉

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

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

您可以使用软件进行精简，但是我更喜欢墙上的一大张纸。画并写在上面。

自动化测试

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

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

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

有很多关于测试的书，但是至少进行一些验收测试可以帮助确保在进行项目时不会遇到任何问题。

避免技术债务并完成工作

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

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

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

编辑相同的文件本身不是问题。如果您编辑相同的功能来做两种不同的事情，这只是一个问题。

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

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

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

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

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

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

确保对开发人员强制执行TDD，以确保所有模块均单独工作。

给你一个我的意思的例子：

假设您要让一名开发人员构建一个SQL记录器。

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

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

然后，我期望开发人员提供以下内容：

1. 记录器的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);
       }
   }

2. 任何相关代码，例如 SqlLogRepository

3. 根据要求进行单元测试或模拟测试。在上述情况下（我们还有其他外部依赖项）进行模拟测试，或者如果它是例如的简单实用程序功能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。

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

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

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

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

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

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