共计 1870 个字符，预计需要花费 5 分钟才能阅读完成。
不同的软件开发团队做事格调迥异，即便在企业外部，团队与团队之间也存在诸多差别。作为一名软件工程师，和新的搭档一起工作、开发新的软件通常是件令人兴奋的事件，同时他们还应思考很多问题。最近，软件工程师 Thomas Stringer 就从技术、合作、内部、产品多个角度进行了剖析。
技术
1. 如何在本地构建软件？
这是你应该学习的第一件事。毕竟，对于开发和运行软件来说，构建是第一步！
2. 如何在本地测试软件？
CI pipeline 对于纠正测试谬误十分有用，同时它还能够缩短外部开发循环周期，确保测试顺利进行，同时查看回归。该 pipeline 不应成为创立或导致测试失败的首个迹象。
3. 如何设置开发环境？
团队文档应对此有明确要求。此外你还应理解在开发机器上要应用哪些不同的工具，以便使本人成为团队的生产者。一次性设置好环境来解决 95% 的需要，要比在开始开发后遇到谬误和 gradle 依赖好得多。
4. 源代码在哪里？
通常状况下，在新团队中你将在一个事后存在的代码库中工作。因而，你须要晓得代码在哪里，如何在本地机器上获取代码。
5. CI/CD pipeline 在哪里，它是如何工作的？
心愿你能退出一个确保交付产品质量的团队。最常见的工具之一是 CI/CD pipeline。找出它的地位，并简略理解其工作原理，查看最近的一些运行，理解曾经进行的步骤。
6. 产品 backlog 在哪里？
你面临的是软件的以后状态，但最好先理解其将来状态。疾速浏览 backlog，查看产品行将推出的一些优先事项。
7. 预生产和生产测试是如何进行的？
新团队有集成环境吗？团队用 canary build 和部署来进行测试吗？团队是否引入混沌工程？你须要理解新团队如何确保其生产软件放弃在特定规范。
8. on-call 以什么模式进行？
这款软件须要 on-call 吗？如果是，怎么轮换？事变产生频率是多少？on-call 是否有非工作工夫要求？当我执行 on-call 时，如何失去告诉？通常在你退出新团队时不会立即开始 on-call 轮换，因而随着工夫的推移，你能够在执行 on-call 前失去一些答案。
9. 外部文档在哪里？
新团队在哪里保护外部文档？是最新版吗？
合作
10. 团队中的每个人在关注什么？
软件团队通常有多名工程师，理解团队中不同程序员的关注点是不错的做法。
11. 团队每周的节奏是怎么的？
有每日站立会议吗？须要每周签到（weekly check-in）吗？你须要理解新团队的“典型”一周是什么样子。
12.“初学者”问题该向谁发问？
退出新团队后，你通常会被调配一个“入职搭档”——一个晓得事件如何运作的团队老人。这是一件十分有价值的事件，尤其是在你对新软件简直无所不知、提出的问题十分高级的状况下。这很失常，提出初学者问题并不丢人，即便你是高级工程师。
13. 谁来驱动新性能？
这款产品是否有产品经理？团队中有架构师与工程师协同工作吗？你须要理解个性申请的上游源头。如果能抽出工夫和这个人（或这些人）理解产品的近期和远期前景就更好了。
14. 团队如何沟通？
新团队应用 Slack 或者 Teams 吗？还是大部分异步通信通过电子邮件实现？工程师们通常终日都在议论问题或进行其余类型的探讨。作为团队中的新成员，你须要理解这些沟通渠道。
内部
15. 如何取得客户反馈？
这是 GitHub 上的开源软件吗？GitHubissue 是咱们取得反馈的形式吗？还是有销售团队作为从客户到产品团队的代理人？咱们能够从不同的反对团队处收集常见的客户痛点吗？换句话说，你须要理解新团队如何取得用户反馈，无论是通过另一个平台、集体还是团队。毕竟，咱们是为用户编写软件的。
16. 咱们对客户有哪些反对协定？
咱们是否必须恪守 SLA？咱们反对什么样的用户场景？
17. 公共 / 客户文档在哪里？
这是一个重要的问题。不论软件有多好，客户文档都应该是精确和最新的。你须要理解在哪里浏览这些文档，文档如何放弃最新，以及谁对此负责（心愿答案是“所有人”）。
产品焦点
18. 软件的高级痛点是什么？
你须要理解软件和团队是否正在解决一些大问题。是不是某些架构问题导致了其余问题？是否存在可利用的安全漏洞？是否有常见的客户问题一直呈现，并须要解决？
19. 利益相关者的关注点是什么？
软件的某些个性是否是要害集体或其余团队心愿看到的？通常，这些利益相关者会对软件的短期和长期路线图产生重大影响。理解他们的关注点有助于设想软件的将来路线。
20. 软件的公布周期是什么？
你还须要理解软件公布的频率和工夫节奏。团队是否每天继续部署屡次？还是一年两次公布？理解软件公布时间表能够让你对软件开发节奏有一个很好的理解。
