2019.08.19

기고 | 애자일 소프트웨어 개발 관리자의 5가지 책임

Isaac Sacolick | InfoWorld
"코딩의 현재와 미래 상태"라는 주제로 지난 15일 오후 12시에 열린 트위터 채팅인 #IDGTECHTalk에 참여했다. 많은 질문과 트윗들이 코딩 언어와 프레임워크에 관한 것이었다. 하지만 필자는 팀들이 목표를 달성하고 모범 사례를 따르고 솔루션에 대한 공동작업을 할 수 있도록 해주는 소프트웨어 개발 관리의 역할에 초점을 맞추기로 했다.

오늘날 많은 회사들은 산하의 자가 생성적 팀들에게 단기적인 작업에 전념하고 신뢰할 수 있는 애플리케이션 출시를 제공할 수 있도록 각종 권한을 주고 있다. 이를 통해 고품질, 저결함, 보안 및 유지보수가 가능한 코드를 기대하는데, 이러한 코드는 사업목표를 충족시키고 기술적 부채도 감소시킨다. 큰 기업들은 에자일 팀들이 여러 개 있고 자체적인 조직 원칙과 표준 사이의 균형을 맞추기 위해 노력하고 있다. 이를 위해서는 경영진과 핵심 팀원들의 역할과 책임을 고려해야 한다.

이 과정에서 소프트웨어 개발 관리자의 역할이 정의되어야 할 필요가 있다. 애자일 개발에는 스크럼 마스터, 제품 소유자 및 팀의 역할에 대한 구체적인 지침이 있지만, 대부분의 관행과 프레임워크는 소프트웨어 개발 관리자에 대해 거의 언급하지 않는다. 

필자가 보기에 소프트웨어 개발 관리자의 업무는 팀원들이 각자의 역할을 훌륭하게 해내고, 표준화된 프로세스와 애자일 원칙 간의 균형을 도모하고, 프레임워크와 모범 사례에 기초한 훌륭한 기술을 제공하도록 돕는 것이라고 바라본다. 
.
애자일 소프트웨어 개발 관리자가 지녀야 할 5가지 구체적인 책임들에 대해 살펴본다. 

제품 소유자와 구현에 따른 장단점 논의
기능과 유저 스토리를 통해 무엇을, 왜 그리고 누구를 위한 것인지 정의해야 한다. 팀이 요구사항과 허용 기준에 대한 이해를 공유하도록 하기 위해서다. 이 때 이상적으로는 기능이나 스토리를 어떻게 구현해야 하는지에 대해 지나치게 규범적(prescriptive)이 되어서는 안 된다.

기능이나 유저 스토리가 지나치게 규범적인 경우, 그것은 개발팀을 구현하는 데 비용이 많이 들거나 확장하기 어려운 특정 구현에 매몰되게 한다. 또 세부사항이 너무 적은 경우 개발 팀은 최종 사용자의 요구와 비즈니스 요구사항을 충족하는 최적의 구현 옵션을 알지 못할 수 있다.

요구사항이 지나치게 규범적인 경우 소프트웨어 개발 관리자는 제품 소유자와 함께 여러 구현 옵션을 식별한 후 설명해야 한다. 각 옵션에는 장점과 상충관계가 있을 수 있으며, 논의를 통해 종종 더 나은 해결책이 도출된다.

또한 유저 스토리가 잘못 정의되었을 때 소프트웨어 개발 관리자는 팀이 그러한 이야기에 몰입하는 것을 막는 한편, 필요한 세부사항 수준에 대해 제품 소유자와 상의해야 한다.

모범사례와 표준을 팀원들에게 이해시키기
모범사례와 표준을 정의하고 공유하는 것은 설계자의 어려운 업무 중 하나지만, 팀이 이를 적절히 이해하고 활용하도록 하기란 대형 소프트웨어 회사에게도 부담스러울 수 있다.

팀에는 표준적인 권장사항과는 다르게 일을 하고 싶어하는 전문가들이 있을 수 있다. 또한 팀은 모범 사례나 코딩 과제에 이러한 모범사례를 적용하는 방법을 완전히 이해하지는 못하고 있을 지도 모르는 경험이 적은 개발자를 보유할 수 있다.

소프트웨어 개발 관리자는 팀원 개개인의 기술과 사고방식을 이해할 필요가 있다. 관리자는 어떤 경기장 뷰에서 구현을 검토하고 적용할 수 있는 모범 사례와 표준을 식별해야 한다. 그리고 나서 그것들을 팀에 번역하여 이해시킬 수 있고, 설계자들과 질문이나 도전을 공유할 수 있다.

혁신 및 기술 부채를 해결하지 못하는 백로그에 도전
제품 소유자는 많은 이해 관계자 및 고객과 협력하여 제품 비전, 로드맵 및 기능 우선 순위를 결정한다. 그들은 더 많은 기능을 수행하고 더 많은 이해당사자들이 우선 순위에 대한 선택에 만족하도록 해야 한다는 상당한 압력에 직면해 있다.

이러한 압박은 종종 기능 오버로드 및 실험, 혁신, 그리고 더 중요한 기술적 부채를 해결할 수 있는 충분한 용량을 갖추지 못한 불균형적인 애자일 백로그로 이어진다.

-> 기고 | 근절이 능사가 아니다··· '기술 부채' 측정 및 관리법

비즈니스에 결정적인 기능성이 빠른 시간 프레임 내에 제공되어야 하는 경우 이러한 불균형이 일부 스프린트와 출시에 필요한 경우가 많다. 그러나 어느 시점에서는 팀들이 특징, 혁신, 기술적 부채 우선순위가 균형을 이루는 평형 상태로 돌아가야 한다.

애자일 백로그에서 대시보드를 개발하는 것은 우선순위를 보다 투명하게 만드는 한 가지 방법이다. 일부 팀들은 기술적 부채를 관리하기 위해 추가적인 거버넌스 및 프로세스를 도입한다. 그러나 어떠한 것도 이러한 거버넌스를 적극적으로 추진하는 지도자가 일선에 있는 것을 대체할 수는 없다. 

소프트웨어 개발 관리자는 그런 일을 해야 하는 사람이다. 그는 팀들이 좌절하고 기술적 부채를 해결하기 위해 추가적인 시간이 필요한 때를 감지할 수 있다. 그는 또한 팀이 더 복잡한 해결책을 구현하기 위해 고군분투하고 실험과 혁신을 위한 시간이 필요한 때도 알고 있다.

정의된 일정에 따라 고품질 출시를 제공하기
아마도 애자일 소프트웨어 개발 관리자의 가장 중요한 책임은 고품질 출시가 예정대로 제공되도록 하는 것이다. 실행이 부실하거나 품질과 일정에 대해 신뢰할 수 없거나 일관성이 없거나 무책임하다고 판단되는 팀은 조직과 업무를 위험에 빠뜨린다.

이러한 문제의 증상이 있을 때 원인을 파악하고 해결하는 것이 애자일 소프트웨어 개발 관리자의 일이다. 많은 소프트웨어 개발 관리자들과 이야기해 보면, 이러한 문제에 대한 일반적인 반응은 다음과 같다. 

- 너무 많은 복잡한 우선순위 때문에 백로그에 걸린 과부하에 대해 제품 소유자를 비난하는 것.
- 진행을 방해하거나 지연시키는 다른 팀 또는 외부 의존성을 파악하는 것.
- 팀에 대한 훈련, 기술, 지식의 부족을 지적함. 
- 기술 부채, 표준의 부족 또는 새로운 아키텍처의 필요성을 지적함.
- 테스트에 대한 추가 투자, CI/CD(연속 통합/연속 제공) 자동화 및 품질을 향상시키거나 오버헤드를 줄이는 기타 구현을 특정화 함. 

이 모든 것들이 어느 정도 적용될 가능성은 있지만, 그렇다고 팀의 성과가 부진할 경우 리더들이 듣고 싶어하는 대답은 아니다. 소프트웨어 개발 관리자는 팀을 정상 궤도에 올려놓기 위해 그들이 어떤 조치를 취할 것인지, 그리고 더 큰 범위 내에서 그들이 통제할 수 있는 것이 무엇인지 고려할 필요가 있다. 이러한 옵션 중 일부는 다음을 포함할 수 있다.

- 팀이 문제를 인식하고 이를 해결하는 데 협력할 수 있도록 소급하여 문제들을 논의
- 생산으로 유출되는 결함에 대한 추가 데이터 검토 및 수집, 요구 사항 및 테스트 격차 파악
- 팀이 품질 기대치를 완전히 이해했는 지 확인하기 위한 스토리 수용 기준 검토.
- 작업에 외부 팀의 투입이 필요한 경우 출시 및 스프린트 사이클에서 초기에 기획 및 소통
- 팀이 궤도에 오를 때까지 더 느린 속도와 더 작은 범위에 집중

다양한 사고와 문제 해결 추진
성공적인 애자일 팀은 팀으로서 협업하고 함께 일하는 방법을 배운다. 스탠드업, 데모, 소급 같은 의식은 팀들이 요구사항을 이해하고, 해결책을 예측하고, 블록을 해결하고, 프로세스를 개선하도록 돕는다. 이러한 의식은 협동의 기초를 만든다. 소프트웨어 개발 관리자는 모든 참가자들로부터 아이디어와 적극적인 기여를 얻어내는 방법을 결정해야 한다.

팀원들은 각기 다른 성격과 전문지식을 가지고 있다. 어떤 사람들은 내성적이고 대화에 기여하는 데 어려움을 겪을 수도 있는 반면에, 다른 사람들은 모임을 지배하는 A형 성격일 수도 있다. 마찬가지로, 경험이 더 많은 개발자들은 문제 해결 세션을 통제하거나 더 발전된 작업에 착수하여 더 많은 젊은 개발자들이 자신의 아이디어를 공유하거나 그들이 성장하도록 돕는 일을 맡는 것을 방해할 수 있다. 

스크럼 마스터는 회의 중에 적극적인 역할을 하여 모든 사람이 기여하고 다양한 사고가 가능하도록 해야 한다. 소프트웨어 개발 관리자는 한 걸음 더 나아가 팀이 팀처럼 행동하고, 서로의 의견을 존중하고, 아이디어를 공유하고, 모든 사람이 참여하고 배울 수 있도록 해야 한다.

경영이라는 게 전부 이런 것 아니겠는가?

* Isaac Sacolick는 애자일, 데브옵스, 데이터 과학을 다룬 ‘Driving Digital: The Leader’s Guide to Business Transformation through Technology’의 저자다. ciokr@idg.co.kr
 



2019.08.19

기고 | 애자일 소프트웨어 개발 관리자의 5가지 책임

Isaac Sacolick | InfoWorld
"코딩의 현재와 미래 상태"라는 주제로 지난 15일 오후 12시에 열린 트위터 채팅인 #IDGTECHTalk에 참여했다. 많은 질문과 트윗들이 코딩 언어와 프레임워크에 관한 것이었다. 하지만 필자는 팀들이 목표를 달성하고 모범 사례를 따르고 솔루션에 대한 공동작업을 할 수 있도록 해주는 소프트웨어 개발 관리의 역할에 초점을 맞추기로 했다.

오늘날 많은 회사들은 산하의 자가 생성적 팀들에게 단기적인 작업에 전념하고 신뢰할 수 있는 애플리케이션 출시를 제공할 수 있도록 각종 권한을 주고 있다. 이를 통해 고품질, 저결함, 보안 및 유지보수가 가능한 코드를 기대하는데, 이러한 코드는 사업목표를 충족시키고 기술적 부채도 감소시킨다. 큰 기업들은 에자일 팀들이 여러 개 있고 자체적인 조직 원칙과 표준 사이의 균형을 맞추기 위해 노력하고 있다. 이를 위해서는 경영진과 핵심 팀원들의 역할과 책임을 고려해야 한다.

이 과정에서 소프트웨어 개발 관리자의 역할이 정의되어야 할 필요가 있다. 애자일 개발에는 스크럼 마스터, 제품 소유자 및 팀의 역할에 대한 구체적인 지침이 있지만, 대부분의 관행과 프레임워크는 소프트웨어 개발 관리자에 대해 거의 언급하지 않는다. 

필자가 보기에 소프트웨어 개발 관리자의 업무는 팀원들이 각자의 역할을 훌륭하게 해내고, 표준화된 프로세스와 애자일 원칙 간의 균형을 도모하고, 프레임워크와 모범 사례에 기초한 훌륭한 기술을 제공하도록 돕는 것이라고 바라본다. 
.
애자일 소프트웨어 개발 관리자가 지녀야 할 5가지 구체적인 책임들에 대해 살펴본다. 

제품 소유자와 구현에 따른 장단점 논의
기능과 유저 스토리를 통해 무엇을, 왜 그리고 누구를 위한 것인지 정의해야 한다. 팀이 요구사항과 허용 기준에 대한 이해를 공유하도록 하기 위해서다. 이 때 이상적으로는 기능이나 스토리를 어떻게 구현해야 하는지에 대해 지나치게 규범적(prescriptive)이 되어서는 안 된다.

기능이나 유저 스토리가 지나치게 규범적인 경우, 그것은 개발팀을 구현하는 데 비용이 많이 들거나 확장하기 어려운 특정 구현에 매몰되게 한다. 또 세부사항이 너무 적은 경우 개발 팀은 최종 사용자의 요구와 비즈니스 요구사항을 충족하는 최적의 구현 옵션을 알지 못할 수 있다.

요구사항이 지나치게 규범적인 경우 소프트웨어 개발 관리자는 제품 소유자와 함께 여러 구현 옵션을 식별한 후 설명해야 한다. 각 옵션에는 장점과 상충관계가 있을 수 있으며, 논의를 통해 종종 더 나은 해결책이 도출된다.

또한 유저 스토리가 잘못 정의되었을 때 소프트웨어 개발 관리자는 팀이 그러한 이야기에 몰입하는 것을 막는 한편, 필요한 세부사항 수준에 대해 제품 소유자와 상의해야 한다.

모범사례와 표준을 팀원들에게 이해시키기
모범사례와 표준을 정의하고 공유하는 것은 설계자의 어려운 업무 중 하나지만, 팀이 이를 적절히 이해하고 활용하도록 하기란 대형 소프트웨어 회사에게도 부담스러울 수 있다.

팀에는 표준적인 권장사항과는 다르게 일을 하고 싶어하는 전문가들이 있을 수 있다. 또한 팀은 모범 사례나 코딩 과제에 이러한 모범사례를 적용하는 방법을 완전히 이해하지는 못하고 있을 지도 모르는 경험이 적은 개발자를 보유할 수 있다.

소프트웨어 개발 관리자는 팀원 개개인의 기술과 사고방식을 이해할 필요가 있다. 관리자는 어떤 경기장 뷰에서 구현을 검토하고 적용할 수 있는 모범 사례와 표준을 식별해야 한다. 그리고 나서 그것들을 팀에 번역하여 이해시킬 수 있고, 설계자들과 질문이나 도전을 공유할 수 있다.

혁신 및 기술 부채를 해결하지 못하는 백로그에 도전
제품 소유자는 많은 이해 관계자 및 고객과 협력하여 제품 비전, 로드맵 및 기능 우선 순위를 결정한다. 그들은 더 많은 기능을 수행하고 더 많은 이해당사자들이 우선 순위에 대한 선택에 만족하도록 해야 한다는 상당한 압력에 직면해 있다.

이러한 압박은 종종 기능 오버로드 및 실험, 혁신, 그리고 더 중요한 기술적 부채를 해결할 수 있는 충분한 용량을 갖추지 못한 불균형적인 애자일 백로그로 이어진다.

-> 기고 | 근절이 능사가 아니다··· '기술 부채' 측정 및 관리법

비즈니스에 결정적인 기능성이 빠른 시간 프레임 내에 제공되어야 하는 경우 이러한 불균형이 일부 스프린트와 출시에 필요한 경우가 많다. 그러나 어느 시점에서는 팀들이 특징, 혁신, 기술적 부채 우선순위가 균형을 이루는 평형 상태로 돌아가야 한다.

애자일 백로그에서 대시보드를 개발하는 것은 우선순위를 보다 투명하게 만드는 한 가지 방법이다. 일부 팀들은 기술적 부채를 관리하기 위해 추가적인 거버넌스 및 프로세스를 도입한다. 그러나 어떠한 것도 이러한 거버넌스를 적극적으로 추진하는 지도자가 일선에 있는 것을 대체할 수는 없다. 

소프트웨어 개발 관리자는 그런 일을 해야 하는 사람이다. 그는 팀들이 좌절하고 기술적 부채를 해결하기 위해 추가적인 시간이 필요한 때를 감지할 수 있다. 그는 또한 팀이 더 복잡한 해결책을 구현하기 위해 고군분투하고 실험과 혁신을 위한 시간이 필요한 때도 알고 있다.

정의된 일정에 따라 고품질 출시를 제공하기
아마도 애자일 소프트웨어 개발 관리자의 가장 중요한 책임은 고품질 출시가 예정대로 제공되도록 하는 것이다. 실행이 부실하거나 품질과 일정에 대해 신뢰할 수 없거나 일관성이 없거나 무책임하다고 판단되는 팀은 조직과 업무를 위험에 빠뜨린다.

이러한 문제의 증상이 있을 때 원인을 파악하고 해결하는 것이 애자일 소프트웨어 개발 관리자의 일이다. 많은 소프트웨어 개발 관리자들과 이야기해 보면, 이러한 문제에 대한 일반적인 반응은 다음과 같다. 

- 너무 많은 복잡한 우선순위 때문에 백로그에 걸린 과부하에 대해 제품 소유자를 비난하는 것.
- 진행을 방해하거나 지연시키는 다른 팀 또는 외부 의존성을 파악하는 것.
- 팀에 대한 훈련, 기술, 지식의 부족을 지적함. 
- 기술 부채, 표준의 부족 또는 새로운 아키텍처의 필요성을 지적함.
- 테스트에 대한 추가 투자, CI/CD(연속 통합/연속 제공) 자동화 및 품질을 향상시키거나 오버헤드를 줄이는 기타 구현을 특정화 함. 

이 모든 것들이 어느 정도 적용될 가능성은 있지만, 그렇다고 팀의 성과가 부진할 경우 리더들이 듣고 싶어하는 대답은 아니다. 소프트웨어 개발 관리자는 팀을 정상 궤도에 올려놓기 위해 그들이 어떤 조치를 취할 것인지, 그리고 더 큰 범위 내에서 그들이 통제할 수 있는 것이 무엇인지 고려할 필요가 있다. 이러한 옵션 중 일부는 다음을 포함할 수 있다.

- 팀이 문제를 인식하고 이를 해결하는 데 협력할 수 있도록 소급하여 문제들을 논의
- 생산으로 유출되는 결함에 대한 추가 데이터 검토 및 수집, 요구 사항 및 테스트 격차 파악
- 팀이 품질 기대치를 완전히 이해했는 지 확인하기 위한 스토리 수용 기준 검토.
- 작업에 외부 팀의 투입이 필요한 경우 출시 및 스프린트 사이클에서 초기에 기획 및 소통
- 팀이 궤도에 오를 때까지 더 느린 속도와 더 작은 범위에 집중

다양한 사고와 문제 해결 추진
성공적인 애자일 팀은 팀으로서 협업하고 함께 일하는 방법을 배운다. 스탠드업, 데모, 소급 같은 의식은 팀들이 요구사항을 이해하고, 해결책을 예측하고, 블록을 해결하고, 프로세스를 개선하도록 돕는다. 이러한 의식은 협동의 기초를 만든다. 소프트웨어 개발 관리자는 모든 참가자들로부터 아이디어와 적극적인 기여를 얻어내는 방법을 결정해야 한다.

팀원들은 각기 다른 성격과 전문지식을 가지고 있다. 어떤 사람들은 내성적이고 대화에 기여하는 데 어려움을 겪을 수도 있는 반면에, 다른 사람들은 모임을 지배하는 A형 성격일 수도 있다. 마찬가지로, 경험이 더 많은 개발자들은 문제 해결 세션을 통제하거나 더 발전된 작업에 착수하여 더 많은 젊은 개발자들이 자신의 아이디어를 공유하거나 그들이 성장하도록 돕는 일을 맡는 것을 방해할 수 있다. 

스크럼 마스터는 회의 중에 적극적인 역할을 하여 모든 사람이 기여하고 다양한 사고가 가능하도록 해야 한다. 소프트웨어 개발 관리자는 한 걸음 더 나아가 팀이 팀처럼 행동하고, 서로의 의견을 존중하고, 아이디어를 공유하고, 모든 사람이 참여하고 배울 수 있도록 해야 한다.

경영이라는 게 전부 이런 것 아니겠는가?

* Isaac Sacolick는 애자일, 데브옵스, 데이터 과학을 다룬 ‘Driving Digital: The Leader’s Guide to Business Transformation through Technology’의 저자다. ciokr@idg.co.kr
 

X