巴士系数

╰+攻爆jí腚メ 2023-10-05 11:52 13阅读 0赞

巴士系数

巴士系数可衡量必须乘公交车撞到危险项目的最小团队成员人数。旨在尽可能增加您的巴士系数？阅读更多内容以了解操作方法！

**什么是巴士系数**

巴士系数定义了对项目至关重要的开发人员数量。如果他们发生了什么事（他们被公共汽车撞到了），则该项目处于危险之中。被公交车撞可能有点极端。考虑另一种情况：如果一个关键的团队成员长假或生病了，该项目很容易面临风险。目标是尽可能增加巴士系数。增加数量的最好方法是鼓励团队内部和外部的知识共享。

巴士系数也称为面包车场景，彩票因子，卡车因子，公共汽车/卡车数量或卡车因子。

**为什么您可能想增加巴士系数**

*  它可以在团队发生之前检测出团队中的单点故障。
 *  共享知识可以防止项目崩溃。
 *  尝试不断增加巴士系数可以使您对项目有很好的控制。

**增加巴士系数的问题可以解决**

*  [“不是我的问题”的心态][Link 1]
 *  [毫无意义的工作][Link 2]
 *  产品失败
 *  不满意的客户
 *  [断开业务与IT之间的连接][IT]
 *  [代码质量差][Link 3]
 *  [士气低落的团队][Link 4]
 *  [有毒的团队文化][Link 5]

**如何增加巴士系数**

*  **重新分配**  
      
    通常，项目依赖于一个或几个“英雄”。公司必须为他们离开或缺席做好准备。将英雄重新分配到项目的不同部分或完全不同的任务。他们的替代者将有时间完成知识转移，并在英雄仍然是公司一部分的情况下向他们提问。英雄在他们的新区域中也可能非常有用。
 *  **代码审查**  
      
    代码审查有助于发现错误，并帮助其他开发人员熟悉您的项目。此外，分担责任营造了友好的气氛。  
      
    有关更多信息，请参见[代码审查][Link 6]。
 *  **提高初级团队成员的水平和经验**  
      
    重要的是，让初级团队尽快成为有价值的团队成员。不要总是将复杂而困难的项目交给高级开发人员。大三学生可能会花更多的时间来弄清楚项目，但他们总是可以寻求帮助。与更高级的同事讨论这些问题有助于初级人员快速成长。
 *  **结对编程**  
      
    可以由未编写代码的人员（如果不需要尽快修复）来修复错误。  
      
    有关更多信息，请参见[配对编程][Link 7]。
 *  **例行会议**  
      
    如果您的团队不做日常站立活动，请确保不时与所有团队成员见面，以共享重要信息。  
      
    有关更多信息，请参见[敏捷事件][Link 8]。
 *  **编写显式代码**  
      
    如果任何人都可以阅读您的代码，这将非常有帮助。您可以改善样式，结构或命名。评论也很有用。  
    有关更多信息，请参见[代码质量差][Link 3]。
 *  **保持域名安全**  
      
    您应该了解客户的域名。采用与客户相同的词汇可以帮助您的团队理解他们要说的话。帮助他们提供项目描述和摘要，并将其全部记录在词汇表中。
 *  **编写测试和文档**  
      
    功能测试可帮助开发人员快速了解项目。记录（至少）项目的主要目标。  
      
    有关更多信息，请参见[软件文档][Link 9]或[性能测试][Link 10]。

**增加巴士系数的常见陷阱**

*  缺少团队可替代性。似乎每个人都熟悉该产品，但是只有一个人（或几个人）可以发布该产品。这可以通过自动化来防止。
 *  巴士系数可能被隐藏。它并不仅仅是关于您的项目的知识。它只能是一个不共享的密码，可以保护项目的重要部分。
 *  文档不完善或不存在。如果开发人员不同意他们的想法，写下来非常重要。可以通过建立信任，甚至在需要时签署保密协议来避免这种情况。

**巴士系数资源**

*  敏捷建议：[卡车因素][Link 11]
 *  中：[有关巴士系数的经验教训][Link 12]
 *  媒介：[巴士系数][Link 13]
 *  开发人员：[如何增加巴士系数][Link 14]
 *  中等：[编写高度可读的代码][Link 15]

[Link 1]: https://developerexperience.io/problems/not-my-problem-mentality
[Link 2]: https://developerexperience.io/problems/meaningless-work
[IT]: https://developerexperience.io/problems/disconnect-between-business-and-it
[Link 3]: https://developerexperience.io/problems/poor-code-quality
[Link 4]: https://developerexperience.io/problems/demotivated-team
[Link 5]: https://developerexperience.io/problems/toxic-team-culture
[Link 6]: https://developerexperience.io/practices/code-review
[Link 7]: https://developerexperience.io/practices/pair-programming
[Link 8]: https://developerexperience.io/practices/agile-events
[Link 9]: https://developerexperience.io/practices/software-documentation
[Link 10]: https://developerexperience.io/practices/performance-testing
[Link 11]: http://www.agileadvice.com/2005/05/15/agilemanagement/truck-factor/
[Link 12]: https://medium.com/@einenlum/lessons-learned-about-bus-factor-1-5-introduction-994b3b0332d3
[Link 13]: https://medium.com/tech-tajawal/the-bus-factor-6ea1a3ede6bd
[Link 14]: https://dev.to/scottharrisondev/how-to-increase-your-bus-factor-3dpg
[Link 15]: https://medium.com/swlh/writing-highly-readable-code-94da94d5d636