未来从一个人的项目转移到一个团队项目。我现在应该做什么准备，还有什么可以等待？

Question

为了详细说明，我感兴趣的是，当仍然是一个人的项目(团队源代码管理、文档、构建等)时，我想知道人们认为您需要做什么，以及在第二个人进入项目之前不需要做什么。

任何有过这种经历的人，他们的洞察力都会受到赞赏。

Answer 1

我学到的东西。)我尝试了另一种命令。我错了。这就是事情变得相关的顺序。)

1. 将所有内容放入源代码控制中。使用每个人都能接触到的东西，现在就开始。没有例外。没有延误。别找借口。
2. 创建一个与个人“工作”或“开发”环境完全独立的QA/测试区域。至少有一个单独的用户id。理想情况下，在单独的VM上。完全分开。不可能与您当前的工作环境重叠。
3. 停止在您自己的工作环境中进行单元测试以外的测试。代码和单元测试你做的“你自己”。在单独的VM上所做的所有其他测试(集成、性能等)。永远不要像你自己一样测试。始终作为单独的QA用户进行测试。理想情况下，在单独的VM上。“为我工作”是一件坏事，不得不对你的团队成员说(S)。非常糟糕。你得弄清楚他们做错了什么。一天几次。
4. 计划把一切都写下来。使用纯文本标记工具(RST或Markdown等)，以便所有文档都是版本控制存储库中的纯文本。工具可以创建HTML页面(即用于RST的Docutils )、PDF或任何看起来最好的东西。不要使用专有文档格式(即MS-Word)。他们可能在某些源代码控制系统上玩得不好。
5. 您需要写下的第一件事如下。
   • 如何创建工作开发环境。当有疑问时，创建一个虚拟机并在该虚拟机上执行整个操作。确保这些步骤确实有效，并且文档是清晰的。在实际命令行输入的实际行比较清晰。
   • 如何运行单元测试套件。再来一次。确保指令有效，不需要思考。“输入这个：”“确认：”之类的东西。不是说你的团队成员很蠢。这是因为除非你把所有的东西都写下来，否则你不记得你所假设的是什么。
   • 如何运行集成测试套件。

不要浪费大量的时间来描述架构或设计原则。你得先找个人跑起来。你以后再解释吧。

1. 接下来要记录的是用户故事。以及支持这些故事的测试用例。以及支持这些用户故事的测试用例所需的数据夹具。你将分享这一切。它处于源代码控制之下。
2. 最后，您可以记录其他4个视图。
   • 逻辑视图是文档化的有用工具。这里是可以接受的。这往往会迅速发展，所以不要花时间捕捉遗留信息。想出一种与你的团队成员(S)合作的方法。
   • 过程视图通常是有用的。这取决于整个应用程序的重要性。
   • 开发视图--模块、库、框架等--经常被非正式地描述。一张图片可能会有所帮助，但众所周知，要让它足够完整，以至于有人能够拿起一份文档，并对其做出正面或反面的判断，是非常困难的。即使是由来已久、非常公开的项目也有被忽视的库文档。(导致大量堆栈溢出问题。)除了可接受的非正式做法外，这种情况往往会迅速改变。
   • 部署信息。服务器。IP地址。数据库凭据。所有的东西都要写下来。最终会的。

Answer 2

工具和方法

成功地合作和富有成效需要什么？

• 确定项目的部件/组件:明确区分不同的部分(数据库、数据访问层、网站、服务、API、测试项目、构建脚本、.)和环境(开发、阶段、生产)，以及始终如一地命名它们会对口头和书面交流产生影响(文档、项目名称、.)
• 使用源代码管理系统(以防您还没有)。考虑如何在项目和设置中使用分支。
• 自动化您的构建-使从您的源存储库设置环境尽可能容易。
• 在大型项目中，测试项目是必须的，至少对于更复杂的项目是如此。
• 使用准备使用项目的暂存环境(S)。此外，为自动分阶段设置创建和维护示例数据。
• 使用一个bug跟踪系统，它可以帮助确定开发的优先级和计划，还可以作为过去错误的记忆以及它们是如何被解决的。
• 记录项目的每个部分，有些部分比其他部分更多。我个人喜欢:概述-架构-依赖-配置-常见问题(来自这里)。有时候，少就是多--为了不让你的文档过时，最好是简明扼要，让文档成为你日常活动的一部分。

管理/团队合作

..。或者其他的人际层面的东西

• 定义您对其他开发人员的期望。理智点，没有人会像你一样投入和激情--至少从一开始就不正确。沟通你期望的和不期望的，明确你和另一个人的责任。并不是每个人都是工程师、架构师、开发人员、dba和sysadmin，但是如果这就是你想要的，那么选择合适的人，否则你会失望的。
• 首先，精确地定义任务，并回顾和讨论结果。渐渐地，开始越来越少的微观管理。这样做的目的是建立信任和增加责任。
• 计划你的项目，为你的项目和下一年为你的团队设定目标。把它写下来，稍后再检查它，这会给出一个透视图。这些目标可能会也可能不会传达给别人(只要它们是你需要实现的目标，而不是其他目标)，它可以只是你自己的清单。
• 花一天时间准备和计划新开发人员的第一个月(或两个/三个月)。我发现和有充分准备的人一起工作时，这是非常有动力的。没有人会有浪费时间的印象。
• 放手。这是你的孩子，也应该是别人的。让另一个人成为一个比你更好的专家，至少在项目的某些部分。这意味着你成功了。
• 听着-如果你雇了她，她有话要说。准备好学习。
• 准备好分享你的知识和经验(因此要耐心等待)。
• 错误是会发生的，它是如何处理它们的，也是每个人都在学习什么才是重要的。
• 有时间学习和实验

图书参考资料

我会列出一些我实际上读过的书，我认为值得一读，为了更详细的描述或者更多的书，你可能想要查看一些问题，所以问的正是这些问题，比如这或这问题。

关于团队、组织和编程项目，这些书确实值得一读：

• 人器
• 神话中的男人月
• 软件评估，揭开黑色艺术之谜

所有这些都不是关于如何实现方法学X的实用指南(除了软件估计之外，这本书帮助您选择一个适当的评估过程)。当然，更多集中于编程本身的书籍，如代码完成，也非常丰富。

Answer 3

我会从经验中说出来，但要记住，每个人都是不同的。这些东西并不是普遍的。

有一件事是让它亲自去。这个项目是你和你一起生活了18个月的东西--你很自然地希望每一个改变都像你所做的那样。给同事一个缓冲，让他们犯错误，去学习。为他们创造一个有用的空间。记住，这可能不会马上发生。此外，如果有什么东西，代码的一部分，他们可以感觉到他们成功地改进或创建，这将是很好的感觉，在短时间内成功。耐心和宽容在这里有很好的回报。不要试图微观管理，如果你想批评，说“你错了”，确保你有一个优点，你可以证明，这不是一场“宗教”斗争。

另一个关键问题是为你找到合适的人。理想情况下，最好是找一个比你聪明的人。这是主观的和相对的，但是如果你觉得一个人有一些你没有的知识和技能，那是最好的。这将是一次互惠互利的合作。

它可以有两种方式--这位同事将是个累赘，你最终会重做他或她做过的事情，或者你们两个的技能会成倍增长，而不仅仅是加起来，你们会真的很感激一起工作。

关于“干净、快速、可重用的代码”--我建议在面试时，要求编写一个小型的微内核/服务经理和/或作业执行者。请参见如何指定和配置可插拔组件。不一定要完成，这是一个很重要的想法。而且你很快就会学到那些知道怎么做的人会想要像样的钱;-)祝你好运！