礼仪/领导力/分享最佳实践--我应该努力影响多少？

Question

我最近加入了另一个兼职团队，在那里我认识了几个人，他们大多了解我的设计工作，但我会和他们一起做设计和一些开发。在第一周的时间里，我注意到很多事情都做得不对，但我不想拿出一个大清单，让人们想“这个人是谁，告诉我们该怎么做?我们一直做得很好。”

我所看到的许多事情并不是按照最佳实践来完成的，但是除了这是他们已经工作了一段时间的方式之外，没有任何其他的原因，他们自己解决问题。

因此，我只是想知道如何有效地帮助团队和任务，因为这不仅仅是偏好，而且我相信这将使整个团队更高效、更快乐，代码将更干净和更易于维护，并且更容易引入新的人员。我要么成批地提东西，要么暂时吞下去，直到我建立起一些领导力资本，并在暂时陷入困境时展示了我的一些价值和专业知识。

一些例子：

• Scrum的角色都出格了(同一个人是scrum的主人和产品所有者，但大多数故事都是别人写的)
• 故事写得不好，有些是误导的，有些是模糊的，或者是完全错误的，而且需要大量的背景背景。大多数情况下，人们会想出该做些什么，尽管故事并没有说出来
• 每天的会议有一个小时的时间，据说是站起来和冲刺计划的混合体。
• Git提交大多只是一个票号，没有其他解释。许多在一行中使用完全相同消息的多个提交的示例。
• 项目没有自述文件，克隆后也无法运行。
• 显然有一个过程，在一个分支中模拟代码，然后手动复制到另一个分支并进行修改，以创建发布的“真实”代码
• 有一小部分单元测试，但没有集成测试，没有E2E测试。我仍在努力学习如何把TDD做好，并希望这个团队已经拨号以便我可以学习，但是他们的软件主管说：“我们开始的时候每个人都对Framework很陌生，所以我们不得不给开发人员一些放松”，显然这种放松从来没有加强过。
• 没有内置的线性化策略，代码中也有不同的、非标准约定的例子(比如命名事物)。

我知道这很长，但考虑到所有这些事情，在我看来，这些都是我想要帮助球队克服的、更快、更好的事情，但我不知道我是否应该在这个早期阶段指出这些事情。提前感谢！

Answer 1

如果您的组织遵循敏捷软件开发的价值观和原则，那么应该定期反思团队的工作方式和改进的机会。这是敏捷软件开发宣言中唯一的具体实践。在Scrum中，这种一般做法以Sprint回顾展的形式出现。其他框架和方法可能有其他反映和改进的方法。

由于这个问题被标记为敏捷化并提到Scrum，我将假设您有定期的回顾。如果您不这样做，这将是我建议实施的第一个实践，这样团队就可以找到并讨论妨碍有效工作的事情。

这个问题的核心是，据我所知，当你刚加入一个团队时，如何有效地提出问题，而你过去的经验告诉你，有很多无效的实践。特别是在你没有正式的领导角色或者对团队的整体表现负有任何责任的情况下。

第一步是认识到在软件开发这样复杂的领域中没有最佳实践。对一个团队非常有效的东西可能会对另一个团队失败。问题的实践、方法、工具和解决方案取决于团队所处的环境。即使是同一组织中的团队也可能会发现不同的实践对他们的环境更好。

我的建议是找出最痛苦的一两个问题，并在下一个Sprint回顾展中提出。由于您来自外部，您已经在没有经历过这些问题或可能已经找到了解决方案的团队中工作过。如果问题已经存在了一段时间，团队中的人可能已经对他们失去了敏感。当考虑要提出的问题时，考虑你在团队中的角色。

在这种情况下，您是团队的开发人员。Scrum角色使用不当或会议时间可能非常烦人，但作为开发人员，Scrum角色是最大的问题吗？可能不会。像克隆后的项目运行问题这样的事情在你的脑海中是新鲜的--你能解决这个问题吗，以便更容易地加入新的团队成员？由于缺乏约定，您发现代码很难阅读，所以您能开始在您所接触的代码中介绍它们并让团队购买吗？

这种方法不仅可以帮助团队充分利用您作为开发人员的知识和技能，还可以帮助您充分利用您在团队中的经验，以及团队其他成员最近没有经历过的学习过程。希望你在这些领域的观点能得到团队的重视。

Answer 2

我使用的主要方法是以身作则，选择你的战斗。

由于人才的混合，以及实践和代码基础的发展，大型项目几乎从未处于很好的状态。有很多你看不见的历史。

举个例子来说，清单上的很多事情都是你可以做的。在进行常规更改之前，使用如下标题进行拉请求：“提高测试覆盖率，为实现特性X做准备。”提高标准。人们会注意到自己的游戏。

为了选择你的战斗，优先考虑你的清单，只需做第一项工作。在回顾中提出来。提出具体的、渐进的步骤。融入你队友的反馈。人们通常愿意作出改进，但你必须逐步引进它。

Answer 3

我参与进来，因为我有很多项目和公司文化的经验。而你正处于冰层上。

首先，您是在一个非scrum环境中，标签敏捷被过度使用，并且有太多的变体。还有一种态度：“照我的理解做简单的事情，不做开销。”因此，如果你想看scrum，建议一个研讨会，最好是一个已经做好了的部门。首先，询问经理们是否愿意对当前的敏捷方法有深入的了解。

任何改革都不会发生得很快，说教scrum只会让你自己和你的同事失望。另外，90 %的代码库将是遗留代码。疯狂重构是个坏主意。

你自己可以正确地工作并提供高质量的服务。但你必须接受这种情况，并喜欢用小宝石来表示。否则，如果涉及另外三个开发人员，请转到另一份工作。因为改变是很难的。

有一些一般的措施，如

• 组织新代码/重新设计、特殊业务特性的演示；
• 代码评审，比如承诺，分享知识；
• 工作中的学习:指派其他开发人员来保存关于新语言/库特性的演示文稿(对于java、C#、新语言、SSH、SAML、.)；
• 代码检查器，SonarLint/SonarQube (如果尚未使用)。免费找虫器；
• 工具，小型自写代码生成器，分析器，语言词汇表.

特别是我不想重提整个scrum方法，因为scrum有一个圣经术语，并且存在混合的非纯形式，包括看板之类的。很可能有些人已经经历过scrum的失败。想想看：

答：“苏格兰人不会说谎。”B：“McGorwedd呢？”答：“一个好苏格兰人不会说谎。”

名字是相对的。遗留代码的优点是代码基本上可以工作。新代码意味着更多的风险和压力，质量可能更差。