我的团队很小，有些新（不到3岁）。他们缺乏：
定义良好的软件开发/工作管理框架（例如
scrum）
强大的产品所有权
定义明确的角色（例如，业务人员将进行手动测试）
定期例行会议
一个合并的问题跟踪流程（我们有一个工具，该流程仍在开发中）
一个单元，系统，回归或手动测试套件或列表
有关业务逻辑和流程的文档
用于记录内部和面向客户的提示的知识库
，清单还在继续。只要价值是合理的，管理人员就可以实施改进措施，并且可以帮助完成最重要的工作（即开发）。但是，基本假设是您必须在实现中拥有所有权，因为没有人会为您做这件事。不用说，上面的一些项目是不平凡的，无疑是很耗时的，而且显然不是开发工作。
（初级）开发人员尝试随着时间的推移努力实现上述目标值得继续？还是最好“随心所欲”并专注于开发，将大部分流程定义和优化留给管理人员？
#1 楼
到目前为止，答案很好，但并不能涵盖所有基础。以我的经验，许多刚从大学毕业的人都拥有出色的理论知识-远比我或拥有数十年构建软件的许多前辈更好
但是，但那是一个很大的问题，知识并不以任何实际情况为基础。在现实世界中，很多理论都趋于平庸，或者至少必须采用大量的盐，因为在实践中发现这种盐在现实世界中不能很好地发挥作用。
这是一个很棒的软件设计。
可悲的是，这导致了生产和维护的噩梦。代码库是如此庞大和复杂，以至于无法更改位置。不是因为它特别脆弱，而是因为它是如此复杂，所以没人敢触摸它，因为它会担心会发生什么（原来的建筑师/设计师是一个很久以前就已经离开的承包商）。
它正是由于模式的多层结构以及设计所需的类库，它们的性能也非常差。例如，单击屏幕上的按钮以对数据库进行一次调用将导致数百个对象实例化和方法调用-都是以确保松散耦合之类的名义进行的。
建筑师曾是大学教授，以他的名字写过几本有关该主题的书。他从来没有在商业项目上做过一天的程序员。
具有构建软件的实际经验的人们会意识到，设计不可避免地会导致怪异的现象，并采取更加务实的方法，从而导致一个易于维护且性能更好的系统。
同样的事情可以适用于您在应届毕业生或任何公司的新员工中遇到的许多其他事情。不要以为您的理论基础会告诉您什么是错误的或次优的，所以不要以这种方式来完成它是没有充分的理由的。
即使现在，拥有20多年的经验在该领域，我对批评与之合作的公司的工作方式持谨慎态度。我会顺便提及，我注意到事情与我的最佳经历有所不同，但不是好战的。关于这些事情为什么如此，通常会引起有趣的对话。也许会发生改变，也许不会发生，这取决于改变事物的价值是否小于成本。
不要害怕暗示事情可能会做得更好，但请始终确保不要这样做并不是一个无所不知的孩子，而是一个正在努力并且愿意不仅学习而且还帮助改善公司发展过程的同事，而不仅仅是理论上的正确性。
评论
我完全同意你的看法。到目前为止，实践是了解行之有效的最佳方法，即使如此，总会有更多的东西。
– Kain0_0
19年1月9日在5:31
如果一个项目异常复杂，难以更改，那么它就不是“软件设计的奇妙作品”。
– Steve Chamaillard
19年1月9日在7:25
这个答案听起来像是面向对象编程（OOP）是学术界所痴迷的知识体系，而该行业则“知道得更好”。以我的经验，这是另一回事：学者对OOP不太在意，而许多公司仍然对OOP着迷。学术界倾向于用更多的永恒但晦涩的概念来关注自己（其价值通常需要数十年的时间才能被业界所认可）。
– Theodoros Chatzigiannakis
19年1月9日在9:26
此外，期望高级工程师对时尚保持警惕。
–吴宗宪
19年1月9日在10:09
“这是一个很棒的软件设计。可悲的是，在生产和维护中，这是一场噩梦。”第二部分意味着第一部分是不正确的。按定义，好的设计可以使软件更好。如果该理论实际上不起作用，那么该理论就是错误的，遵循它是一个可怕的想法。
– jpmc26
19年1月9日在10:28
#2 楼
是的，但要格外小心！让我澄清一下。
您应该努力提高软件的可居住性。如果您查看代码/团队/业务/项目/管理，而您的第一反应是洗个澡，那是不适合的。如果您的第一反应是大声喊叫...，然后当您因草皮离开办公室而抱怨时，则需要使您的房屋更宜居。这是一种感觉，您会知道的。
话虽这么说，您正在从事复杂的演奏。您所做的任何事情都可能出错，并且至少在短期内可能会使情况变得更糟，因为简单的更改会产生连锁反应。因此，首先要变得谦虚，我并不是说要推翻或接受事情一定很糟糕，我的意思是要接受这样的事实，即您的良好意愿会恶狠狠地打扰您。
问题
怀着最好的意图，您可能会觉得需要进行广泛的变革，我并不不同意这些情况的确存在，但请花一点时间考虑一下。当前的系统正在运行，您和您的团队正在生成代码，也许是缓慢的代码，也许是痛苦的代码，但是它正在运行，并且大家都具有执行此操作的经验。您大致知道会发生什么，总之，您是该系统中的从业人员。
进行了大刀阔斧的变革之后，除了实施者之外，没人知道会发生什么。简而言之，在系统的这一部分，每个人都被重置为新手级别。这不好。新手必须学习需要时间的新规则。在那个时候，新手正在犯错误，因为他们没有实践。这些错误已成为系统的一部分，您现在必须忍受它，而且现在还没有那么闪闪发光。
前进之路
有时，斜线，刻录和重建是您所能做的最好的事情。如果没有人在旧系统中实践，那么它特别有吸引力，因为唯一丢失的是已编码的知识。如果这种知识是完全不可理解的，那么它已经丢失了，并且重新开始是唯一的选择。相反，如果编纂方法或其使用方式有问题但可以起作用，则该知识仍可访问，并且可能值得保留，也许不值得-只是不要轻易做出决定。
另一种选择是使用系统，以便每个人都有一个参考框架，但是要更改系统的一小部分，以便团队中的每个人都知道，或者如果他们不知道更改，则很容易注意到且易于学习。这是称为改善的实践的基础。演讲“剃毛presentation牛”中介绍了一种面向开发人员的公式，强烈建议您仔细研究并仔细思考。
因此，找到一个可以改变的小东西，可以改善您的生活，并希望其他一些。解决或改善情况。这将为您提供实践和经验，以将更改付诸实践。确保获得反馈：您是否可以更好地讨论它，是否真的有用，是否使系统的另一部分不适？培养对可以做什么以及如何做的感觉。
现在发生了三件事：
您已经改进了系统，
您已经获得了有关如何更改系统的经验
团队已经看到您成功地更改了系统。
现在，随着您的经验的增长和消除悬而未决的问题，请选择另一项改进您将开始面对系统中的难题，但至少现在当您说我们必须更改X时：
您知道更改将如何影响系统
您知道它将产生什么问题（需要重新学习哪些规则）
您知道一些立即解决或解决变更问题的方法，这些变更会引入您的周围环境。
周围的人都知道您对系统有所了解，并且能够成功进行更改
评论
很多人同意那里。值得强调的一件事是，没有代码库或过程是完美的。一切总是妥协。就像您说的那样，您可能想舍弃所有内容并重新开始，IME通常最好是通过一些小步骤来缓慢演进。这样，您就可以将所有人带到一起，并避免失去现有知识。重要的是要知道要去哪里。这样，您就可以发现并抓住机会，把握机会。
–gidds
19年1月9日在10:57
@gidds我认为这是我的观点，最好做出每个人都知道的，或者至少对他们来说显而易见的小改变，并且可以轻松阅读。尽管我确实认为有一个长远的目标来帮助您在所有可以改进的方法中进行选择的选择很重要，但我认为制定这种方法并不总是可行的，特别是对于在开发方面经验有限的初级开发人员而言与人大规模合作。制定对现状的改进要容易得多。这会激怒您吗？是的，您可以做些什么来改善这种情况？
– Kain0_0
19年1月9日在23:38
@gidds会再次阅读您的评论，我同意没有一个过程或过程是完美的，甚至无法适用于给定的情况，而且如果处理不当，甚至可能使团队到达一个从未尝试过的地方。话虽这么说，即使成功了，最终结果通常还是该软件及其团队必须满足的所有竞争要求之间的折衷。如果企业属于受管制的行业，则要困难得多。政府不喜欢违反规则的人。
– Kain0_0
19年1月9日在23:55
#3 楼
是的你可以。但是...你要小心。
在我职业生涯的开始（很久以前），我很幸运/不幸进入了几个月作为“初级”项目。
我注意到的第一件事是（OMG）没有代码存储库！所有代码合并都是通过邮寄彼此发送zip文件来手动完成的。
因此，我去了（也是新来的）经理，建议我们应该有一个存储库。答案是：好的，组织它....
因此，在没有帮助的情况下组织代码存储库是公司的新事物，现在这真是令人沮丧的体验。
何时我将其全部设置好，（震惊）没人愿意使用它。因此，我尝试着继续前进，幸运的是，我的经理理解了它的重要性，因此得到了我的支持。
但是，这导致我不太喜欢，并且不幸地从源代码控制系统获得了一个昵称。
所以我的看法是，首先了解您的团队成员，他们认为接下来要建立的团队重要。
也许他们也有一份清单像你的。也许他们已经完成了所有工作，但他们想做清单上的“事情”。也许他们....（无论如何）....
整个团队必须保持一致。
但是，如果没有，那么您仍然可以专业地工作。
并找到志同道合的人，并一起工作，您认为应该怎么做。如果这样做能带来良好的结果，那么更多的人将与您合作，最终将成为“过程”。
与代码一样，开发过程也是如此：需要不断改进。
所以，是的，您应该始终努力改进，有可能改进。
还要记住，您正在与很多人一起工作，可能已经是专业人员，他们知道哪里出了问题以及需要什么。
评论
在我看来，您像是在背后落后于人，而没有先向其他开发人员提出任何正当理由，而只是由经理强迫这样做。没有人喜欢“那个家伙”。所以，是的，如果您有改进的建议，请与同事一起提出，但最重要的是：能够向他们证明您的建议。为什么它将使情况变得更好？如何节省人们的时间和精力？新方法有什么弊端吗？等等。如果您可以预测并准备对人们关注的问题的回应，那么他们将更有可能愿意接受您的建议，而不是强加于人。
– Alex
19年1月9日在9:54
我感觉好像它“没有在人们的背后”。我将此问题报告给我的经理，他告诉我要解决，我做到了。
–罗伯特·安德鲁杰克（Robert Andrzejuk）
19年1月9日在10:14
“很不幸，从源代码管理系统获得了一个昵称。”大声笑我希望你不要混蛋。
–BЈовић
19年1月9日在10:50
Git还没有出现。
–罗伯特·安德鲁杰克（Robert Andrzejuk）
19年1月9日在11:31
@BЈовић也许他们称他为“颠覆性” ... :-)
–亚历山大
19年1月10日在11:32
#4 楼
随着时间的推移，（初级）开发人员尝试实现上述目标是否值得？
是的，尝试并创造事物总是值得您付出努力的更好。您最清楚自己毕竟会面对什么问题。
但是正如您所提到的，有很多问题需要解决，而且其中许多问题并不是很有价值。在很多地方，成功或其他条件更好的人会为您取得成功提供难以克服的障碍。因此，您应该始终尝试使事情变得更好，即使那意味着选择您花费时间尝试做的事情。
最后，如果您不属于解决方案，那您就是部分问题。
评论
哲学.stackexchange.com / a / 38244
–凯文
19年1月9日在14:33
#5 楼
是。但是，即使对于高层管理人员而言，组织变革也很困难，因此，如果您真的想以正确的方式做出改变，请：在头几周内不使用此时间to：
创建良好的第一印象。证明自己适合团队。
了解文化和政治或您的公司。推动变革是否安全？
与同事建立良好的关系
了解团队的流程，规则和需求
了解您的工作并尽力而为。您一定会很忙。
选择战斗。取得一些早期的胜利：您可能会充满力量去改变一切，但这是不现实的。专注于一些低调的成果，并表明您的想法可行。您希望他们接受更复杂的改进。并记住，书中的内容会更容易。
考虑对他人的影响：我确实会重构影响很多文件的文件。即使他们改进了代码，我也必须非常小心，以免将合并变成麻烦。还应尝试了解他们继续那样工作的原因。可能是因为他们缺乏测试，所以他们不能使用Scrum，并且可以理解的是，他们害怕频繁地将未经测试的代码推向生产环境。编写可行的测试绝非易事。当前的代码可能真的很难测试。此外，团队可能既不编写测试也不编写可测试的代码。当前的代码库可能特别难以测试，需要重构。更改此问题可能需要几年时间，但至少您可以专注于根本原因。
不要判断。不要要求。要求并仔细聆听：这是交流至关重要的时刻，我们程序员通常并不擅长于细微的差别。有技术可以帮助您。不断推动我们的想法而不是专注于答案很容易。首先，确保他们觉得您有他们的观点。了解感觉很重要。这种变化使他们感到什么？恐惧？不足？愤怒？挫折？希望？懒？笨？ （永远不要让人们感到愚蠢）。当然，您之前会问很多问题，这可以防止很多错误的步骤。
以身作则：抱怨很容易，改变很难。显示结果，人们就会相信您。如果他们不使用测试，则可以编写单元测试。如果人们不提供文档，则可以与团队共享一些Google文档。理解“确定，做到这一点”是最好的方案之一，然后您需要交付。在这种情况下，您需要考虑所需的资源。示例：给我一个小的Amazon实例，让我从管理员那里得到两个小时的Jenkins服务器
让它变得小巧（又便宜）：您不想等待正式的预算批准，也不想让老板认为您从昂贵的程序员那里浪费了宝贵的时间。最好使用此代码来审查软件或评估几种开源工具，但我们暂时仅使用该仓库。
获得临界质量：聚集一群致力于提高质量的人。您甚至可以与他们一起参加会议并寻求帮助或指导。 Peopleware在团队的基础上描述了“唤醒巨大现象”，他们实际上是在反抗一些愚蠢的做法，这些做法会降低生产率。单独地讲，这真的很危险，我不建议这样做。但是如果所有人都同意，变更就容易了。
给它一点时间。之后用脚投票：您可能想要在几个月至两年内尝试一下。但是有些公司没有简单的解决方案。一些团队不想改变并且没有激励。有些代码库简直令人恐惧。如果您觉得自己与世无争，请记住工作池中有很多职位。您想学习良好的做法，从长远来看，如果您的薪资水平明显降低，您会变得更好，但是获得的经验将使您变得更有价值。
奖励：如果成功，请写下来进行简历/面试。作为初中生，您通常无话可说，做出更好的改变总是一个好兆头。您想对自己的所作所为和他人的所作所为有一个非常清晰和现实的看法。想象一下下面的面试问题。
告诉我你在团队中有所作为的那段时间。
好吧，我在一个他们过时的地方实践。很多人对此不满意，生产力还有很大的提高空间。因此，我建议进行回顾性研究的快速实验，我们分别进行了X和Y评估，结果得到了可衡量的出色结果。”
评论
我认为“不是在最初的几周内”，尤其是在最初的几周内，仅问问题就能取得很大的成就。您不仅会了解项目和工作流程，还将使您的同事思考X为什么在Y中而不在Z中，缺少文档，繁琐的工具（为什么我需要20条命令来整合我的变更？）等
–迈克尔
19年1月11日在12:34
我可能说得很糟：当然，您有时会在其他时候提出疑问，特别是在头几天。我打算但可能通过中间交流的观点是，作为一名大三学生，您在一开始就不要“追求变化”，因为您似乎是万能的，并且您缺乏诸如改变组织等棘手的工具
– Borjab
19年1月11日，14：40
#6 楼
是。但不是您建议的内容。列表/单元测试是您唯一可以取得进展的项目。
您可以最小限度地自行添加这些内容投入时间并显示即时价值。这是一个技术问题，具有广泛接受的好处，不会影响其他工作惯例。即使您没有接受结果，也可以使您对代码库有所了解。容易出售。
其他通常是涉及整个团队甚至其他团队的业务流程。您可能会提出改进建议，但对于初级员工而言，这些改进很难，而且更改过程通常与技术无关，并且可能与您的正常工作无关。
我还建议诸如设置CI管道，自动化部署，版本控制，打包库是攻击的好方法
评论
作为初级员工，我提出了所有这些建议。几年来，在一些帮助（和大量的支持）的帮助下，我成功地实现了它们。最后，我是高级建筑师。它可以工作，并且通常值得尝试。 ;）但是，您必须选择自己的战斗方式，并知道何时面对艰难的奋斗，而这可能甚至无法很好地适应组织的概况/动态。在另一个角色中，我很想走同样的路线，并决定甚至不提出这个话题，因为在那里永远都不可能解决这个问题，而且也不是特别重要。
–轨道轻赛
19年1月9日在12:06
单元测试和持续集成是开始的不错选择。他们将为您提供最佳的投资回报。没有允许其工作的技术实践，请勿尝试Scrum。如果每个人都是危险的并且需要测试人员和系统管理员的大量工作，那么您如何频繁部署？
– Borjab
19年1月9日，19：21
单元测试/集成测试不一定由于架构而可以立即开始实施。此外，它们倾向于迫使某些模式违背现有事物的顺序。尽管它们确实有价值，但并非总是建议的那样简单。
–NPSF3000
19年1月13日在5:40
#7 楼
这取决于：您希望从更好的实践中获得多少收益
您需要花多少精力去实现这一目标
成功的机会是什么和风险-从简单的采用失败到新的实践实际上是可怕的，代码质量下降，关键人员离职，每个人都讨厌您，您必须在另一个没人知道您名字的城市找到另一份工作
：花一些合理的时间提倡自己认为最好的事情完全在您的职责之内-但决定应该是团队或管理责任。请记住，即使最终会有更好的做法，疏远别人也很少值得。
#8 楼
不要从最复杂的事情开始，例如Scrum。从最简单的步骤开始。您没有提到源代码管理。您是否有一些源代码存储库（git，svn，cvs等）？标记和分支的策略？这些是初学者可以做的简单步骤。阅读这些步骤（试图解决）所解决的问题，以及如何帮助您的公司降低成本（这正是管理层感兴趣的内容）。
下一步可以自动构建，每晚或在每次检查后立即构建在，例如和詹金斯在一起。您也可以自动运行测试。并添加一些用于测量代码质量的工具（哦，是的：定义一些编码标准也是一个好步骤）。关于Scrum，请更好地阅读“极限编程”（XP）。 Scrum基于XP的许多思想，并在它们周围添加了形式化的过程-XP的概念可以在没有该过程的情况下使用。它，分析结果，……但不要期望与他人有太多合作：大多数人都喜欢坚持自己的旧坏习惯。但是，如果您不尝试这样做，将无济于事。
#9 楼
首先，请提出问题。在阅读您的列表时，我会建议以下问题（请参考您的列表以了解其适用范围）：
如何我能看到企业主要求的工作吗？
您尝试过[Scrum]吗？
谁是产品负责人？
有什么角色？
[这是什么？角色]？
哪个角色负责[此活动]？
您是否尝试过每天站起来？
我如何将我的障碍传达给团队的其他成员？
我如何找出团队中其他成员的工作方式？
我们应该将[this]放在问题跟踪工具中吗？
我们应该如何在问题跟踪工具中写入[this]？
/> [this]发生时，是否应将其作为[that]放入问题跟踪工具中？
我们如何测试？
我们如何记录测试以供其他人重复使用？
您尝试过[JUnit]吗？
[this]记录在哪里？
您尝试过[MediaWiki]吗？
将[括号]中的内容替换为适合于m使问题有意义或适合您的优先事项。如果我的措辞与您的风格不符，请考虑重新措词。
您可能已经开始这样做了。优先于一对一对话而不是小组对话。因为一对一，您可以更好地了解他人的想法。这个人是这个人吗？反对？虚弱？疯了吗
初学者时，提问几乎是免费的。人们应该期望您提出问题。即使您的问题暗中鼓吹反对的立场，也不应生气。他们应该解释为什么反对这一立场。我建议不要与他们争论。争论往往使立场更加坚强。注意谁有什么位置并继续前进。
以后，采取步骤
寻找您和可能的其他人（即您之前提到的同意您的那些人）可以启动所需更改的方法。不是每个人都想站起来吗？为什么不？也许想要一个的人可以拥有自己的立场。不如整个团队有效，但比您现在拥有的更多。
如果遇到障碍（并且假设您无法分道扬）），请向团队发送电子邮件以寻求帮助。
确定角色应该是什么，可能要在同意您的其他人的支持下。当工作涉及到您（可能是您的一个小组）认为他们应该扮演的角色时，请开始始终如一地与他人联系。如果他们退缩，请他们确定谁应该担任这个角色。
询问（您确定的）产品所有者，以书面形式描述他们认为自己的产品现在和将来应该如何工作。
安装测试框架（如果其他人赞成，请共同决定使用哪个框架），并将其用于您的项目。修复错误时，编写测试。将此文档记录在问题跟踪器的错误报告中（表明错误的书面测试，存储在[位置]）。鼓励其他人在进行更改时运行测试。如果没有，请自己运行测试，并根据需要将问题提交给跟踪器。
如果您可以获得管理支持，请安装Wiki软件或类似产品并开始记录您的资料。如果有人问您一些问题，表明他们没有阅读文档，请将其指向相关页面。如果他们不了解文档，鼓励他们提出更多问题。如果他们继续问文档中涉及的问题，请在回答时引用文档中的内容。如果您认为问题是结构性的而不是他们没有阅读，请考虑鼓励他们更新Wiki。
我建议一次只专注于一项任务。当然一次只能推一个。不要努力看到这个比团队想要的更努力的例子。比他们更专注于改变您的行为。如果您的方法是正确的方法，那对观察您的人应该是显而易见的。行动胜于雄辩。轻推时，尽量不要与同一个人重复。一旦您将马匹引水了，就可以选择何时或是否该给另一只喝水了。
最终，您将成为高级职位。
随着时间的推移，您的团队将雇用新员工。您将不再是新员工，而可以与新人一起担任职位。与他们一起进行更改。而且您可能会发现与现有的队友也在进步。或者，如果这不起作用，则在他们有更好的做法的情况下寻找新工作。没有真正的着急。你有一份工作。您可以等待一段时间，找到更好的工作，要么改善工作，要么找到更好的工作。
评论
+1;带有许多好主意的更好答案之一。
–基思
19年1月14日，下午3:26
#10 楼
简短答案：不，出于其他答案中概述的所有原因。即使是中级或高级开发人员，通常最好在加入新团队后首先寻求理解。建议的解决方案：
1）每当您看到自己的东西时，感觉应该有所改善，请注意！ （在笔记本中，在电子记事本中...）
2）6个月后，返回记事本并进行检查。现在有多少个想法变得毫无意义和不足？很可能您为自己节省了一些尴尬。如果某些想法仍然存在，那么现在是介绍它们的好时机，如果可能的话，可以先对它们进行自我测试。
评论
我觉得您的回答很好，就像是“适应环境然后看看缺失的事物”，以便您可以做出有意义的贡献。
–米格尔·阿维拉（Miguel Avila）
20/09/08在23:35
#11 楼
您说该团队还很年轻（3岁），所以如果您现在不能引入一些好的原则，那么10年后的工作将会更加困难。您提到的某些内容（例如测试和版本控制系统）已经可以提出建议，但不要在没有强调它们的明显好处并选择开发堆栈所需的工具的情况下提出建议。#12 楼
答案很晚，在其他答案中也有很多好的内容。我认为需要指出，这里的关键问题不是具体实践，而是整体团队文化。
很难实现文化变革。
更多，因此，如果您被视为“初级”
，只要有实现目标的方法，其他一切都可以跟随持续改进。
我实现这一目标的方法是：
记录在案的流程和程序
与团队进行回顾，其行为是对流程文档的更改。
我想如果您没有冲刺，那么您还没有常规的复习。您所需要做的就是与团队进行对话，然后采取行动。
您可以轻松地开始记录过程。 “我是新人，我说对了吗？让我写下来。”重要的是，您自己可以真正按照流程进行操作，或者尝试打电话给我们中断的地方。
也许您是从这样的临时交谈开始，然后建议常规的仪式。
采用这种方法可以渐进地，轻柔地进行。您可以避免以初级人员的身份了解所有事情，而是尝试成为团队做出改变的促进者。
一些注意事项：
一些团队的流程很差，但实际上已经知道这一点。他们
想要改变，只需要一些东西就可以催化。其他车队
确实束手无策，而且很难改变。
个人也一样。
您需要对此保持敏感，并弄清楚团队中的哪些人愿意改变，而哪些人不愿意改变。了解原因。
轻松获胜。
欢迎团队做出改变：发现他们的个人痛点
并设法帮助他们解决。
评论
我注意到您的标签之一是Scrum。您的团队是Scrum团队吗？如果是这样，他们是否举行回顾展？您有任何理由使用“他们”而不是“我们”吗？例如。 “我的团队很小，有些新鲜（<3岁）。他们缺少”？
仅供参考，如果您曾在多家公司工作过，您可能不再是初级职位。
是什么让您认为您列出的内容“更好”，而不仅仅是最新的浪费时间的风尚？能为每个人提出合理的理由吗？
“管理对改进[..]的实施持开放态度”，这在很大程度上是无关紧要的，更重要的是团队的其他成员是否对此持开放态度。如果不是，则有管理层的支持而不是团队的支持，这是通往与团队其他成员之间对抗关系的道路。