버스 계수
Bus factor버스 요인은 팀원 간에 공유되지 않는 정보와 역량에 따른 위험을 측정한 것으로, '버스에 맞았을 경우'라는 문구에서 도출한 것이다. 빵 트럭 시나리오, 버스 문제, 맥주 트럭 시나리오, 복권 계수, 트럭 계수,[1] 버스/트럭 번호 또는 트럭 계수기로도 알려져 있다.
이 개념은 핵심인재 위험에 대한 훨씬 오래된 아이디어와 유사하지만 (이 개념은 보험에 들 수 있는 비용으로 이론적으로 대체할 수 있는) 재무나 경영진에 비해 핵심 기술 전문가를 잃는 결과를 고려한다. 인력은 버스 요인에 기여하기 위해 키와 교체할 수 없는 사람이어야 한다. 교체 가능하거나 키가 아닌 사람을 잃는 것은 버스 요인 효과를 초래하지 않을 것이다.
이 용어는 소프트웨어 개발에 처음 적용되었는데, 팀 구성원이 잘 수행되는 코드를 제작하여 중요한 구성요소를 만들 수 있지만 문서화되지 않았거나 공유되지 않았거나 암호화되지 않았거나 난독화되지 않았거나 게시되지 않은 작업과 같은 다른 팀 구성원에게도 사용할 수 없는 용어였다. 따라서 핵심 구성요소는 해당 팀 구성원이 부재함에 따른 직접적인 결과로 효과적으로 상실되어 구성원 키가 된다. 이 부품이 프로젝트 진전의 핵심이라면 프로젝트는 중단될 것이다.
정의
'버스 요인'은 지식이나 역량 있는 인력이 부족해 사업이 중단되기 전에 갑자기 사업에서 사라져야 하는 최소 인원이다.
'버스에 치였다'는 표현은 사람이 죽거나 프로젝트에서 갑자기 사라지는 것을 말한다. 가상의 미래 소멸을 암암리에 유머러스하게 묘사하기 위해 사용된다. 팀 구성원은 말 그대로 "버스에 부딪혀"야만 "버스"가 적용되는 것이 아니라, 팀 구성원이 갑작스럽게 프로젝트 작업을 방해할 수 있는 많은 이벤트가 발생할 수 있다. 여기에는 새로운 직업을 갖거나, 육아휴직을 하거나, 생활양식이나 생활상태를 바꾸는 것이 포함될 수 있다.
예를 들어, 30명으로 구성된 팀이 재료 섞기, 반죽하기, 굽기 세 단계로 빵을 만든다고 하자. 재료 섞는 법 10명, 반죽하는 법 30명, 굽는 법 5명 모두 안다. 빵 굽는 법을 아는 5명이 모두 사라지면 팀은 빵을 생산할 수 없기 때문에 팀의 버스 요인은 5이다.
버스 요인에 대한 드문 대안적 정의, 즉 사업에 없어서는 안 될 인원의 수가 있다.[2] 즉, 단일 실패 지점인 최소 인원수라는 것이다. 이 정의를 사용할 경우 높은 버스 요인은 나쁜 것으로 간주되며(포함된 사람의 손실은 프로젝트를 파괴하므로), 0은 이상적인 버스 요인으로 간주된다.
역사
이런 종류의 질의의 초기 예는 1994년 마이클 맥레이가 공개적으로 귀도 판 로섬이 버스에 치이면 파이톤 언어는 어떻게 되느냐고 물었을 때였다.[3]
조직 패턴 책 2004,[4]에 게재된"트럭 번호"는 이미 순환 개념 자체 이 작품은 패턴 언어 프로그램 디자인 시리즈의 1995,[5]의 첫번째 패턴 언어 프로그램 회의의 1994년 8월, 어디에서 referen다 그 때의 출판 기록으로 책에 게재한 발전이에요.ced에 솔로 비르투오소를 포함한 [6]패턴들 이 용어는 1998년까지[citation needed] 경영에서 흔한 일이 되었고 같은 해에 정신 건강에서 사용되었다[clarification needed].[7] 1999년까지 컴퓨터 기계 및 정보 시스템 프런티어 협회의 소프트웨어 엔지니어링 논문,[citation needed] 2003년까지 엔지니어링 논문,[8] 2005년 데비안 프로젝트에서 볼 수 있었다.[9]
2015년과 2016년에 실시된 연구는 133개의 인기 있는 GitHub 프로젝트의 버스/트럭 요소를 계산했다. 그 결과 대부분의 시스템은 버스요소가 작으며(65%는 버스요인 ≤ 2) 10% 미만일 경우 그 값이 10보다 큰 것으로 나타났다.[10][11]
이 용어는 주로 비즈니스 관리, 특히 소프트웨어 개발 분야에서 사용된다.[citation needed]
버스 계수 증가
많은 소프트웨어 개발 프로젝트에서, 버스 요소를 잠재적으로 전체 팀의 크기로 증가시키기 위해 정보를 공유하는 것이 하나의 목표다. 버스요소가 높다는 것은 많은 개인들이 계속 진행할 수 있을 만큼 충분히 알고 있고, 매우 불리한 상황에서도 이 프로젝트는 성공할 수 있다는 것을 의미하기 때문에 좋은 것으로 여겨진다.[12]
버스 요인을 증가시키는 몇 가지 방법이 제안되었다.
참조
- ^ Bowler, Michael (May 15, 2005). "Truck Factor". Agile Advice.
- ^ Coplien, James; Harrison, Neil (2004-07-26). Organizational patterns of agile software development. Wiley.
- ^ McLay, Michael (June 29, 1994). "If Guido was hit by a bus?" (Mailing list).
- ^ Coplien, James; Harrison, Neil (July 26, 2004). Organizational patterns of agile software development. Wiley.
- ^ Coplien, James; Schmidt, Douglas (May 12, 1995). "Chapter 13, A Generative Development-Process Pattern Language". Pattern Languages of Program Design. Addison Wesley. Bibcode:1995plpd.book.....V.
- ^ Coplien, James (August 4, 1994), "A Generative Development-Process Pattern Language", Internal proceedings of PLoP 1994, Allerton Park, Illinois: unpublished.
- ^ Simon, Robert (May 17, 1998). The Mental Health Practitioner and the Law: A Comprehensive Handbook. Harvard University Press. p. 69. ISBN 0-674-69721-9.
- ^ Redmond, Matthew C.; Newton, Paul (2003). "Integrating GIS in the Engineering, Planning and Design Processes" (PDF). Archived from the original (PDF) on 2012-03-12.
- ^ Reinholdtsen, Petter (November 11, 2005). "Re: Resignation and uploads" (Mailing list).
- ^ Avelino, Guilherme; Valente, Marco Tulio; Hora, Andre (September 10, 2015). "What is the Truck Factor of popular GitHub applications? A first assessment". PeerJ Preprints. doi:10.7287/peerj.preprints.1233v3.
- ^ Avelino, Guilherme; Passos, Leonardo; Hora, Andre; Valente, Marco Tulio (2016). "A novel approach for estimating Truck Factors". 2016 IEEE 24th International Conference on Program Comprehension (ICPC). pp. 1–10. arXiv:1604.06766v1. Bibcode:2016arXiv160406766A. doi:10.1109/ICPC.2016.7503718. ISBN 978-1-5090-1428-6. S2CID 19238548.
- ^ James Coplien, 페어 프로그래밍 켜짐. 인용: "프로젝트가 무력화되기 전에 트럭에 치이거나 그만두어야 하는 사람이 몇이나 몇이나 될까?"
- ^ a b c "Increasing your team's bus factor". 2008-09-03.
추가 읽기
- Michele Marchesi, Giancarlo Succi, Don Wells, James Donovan Wells, Laurie Williams (2003). Extreme Programming Perspectives. Boston u. a.: Addison-Wesley. ISBN 0-201-77005-9.
{{cite book}}: CS1 maint : 복수이름 : 작성자 목록(링크) - Laurie Williams, Robert Kessler (2002). Pair Programming Illuminated. Boston u. a.: Addison-Wesley. ISBN 0-201-74576-3.
- Kent Beck (2000). Extreme Programming. Das Manifest (in German). s. l.: Addison-Wesley. ISBN 3-8273-2139-5.
외부 링크
- 독한 사람들, 버스 요인에 대한 (다른 주제들 중) 토론과 그것을 늘리는 방법을 포함하는 강연
- "Linus Torvalds가 버스에 치이면 어떨까?" - 경험적 연구, 유머 작품
