Software Development Tools Do Not Make Teams Fast

도구가 팀을 빠르게 만들지는 않습니다.

팀이 빠르게 움직이는 이유는 사람, 명확성, 그리고 프로세스 덕분입니다. 도구는 이러한 것들을 만들어낼 수 없습니다.

올바른 도구는 한 가지 역할을 합니다. 바로 팀이 느려지는 것을 막는 것입니다.

많은 엔지니어링 팀이 잘못된 사이클을 반복합니다. 속도가 느리다고 느끼면 새로운 도구를 구매합니다. 지표를 추적합니다. 결과는 제각각입니다. 그러면 도구가 잘못되었다고 결론짓고 또 다른 도구를 구매합니다.

이 접근 방식은 잘못되었습니다. 속도를 더해줄 도구를 찾아서는 안 됩니다. 마찰(friction)을 제거할 도구를 찾아야 합니다.

속도를 추구하면 기능이 많고 벤치마크 성능이 높은 도구를 사게 됩니다. 이런 도구들은 종종 복잡합니다. 그 자체로 전문 지식을 요구하며, 새로운 마찰을 만들어냅니다.

마찰을 제거하려 한다면, 지루한 도구를 사게 될 것입니다. 한 가지 일을 잘 수행하는 도구를 찾게 됩니다. 현재 스택과 잘 통합되며, 유지보수 부담이 적은 도구 말입니다.

가장 비용이 많이 드는 마찰은 IDE나 CI 플랫폼 내부에 있는 것이 아닙니다. 그것은 도구들 사이의 간극에 존재합니다.

개발자가 코드를 작성합니다. 커밋을 푸시합니다. CI 파이프라인이 실행됩니다. 결과가 채팅 앱에 나타납니다. 사람이 이 도구들 사이에서 정보를 옮길 때마다 시간 손실이 발생합니다.

도구를 개별적으로 평가하는 것을 멈추십시오. 마찰은 단일 도구 안에 있는 것이 아니라, 도구들 사이에 존재합니다.

도구를 선택할 때 다음 네 가지 질문을 던져보십시오:

  • 팀이 정확히 어느 부분에서 시간을 낭비하고 있는가?
  • 그 특정 손실을 해결하기 위해 필요한 최소한의 도구는 무엇인가?
  • 이 도구가 우리가 이미 사용 중인 것과 통합되는가?
  • 시스템이 성장함에 따라 유지보수에 얼마나 많은 노력이 필요할 것인가?

도구의 과잉(tool sprawl)을 피하십시오. 동일한 문제를 해결하는 도구가 너무 많으면 혼란이 생깁니다. 온보딩을 어렵게 만들고 모든 장애 대응 속도를 늦춥니다.

최고의 도구는 보이지 않는 도구입니다. 실행되고, 보고하며, 방해하지 않고 물러나 있습니다. 만약 도구가 기능을 유지하기 위해서만 지속적인 주의를 요구한다면, 그것은 당신에게 도움이 되지 않는 것입니다.

기능을 구매하는 것을 멈추십시오. 마찰을 제거하기 시작하십시오.

출처: https://dev.to/sophielane/software-development-tools-do-not-make-teams-fast-the-right-ones-stop-making-teams-slow-1ci0