讨论：关于团队的技术栈和项目管理工具选择

TA-KumaXX 2023-03-07 13:54:16

大家在开始团队开发之前或许都有类似的疑惑：如何选择团队的技术栈？如何借助合适的工具帮助团队进行项目管理？ 让我们在真正开始开发之前为了之后的轻松和顺利进展一起来思考和讨论这个问题。

以下是 TA🐻 和来自本届 MOSS 队的 PM🐟 于敬凯同学前些天的交流、以及 MOSS 队的实践结果。以我们不甚全面的考虑作引，希望大家也能在评论区分享你们的思考和实践。

1. MSG from 🐟

2022/02/25 MOSS-于敬凯

助教好~ 俺这几天突击把教材读完了，也读了助教去年团队博客特别是前几篇博客，俺现在有这样几个问题，如果助教什么时候方便的话回答就可以，我不急~

工具问题

助教去年的总结博客提到过，“ 由于团队（尤其是后端）在自动化工具上采用了高标准和最优实践，BUG 的出现大大减少，代码统一且高质量，为平台的稳定性提供了充分保障”。

我注意到助教去年的硬件和技术栈有腾讯云，微信小程序、HTML+CSS+JS+Nuxt.js、Django（Restful）、PostgreSQL，软件上还有 nginx 等，其他技术还包括 GitHub Actions、Docker、Notion 等（我说的肯定不全）。

我的问题是，请问这些具体技术的选择与比较该如何进行呢，该如何结合团队成员本身的技术栈以及当前流行或者最佳实践来选择合适的技术和框架呢？特别是当大家很可能有不一样的地方，这个时候往往会出现大家都尬住没人愿意做决定，那么该如何尽早确定好这些基本工具呢（作为 PM）？或者说，助教经过去年的软工有什么经验之谈吗？

我个人比较希望尽早推动这些基本技术的选择和确定，让大家在正式开工前对工具有初步的了解，不知道我的这个想法如何呢？

项目管理工具

助教团队去年使用的是 notion，我调查了一下了解到这是一个很不错的笔记工具，很多为开发者设计的功能。

但是我面临这样几个问题：

首先是学习门槛，这个工具似乎不是很容易上手，有一定的学习曲线，如果队友不是对这个软件很感兴趣，可能学习使用起来积极性很低，最后退化到使用微信控制进度。
然后是新工具的推动，我曾在 OO 助教团队中试图推广飞书作为工作交流工具，但是后来遇到种种问题导致基本弃用，但是我本人很喜欢这种能够高效管理团队进度的工具，我们该怎么推动新工具的使用呢？
再然后是选择问题，我了解到 notion 每人每月需要五美元，可能并不是每个团队成员都愿意付出这样的成本，那有没有其他的平替或者下位替代工具呢？飞书等工具是否有类似的效果呢？

作业时间节点

今年的各个博客作业时间节点似乎比去年有所前移（特别是团队的），想请问助教有没有推荐团队在早期（比如我们现在只有队伍和分工但是没有确定需求等其他所有工作）尽早讨论和确定的工作呢？

问题有点多，描述也比较啰嗦，非常感谢助教！！

2. MSG from 🐻

2022/02/27 TA-KumaXX

谢谢你问我，还去翻了去年的文档！
那我回忆下去年的流程，再加上一点事后回顾的感想，说得不一定对喔不能算解答只能说是一起讨论！

关于技术栈的选择

关于第一点，我想你问的是技术栈选择。

我们先是一个人出一个提案，内容大概是简化版的 NABCD，主要考虑需求本身、亮点功能、难点和可行性，然后线上先投票和提出问题，过了几天收集完意见了再开会讨论选题。初步定题之后大概要做什么就心里有数了，再来考虑技术栈。

首先，肯定是要写一个 WebApp，自然的考虑是前后端分离来做。对着大致的需求估计工作量，大家按技术熟悉程度和分前后端两组，然后分组统计大家熟悉的技术栈。以我们去年的状况来说：前端三人大家都熟悉 Vue，于是很顺利地决定基于 Vue 去构建；后端有三位熟悉 Django，三位熟悉 ROR，还有零散地熟悉基于 Node 的框架、Java 的 SpringBoot 等等......这下就来到了比较你所提到的“尬住”的情况，怎么选择技术栈呢？

那么以后端为例，我们最后的决定是按这个顺序来思考然后做出的：

框架能否适应需求，不能确保需求实现的技术当然不适应于【完成产品】的目标：我们对于所有候选框架，请最熟悉的那位同学考虑和解说了一下能否覆盖、以及如何实现我们初步考虑到的功能点。事实上对于现今早已成熟的各类框架来说，基本上我们想到的需求里没有什么不能做或者不好做，在这个层面上每一个候选都没有问题。
考虑熟悉该候选框架的开发人员数量，这个和人员培训的难度相关：更多人熟悉的框架，需要做的培训工作更少，选择的成本更低。基于这一点，我们会从 Django 和 ROR 中来选。
到这一步还是很难抉择：三对三，总有一位成员要从入门（虽然成本在预想范围内）开始，而考量成员培训的成本，可以说很难去量化哪一个更大。这时我们考虑到的方向是：组织开发的效率。我们请对于两个选择分别最熟悉的那两位成员，从“你现在主管后端开发”的角度来考虑问题，谁对【工作量/成本（比如说配置自动化是否方便、能减少哪些工作量）、会有多少、工期如何规划、如何分配任务和安排成员工作（包括培训）、潜在风险和解决这些风险需要投入的资源】这些问题更心里有数，我们就选择 TA 所代表的框架——事实上，也同时选择了 TA 作为总领后端开发的人选。

好在我们在这一步就得出了答案。决定技术栈不仅是决定实现阶段所采用的技术，也和需求分析相互动要体现需求分析得到的信息，同时还关切到团队开发很重要的方面：组织工作的形式——人选择技术的同时，也在依据技术选择人。

上面这样的决策方式在我看来是比较能解决【团队如何选择技术栈（而不仅仅是【如何选择技术栈】）】这个问题的。

关于项目管理工具的选择

关于第二点，关于项目管理工具。

我个人的想法是：工具在进步、进步的方向往往基于各种各样言之有据的方法论，选择工具也是选择一种方法论和价值观。

我举个例子，对于团队沟通，大家一般会觉得 QQ 等 IM 较之一些比较成熟的团队沟通工具例如 Slack、飞书等等会比较“粗糙”，例如说没有话题汇总的功能、沟通没有办法很好地绑定到工作任务上等等很多功能上的缺失——你会发现我们在谈论这些问题的时候，“选择某种工具的话，我们会缺少什么能力”这种叙述方式，其实是预设了一套隐含的工作模式，这种工作模式是某种具体的工具（或者如宣传时他们的用词：团队工作流/解决方案）所赋予我们的。如果按照这种叙述方式去讨论，可能我们会觉得每种工具有每种工具的好（与坏），就不太好做出选择。因此我们一定要落到最根本的问题来：作为团队的【我们（而不是某一个人、或者某一种工具所代表的工作流）】，到底需要什么？

我来回顾一下去年我们的情况：

沟通上，线上大家会比较经常进行一些零散的讨论，我们喜欢开线下会面对面交流某个特定议题。

我们在沟通上面临的问题是：线上的讨论虽然实时而且随时随地，但可能会“太过于散”，信息密度低，留下来的记忆太薄；线下讨论机会会比较少，而且需要控制时长保证高效。

我们是这样面对这两个问题的：对于线上沟通，PM 会稍微规范一下讨论的形式和流程：例如谈选题，我们分成提出提案、提案商讨、表决三个步骤，在线上沟通。提案要求每个提案形成完整的一段表达，这段表达是 PM 先发一个模板大家按模板来考虑统一的几个方面填进去；对于一个想法，没有人来规整出一个比较完整的考虑我们就先不开始商量这个选题；选题表决会用群投票，明确有 Due。有这样充分利用零散时间的思考之后，我们再来做线下的专题讨论做出决定，并且要把大家的讨论结果形成完善明确的会议纪要。

根据这样的流程我们再去选择工具，这样考虑之后我们会发现线上沟通选择 QQ 就已经足够了，其实无需引入其他工具。

对于文档管理，就没有像考虑沟通方式那样大家都有明确的认识和共识，这会儿就需要团队投入精力来考虑了，我们团队的选择是把这个投入交给 PM。作为 PM 我有去调研目前比较好的团队文档管理实践，最后选择了数据统计、协作编辑、信息组织和呈现形式都比较合适并且扩展性好的 Notion。从需求调研阶段收集用户采访报告、记录会议纪要、甚至是协同编辑完成作业要提交的文档，到形成开发规范、任务分配和进度管理、乃至像一个公告板一样做某些信息的汇总和备忘（例如收集各项支出的发票并且记账算账），我们选择的 Notion 都能满足需求，那么我想我们可以认为这个选择是一个正确的选择。

文档管理事实上就是建立和维护团队公有知识库的过程。必须要指出，课程要求提交的只是很狭窄的几个方面，维护好文档的主要目的当然不应该仅仅是完成课程的要求。

关于成本，我很认同你考虑的方式。其一是人员培训的成本，我们的实践结果是：一个人先了解最佳实践，再进行团队培训，好过大家一起摸索；其二可能是物质上的成本。去年两个多月的开发流程中：最开始一段时间是试用期；其后第一个月是提出这个提案的成员（......呜呜别让我想是谁了心疼钱钱）在外面打黑工赚钱出的费用；第二个月大家试用了石墨、腾讯文档等其他选择感受到了对团队工作流帮助的差异，并且考虑到大家都比较习惯且已熟悉使用这一工具，就决议分担开销继续使用 Notion 进行文档管理。

去年冯张弛助教的团队使用的就是 Coding 来组织他们的工作流，我想你也可以询问他获得一些经验。

关于作业的发布时间

最后是第三点问题，发布时间有所前移、提供大部分文档作业的预览版等等今年课程的变化，正是为了鼓励大家更早地做多方面的准备，进而提供同学们更高的自由度、适应大家各自不同的步调。作业和其他任务在总时间上事实上是要比往年宽松的，大家可以不用担心做不完，但是据我们的经验，按照作业发布的步调早开始、早思考、早准备，当然能获得更好的课程体验。

3. MSG from 🐟

2022/03/04 MOSS-于敬凯

我们刚开完第一次会议，我正好结合助教的回答、我的调研、团队的思考和决策逐条 feed back 一下。以我们开展工作的时间线展开回复。

调研顺序

首先，在面对开发技术栈和项目管理工具这两个问题时，我决定先解决项目管理工具，再解决开发技术栈，这样有利于初期即开始良好的文档管理，并且可以在调研技术栈的时候即逐渐在实践中使用该工具，以便在正式项目中更熟练地使用。

项目管理工具

这个问题其实也是工作流的子问题。

方法论、价值观与应用场景

我们既有“磨刀不误砍柴工”的哲学思想，这表示初始即确定趁手的工具十分重要，可能起到事半功倍的效果，比如用 devc++ 开发大型 cpp 工程显然不如 VS；我们也有“不要沉溺于工具”的哲学思想，酷炫的 IDE 们自然很帅，但是重要的是开始写代码的时刻，纵使安装有 IDEA，Eclipse，VSCode 以及 Atom 等等酷炫的工具和环境，不写代码依然==0。

因此，我们的调研思路是，结合工具的特点、人的特点、过去工作/项目的经验，尝试设想【真实的场景和需求】，而非被创造的需求。市场上相当多的产品为我们描述了美妙的工作场景以及他们解决方案的优雅和高效，但是问题是，【这是我们需要的吗？】。

失败的案例

这是一个反面案例，可以佐证上述分析。

在 2023 OO 助教团队中，我由过去的了解和试用尝试推行飞书（lark）作为工作软件，当时设想的场景是沟通在飞书、文档在飞书、工作安排在飞书、会议在飞书，试图用飞书+ gitlab 完成一站式工作流，并且分割工作和其他部分的生活和学习，以达成某种 work-life balance 的哲学。

然而，实际应用上，出现了不少问题。无论是微信和飞书在交流上的冗余性、 gitlab 和飞书在文档上的冗余性还是腾讯会议和飞书在开会上的冗余性，都导致了尽管飞书确实提供了一站式方案和美好的工作场景设想，但是大而全并不是足够让人迁移的动力。也就是说，在这一环境中，我们被飞书创造了需求和场景，而这是有很大偏差的。

软工的调研

我们设想了两种工作流，并对工作流和其中部分工具进行投票表决。

方案一

代码托管平台：GitHub
部署：GitHub Actions + 云服务器（可能选择腾讯云等提供商，已经有过成功案例）
即时通讯：微信+腾讯会议（进行碎片化的、快速的沟通）
【待确定】文档管理（公共知识库）：notion /飞书（工作场景包括数据统计、协作编辑、信息组织、公共作业完成、开发规范、任务分配、进度（看板）管理等）

对于其中的 notion 和飞书，我们也分析了如下优缺点：

notion
- 优点：有成熟的实践；是类似软件系统的鼻祖；界面清晰简单；对markdown有很好的支持；看起来很牛，逼格很高。
- 缺点：某些功能受限，可能需要付费（参考价格：每人每月 5 美元）；服务器在境外，网络连接慢/波动；没有官方中文，只有社区开发的中文油猴插件（体验了一下还可以）；有网页版，没有手机 app。
飞书
- 优点：由字节开发的仿照 notion 的软件，功能基本齐备；免费；服务器在境内，访问快；支持中文；有手机 app。
- 缺点：页面较复杂；桌面端是阉割版，文档编辑等会跳转到网页，网页端功能最全。

方案二

腾讯云 Coding 提供的一站式敏捷软工解决方案，包括完整的标准化生产线；项目协同（工作流）；代码托管（ coding 自有的基于 git 的仓库，也可以导入 GitHub 仓库）；DevOps（ coding是腾讯云的子品牌，可以方便地对接腾讯云服务器）；有免费版，但可能需要付费可以取代的上述的服务：1.代码托管平台；2.部署；4.文档管理（公共知识库）

分析与表决

方案一是我们尽可能少地增加新工具，而是整合目前大家熟悉的、过去有过成功案例的工具包括 GitHub、GitHub Actions、微信、腾讯会议。唯一可能对部分同学不熟悉的工具是 notion /飞书，这是服务于软工项目特点的新工具，具有引入的必要性。这意味着，我们用类似 MIPS 的哲学思想，整合了经典场景的最佳实践方案（此处的最佳综合考虑了工具本身、大家的熟悉程度以及使用和学习门槛）。

方案二是一套完整的工作流解决方案，好处在于一站式，缺点即是每个细分场景都要迁移到该工作流中。虽然如代码托管平台的界面和功能等与 GitHub 高度相似上手容易，但是难免容易使人产生厌烦和抵触心理，同时学习和使用该工作流的很多细节服务成本较高，不一定容易推行。

最终表决结果是，采用方案一，并且文档管理使用 notion，尽可能少的 push 大家做出改变和学习。

需求分析和技术栈

这一部分调研和讨论正在进行中，先描述我们的思路。

首先，我们应当先确定需求，再根据需求和大家的实际情况确定技术栈。

需求分析

拟采用 NABCD，让队友单独或多人一起提出一个需求和方案，并在调研过程中收集意见，最后集中讨论确定选题。

技术栈

首先考虑的是框架能否完成需求，不能完成需求的框架应当直接被排除，这一部分工作由对各框架熟悉的同学完成。
对于前端（后端）同学都熟悉的技术栈，直接确定，没有问题
对于前端（后端）同学熟悉的技术栈交集为空时，由各同学对自己的技术栈进行调研，考虑以下方面：
- 学习成本和学习曲线
- 若选择你熟悉的技术栈，你是否能够带领其他同学较快入门
- 工作量/成本/遇到问题时是否可以在网上找到解决方案或详实的文档
- 是否有成功案例 etc.

...全文