|
필자는 최근 “코딩의 현재와 미래”를 주제로 열린 트위터 채팅 #IDGTECHTalk에 참여했다. 코딩 언어와 프레임워크에 대한 많은 질문과 트윗이 오갔는데, 필자는 팀이 목표를 달성하고 모범사례를 따르고 솔루션을 위해 협업하도록 하는 소프트웨어 개발 관리의 역할에 초점을 맞췄다.
많은 조직은 자체적인 팀이 모든 스프린트를 커밋하고 안정적인 애플리케이션 릴리스를 제공하도록 지원한다. 조직은 품질이 높고 결함은 적으며 안전하고 유지보수가 용이한 동시에 비즈니스 목표를 충족하고 기술 부채(technical debt)를 줄이는 코드를 기대한다. 여러 애자일 팀을 보유하고 표준과 자기 조직화 원칙 사이에 균형을 잡고자 하는 대규모 조직은 관리자와 주요 팀원들의 역할과 책임을 고려해야 한다.
이를 위해서는 소프트웨어 개발 관리자의 역할을 명확히 규정해야 한다. 애자일 개발에는 스크럼 마스터와 제품 소유자, 팀의 역할에 대한 구체적인 가이드라인은 있지만 대부분의 실행안과 프레임워크에서 소프트웨어 개발 관리자에 대한 내용은 거의 없다. 필자가 생각하는 소프트웨어 개발 관리자는 팀원들이 각자의 역할에서 뛰어난 성과를 거두도록 돕고, 표준 프로세스와 애자일 원칙 사이에서 균형을 잡고, 프레임워크와 모범사례를 기반으로 우수한 기술을 제공하는 역할을 수행한다.
애자일 소프트웨어 개발 관리자의 5가지 구체적인 책임은 다음과 같다.
1. 구현 측면의 타협에 대해 제품 소유자와 논의
기능과 사용자 스토리에는 ‘무엇을, 왜, 누구를 위해’가 정의되어야 한다. 그래야 팀이 요구사항과 수락 기준에 대한 이해를 공유할 수 있다. 많은 제품 소유자가 구현상의 세부사항을 포함해 사용자 스토리를 정의하지만, 이상적으로는 기능이나 스토리를 어떻게 구현해야 하는지에 대해 지나치게 지시적이면 안 된다.
기능 또는 스토리가 지나치게 지시적인 경우, 개발 팀은 구현 비용이 높거나 확장이 어려울 수도 있는 특정 구현에 갇히게 된다. 세부사항이 너무 부족한 경우에도 개발 팀이 최종 사용자 요구와 비즈니스 요구사항을 충족하는 최선의 구현 옵션을 이해하지 못할 수 있다.
요구사항이 지나치게 지시적인 경우, 소프트웨어 개발 관리자는 여러 가지 구현 옵션을 파악하고 이를 제품 소유자에게 설명해야 한다. 대부분 각 옵션마다 장점과 타협점이 있고, 토론을 거치면 더 나은 솔루션을 얻게 되는 경우가 많다.
또한 사용자 스토리가 제대로 정의되지 않은 경우 소프트웨어 개발 관리자는 스토리에 대한 팀의 커밋을 막고 제품 소유자와 필요한 세부사항의 수준에 대해 논의해야 한다.
2. 모범사례와 표준을 팀원이 이해할 수 있도록 전달
모범사례와 표준을 정의하고 공유하는 것은 설계자에게 어려운 일이지만 대규모 소프트웨어 조직에서 팀이 모범사례와 표준을 적절히 이해하고 활용하도록 하는 것은 상당히 벅찬 일이 될 수 있다.
경우에 따라 팀에는 표준에서 권장되는 방법과는 다른 방법을 원하는 전문가도 있고, 모범사례 또는 모범사례를 코딩에 적용하는 방법을 제대로 이해하지 못하는 경험이 부족한 개발자도 있다.
소프트웨어 개발 관리자는 각 팀원의 스킬과 사고방식을 이해해야 한다. 전체적인 관점에서 구현을 검토하고 어떤 모범사례와 표준을 적용할 수 있는지 파악해야 한다. 그런 다음 팀에 이를 전달하고, 질문 또는 과제를 설계자와 공유할 수 있다.
3. 혁신 및 기술 부채를 다루지 않는 백로그에 문제 제기
제품 소유자는 많은 이해관계자 및 고객과 협력해 제품 비전과 로드맵, 기능 우선순위를 결정한다. 제품 소유자는 자신이 선택한 우선순위로 더 많은 기능을 구현하고 더 많은 이해관계자를 만족시켜야 한다는 크나큰 부담에 직면한다.
이 부담은 기능은 넘쳐나면서 실험과 혁신, 그리고 더 중요한 기술 부채 해결을 위한 공간은 부족한, 균형이 맞지 않는 애자일 백로그로 이어지는 경우가 많다.
비즈니스를 위한 핵심 기능을 신속하게 제공해야 하는 일부 스프린트와 릴리스에서는 이 불균형이 필요한 경우도 있다 그러나 어느 시점이 되면 팀은 기능과 혁신, 기술 부채의 우선순위가 고르게 균형을 이룬 상태로 되돌아가야 한다.
애자일 백로그에 대한 대시보드를 개발하는 것은 우선순위를 더 투명하게 하는 방법 중 하나다. 일부 팀은 기술 부채를 관리하기 위한 부가적인 거버넌스 및 프로세스를 도입하기도 한다. 그러나 최전선에서 리더가 이 거버넌스를 적극적으로 추진하는 것이 무엇보다 중요하다.
소프트웨어 개발 관리자가 바로 그 사람이다. 소프트웨어 개발 관리자는 팀이 좌절감을 느끼고 기술 부채에 대처할 부가적인 시간이 필요한 시점을 감지할 수 있다. 또한 팀이 더 복잡한 솔루션을 구현하기 위해 애쓸 때와 실험과 혁신을 위한 시간이 필요할 때도 안다.
4. 정해진 일정에 따라 고품질 릴리스 제공
애자일 소프트웨어 개발 관리자의 가장 중요한 책임은 고품질의 릴리스가 일정에 맞게 제공되도록 보장하는 것이다. 실행 능력이 떨어지거나 불안정하고 비일관적이거나 품질 및 기한에 무책임한 팀과 스쿼드는 조직과 스스로의 일자리를 위험에 빠트린다.
이러한 문제의 증상이 발생할 때 원인을 파악하고 해결하는 것이 애자일 소프트웨어 개발 관리자가 할 일이다. 소프트웨어 개발 관리자와 대화를 해보면 많은 관리자는 이런 문제에 대한 다음과 같이 반응한다.
- 백로그에 복잡한 우선순위를 너무 많이 집어넣은 제품 소유자를 비난한다.
- 진행을 막거나 속도를 느리게 하는 다른 팀 또는 외부 종속성을 찾는다.
- 팀의 교육, 스킬 또는 지식 부족을 지적한다.
- 기술 부채, 표준의 부재 또는 새로운 아키텍처의 필요성을 지적한다.
- 테스트, CI/CD(지속적 통합/지속적 전달) 자동화, 기타 품질을 개선하거나 오버헤드를 줄이는 구현을 위한 투자의 추가 필요성을 언급한다.
대부분의 경우 앞의 모든 이유가 어느 정도는 적용되지만, 팀의 성과가 떨어질 때 경영진이 듣고자 하는 답은 아니다. 소프트웨어 개발 관리자는 어떤 조치를 취해야 하는지, 그리고 더 넓은 범위에서 자신이 통제할 수 있는 부분이 무엇인지를 고려해서 팀을 정상 궤도로 돌려놓아야 한다. 이를 위한 방법은 다음과 같다.
- 회고에서 문제를 논의해 팀이 문제를 인지하고 해결을 위해 협력하도록 한다.
- 잡히지 않고 프로덕션까지 빠져나간 결함에 대해 더 많은 데이터를 검토, 수집하고 요구사항을 식별하고 간극을 테스트한다.
- 스토리 수락 기준을 점검해 팀이 품질 기대치를 완전히 이해하도록 한다.
- 작업에 외부 팀의 의견이 필요할 때는 릴리스 및 스프린트 사이클의 조기에 계획해 전파한다.
- 팀이 정상 궤도로 복귀할 때까지 커밋 속도를 늦추고 범위를 좁힌다.
5. 다양한 사고와 문제 해결 유도
성공적인 애자일 팀은 팀으로 협업하고 함께 일하는 방법을 배운다. 스탠드업, 데모, 회고와 같은 절차는 팀이 다 같이 요구사항을 이해하고 솔루션을 추정하고 장애물을 치우고 프로세스를 개선하는 데 도움이 된다. 이런 절차는 협업의 토대를 만든다. 소프트웨어 개발 관리자는 모든 참가자로부터 아이디어와 능동적인 기여를 이끌어낼 방법을 정해야 한다.
팀원마다 성격과 전문성은 제각기 다르다. 내성적이고 대화 참여에 어려움을 느끼는 팀원도 있고, 분위기를 이끄는 외향적인 팀원도 있다. 같은 맥락에서 고참 개발자가 문제 해결 세션을 주도하고 더 고차원적인 작업을 맡는 사이, 신참 개발자는 자신의 아이디어를 표현하거나 자신의 성장에 필요한 작업을 맡는 데 어려움을 느낄 수 있다.
스크럼 마스터는 회의 중 적극적인 역할을 맡아 모든 팀원이 기여하도록 하고 다양한 사고방식을 독려해야 한다. 소프트웨어 개발 관리자는 여기서 한 걸음 더 나아가 팀이 하나의 팀으로 모두가 서로의 의견을 존중하고 아이디어를 공유하며 참여하고 학습하도록 해야 한다.
결국 이게 관리의 핵심이기도 하다. editor@itworld.co.kr
|
