2020.12.30

애자일 개발 프로세스가 변화해야 한다는 5가지 신호

Isaac Sacolick | InfoWorld
수행 중인 애자일 개발 프로세스(agile development process)를 ‘취약함(fragile)’이나 ‘하이브리드 폭포형’,’가짜 애자일’이라고 부르고 있는가? 애자일 백로그가 요청 대기열이나 작업 보드와 비슷한가? 
 
ⓒ Getty Images Bank

그것이 아니라면 팀의 애자일 개발 프로세스가 그다지 나쁘지 않고, 팀이 적시에 출시하고 있으며, 고객을 만족시키고 있을 수도 있다. 아마도 팀은 애자일 방법론을 성숙시키고, 출시 관리를 공식화하고, 애자일 산정 원칙을 수립하고, 스토리 작성 기준을 개발했을 것이다. 이와 함께 개발팀이 운영팀과 협업하고, 애자일 도구가 버전 제어와 지속적통합/지속적배포(CI/CD) 파이프라인, 관찰 플랫폼(observability platforms)과 통합됐기를 희망한다. 

기업 내 개발 팀이 이 양극단 사이의 어디엔가 속할 가능성이 있다. 많은 애자일 기업이 애자일 관행을 성숙시키고 개선하기 위한 지속적인 프로세스를 가지고 있지만, 때로는 개발 프로세스를 변경해야 한다. 애자일 KPI(Key Performance Indicators)와 데브옵스 지표를 활용해 진행 상황을 파악하고 변경이 필요할 때 신호를 보내는 기업도 있다. 그러나 일부 기업은 조정을 위한 판단 여부를 공식적인 지표보다는 사람과 프로세스에 의존할 수 있다. 

다음은 애자일 개발 프로세스가 변화해야 함을 보여주는 5가지 지표와 필자가 권장하는 조정 사항이다. 


적은 백로그와 불충분한 계획

애자일 팀은 모든 아이디어나 요청, 기술 문제로 백로그가 오염되면 제품 소유자와 스크럼 마스터, 팀이 효율적으로 작업하기 어렵다는 사실을 매우 빨리 파악한다. 팀이 애자일 도구에서 큰 백로그를 유지하는 경우, 레이블이나 태그를 사용해 장/단기 우선순위를 필터링해야 한다. 

더 큰 문제는 팀이 적시 계획을 채택하고 스프린트(Sprints) 시작일에 가까워서야 사용자 스토리의 우선순위를 지정, 작성, 검토, 산정하는 경우다. 시간이 촉박한 상황에서 요구사항에 대한 공통된 이해를 개발하는 것은 훨씬 어렵다. 계획에 전념할 시간이 충분하지 않을 때 팀이 아키텍처와 운영, 기술 표준, 기타 모범 사례를 고려할 가능성은 적다. 더 최악은, 비즈니스 이해 관계자가 목표 결과물이나 중기 로드맵을 모를 경우, 교육과 변경 관리 등의 다운스트림 비즈니스 프로세스를 수용하기 어렵다는 것이다. 

지속적인 애자일 계획과 프로그램 구현 계획, 기타 분기별 계획 관행을 비롯해 백로그를 계획하는 몇 가지 모범 사례가 있다. 이런 관행은 여러 애자일 팀이 서사를 브레인스토밍하고, 기능을 분석하고, 종속성을 확인하고, 사용자 스토리 작성의 우선순위를 정하는데 도움이 된다. 


스프린트와 출시가 약속을 지키지 못한다

필자는 ‘애자일 팀이 스프린트 약속을 지키는 5가지 방법’을 쓴 후 트위터에서 몇몇 사람들로부터 약속이 사라졌고 스크럼(Scrum)에서 칸반(Kanban)으로 옮기는 팀이 증가하고 있다고 들었다.  

스크럼과 칸반이 장점을 갖고 있는 다른 사례를 추천할 때도 있지만, 필자는 애자일 개발 팀이 수용하는 작업에 전념할 것을 강력히 지지한다. 이 약속은 제품 소유자와 이해 관계자에게 누가, 왜, 무엇이 필요한지에 대해 공통된 이해가 있으며, 구현 계획을 정의하기 위해 애자일 팀이 필요하다는 신호를 보낸다. 

약속은 예측을 나타내며, 팀이 지속적으로 목표를 달성하거나 초과할 것으로 예상하는 것은 현실적이지 않다. 애자일 개발 팀이 사용자 스토리를 완료하기 위해 전념할 때, 종종 구현과 팀 종속성(team dependencies), 기술 가정(technology assumptions)과 관련해 여러 가지 알려지지 않은 문제가 종종 발생한다. 

애자일 팀이 지속적으로 약속을 지키지 못할 경우, 변화와 개선을 고려해야 할 때다. 더 적은 수의 스토리에 전념하는 것이 쉬운 해답처럼 보일 수 있지만, 스프린트 또는 출시 기간 내에 요구사항을 충족하기 위한 조정이 문제인 경우에는 아니다. 

최고의 자기조직(self-organizing) 팀은 기대치 충족의 실패를 인식하고, 재점검을 통해 근본 원인을 진단하고 개선에 전념한다. 


참석률이 높은 데모 없이 스프린트 종료

스프린트 검토 회의의 의제는 완성된 사용자 스토리를 제품 소유자와 이해 관계자에게 시연하고 초기 피드백을 수집하는 것이다. 스프린트 리뷰는 참석자가 많아야 하며, 팀은 보여줄 것이 많아야 한다. 

필자가 함께 일해 본 최고의 애자일 팀은 스프린트 리뷰를 극장 공연처럼 했다. 이 애자일 팀은 스토리를 어떻게 시연할지, 그리고 시연을 누가 이끄는지, 언제 순서를 정해야 하고, 어떤 종류의 피드백을 포착해야 하는지 논의한다. 행사 주관자는 스프린트 리뷰가 일정에 맞게 진행되고, 피드백이 포착되며, 이후 장시간의 토론이 이어지도록 보장한다. 

수준 미달의 시연은 다음과 같은 몇 가지 문제를 지적할 수 있다. 
  • 스토리가 사용자 관점에서 작성되지 않아 시연하기가 더 어렵다.
  • 개발자는 진행중인 사용자 경험을 보여주는 것을 염려한다.
  • 팀은 리뷰 직전까지 작업하며 좋은 시연을 진행할 준비가 돼있지 않다. 
  • 제품 소유자는 이해 관계자와 비현실적인 기대치를 설정하고 팀을 시연 중에 곤경에 처하게 한다. 
  • 이해 관계자는 이전의 저조한 성과로 인해 시연에 참석할 가치를 알지 못하거나 자신의 피드백을 귀담아 듣는 사람이 없다고 느낀다. 

스프린트 리뷰는 팀의 발전을 축하하는 시간이어야 한다. 부실하거나 참석률이 저조한 시연은 팀 사기 문제로 이어질 수 있다. 


프로덕션에서 발견되는 결함 증가

많은 애자일 개발 팀이 테스트를 자동화하고, CI/CD 파이프라인을 구성하며, 인프라를 코드로 배포해 릴리즈의 안정성을 개선하고, 프로덕션 변경사항을 더 자주 배포한다. 더욱 발전된 기업일수록 시프트 레프트(Shift-left) 테스트 전략과 성숙한 데브옵스(Devops)를 사용해 개발 프로세스 초기에 보안을 포함한다. 

배포를 자주 할수록 사용자 만족도가 높아지고 기술 종속성 문제가 줄어든다는 것이 일반적인 생각이다. 2020년 데브옵스 현황 보고서에 따르면, 높은 발전을 이룬 엔지니어링 기반 기업의 45%는 온디맨드 배포 빈도를 수행한다고 주장하고, 38%는 변화를 위한 리드 타임이 하루가 채 되지 않는다. 더 보수적이고, 운영적으로 성숙하며, 거버넌스 중심의 기업은 비율이 낮다.

잦은 배포는 그렇지 않을 때까지 의미가 있다. 애자일 개발 팀이 너무 자주 배포하고 있다는 명확한 지표는 프로덕션에서 발견되는 결함이 증가하는 경우다. 

프로덕션 결함은 비즈니스 성과에 영향을 미칠 수 있으며 기업이 버그투성이 소프트웨어 배포로 악명을 쌓을 경우 매우 문제가 된다. 또한 개발 팀이 주요 프로덕션 사고에 대응하고, 긴급 문제 해결 릴리즈를 예약하거나, 다른 우선 순위 대신 결함 수정을 우선해야 하는 경우에도 어려운 문제다. 

프로덕션에서 발견하는 결함이 증가하는 팀은 근본 원인을 논의하고 해결책을 찾아야 한다. 대부분의 경우, 백로그를 조기에 계획하고, 요구 사항을 개선하며, 테스트 자동화에 투자하고, 다양한 테스트 데이터를 늘리거나, 지속적인 테스트를 계측하는 모든 단계는 프로덕션 결함을 줄이는데 도움이 된다. 


애자일 팀이나 이해 관계자의 불만족

변화를 고려하는 가장 중요한 요소는 애자일 팀이나 이해 관계자가 만족하지 않는 경우다.

스프린트 혹은 심지어 릴리즈를 놓쳤다고 해서 변화의 신호를 알리는 것은 아니지만, 리더는 피드백을 공식적으로 포착하기 위한 접근방식을 정의해야 한다. 일대일 대화도 도움이 되지만, 대기업은 고객 만족도와 애자일 팀원의 설문조사를 고려해야 한다. 

통제할 수 없는 문제로 인해 장애를 안고있는 팀을 찾는다. 애자일 팀 간에 종속성이 너무 많거나, 사람이나 역량, 기술, 공급업체가 실행 능력을 방해하는 경우 장기간 해결되지 않는 문제가 팀의 만족도에 영향을 미칠 수 있다. 

불만족한 이해 관계자 역시 똑같이 우려할만한 원인이다. 불만족은 지나치게 높은 기대치나 낮은 배포 품질, 애자일 팀과의 협업을 벗어난 작업 현실로 인해 발생할 수 있다. 필자의 경험상, 행복한 애자일 팀은 이해 관계자의 만족도와 관련이 있다. 사람들이 좌절감을 느끼면 적절한 변화에 귀를 기울이고 우선할 때다. 

가장 좋은 방법 가운데 하나는 애자일 팀이 프로세스와 원칙, 협업, 표준에 대한 점진적인 조정을 찾고 우선순위를 정하는 것이다. 애자일 기업이 더 작은 수정을 추구할수록 더 어려운 문제를 피할 수 있다. 바로 그것이 애자일의 전부다. editor@itworld.co.kr 


2020.12.30

애자일 개발 프로세스가 변화해야 한다는 5가지 신호

Isaac Sacolick | InfoWorld
수행 중인 애자일 개발 프로세스(agile development process)를 ‘취약함(fragile)’이나 ‘하이브리드 폭포형’,’가짜 애자일’이라고 부르고 있는가? 애자일 백로그가 요청 대기열이나 작업 보드와 비슷한가? 
 
ⓒ Getty Images Bank

그것이 아니라면 팀의 애자일 개발 프로세스가 그다지 나쁘지 않고, 팀이 적시에 출시하고 있으며, 고객을 만족시키고 있을 수도 있다. 아마도 팀은 애자일 방법론을 성숙시키고, 출시 관리를 공식화하고, 애자일 산정 원칙을 수립하고, 스토리 작성 기준을 개발했을 것이다. 이와 함께 개발팀이 운영팀과 협업하고, 애자일 도구가 버전 제어와 지속적통합/지속적배포(CI/CD) 파이프라인, 관찰 플랫폼(observability platforms)과 통합됐기를 희망한다. 

기업 내 개발 팀이 이 양극단 사이의 어디엔가 속할 가능성이 있다. 많은 애자일 기업이 애자일 관행을 성숙시키고 개선하기 위한 지속적인 프로세스를 가지고 있지만, 때로는 개발 프로세스를 변경해야 한다. 애자일 KPI(Key Performance Indicators)와 데브옵스 지표를 활용해 진행 상황을 파악하고 변경이 필요할 때 신호를 보내는 기업도 있다. 그러나 일부 기업은 조정을 위한 판단 여부를 공식적인 지표보다는 사람과 프로세스에 의존할 수 있다. 

다음은 애자일 개발 프로세스가 변화해야 함을 보여주는 5가지 지표와 필자가 권장하는 조정 사항이다. 


적은 백로그와 불충분한 계획

애자일 팀은 모든 아이디어나 요청, 기술 문제로 백로그가 오염되면 제품 소유자와 스크럼 마스터, 팀이 효율적으로 작업하기 어렵다는 사실을 매우 빨리 파악한다. 팀이 애자일 도구에서 큰 백로그를 유지하는 경우, 레이블이나 태그를 사용해 장/단기 우선순위를 필터링해야 한다. 

더 큰 문제는 팀이 적시 계획을 채택하고 스프린트(Sprints) 시작일에 가까워서야 사용자 스토리의 우선순위를 지정, 작성, 검토, 산정하는 경우다. 시간이 촉박한 상황에서 요구사항에 대한 공통된 이해를 개발하는 것은 훨씬 어렵다. 계획에 전념할 시간이 충분하지 않을 때 팀이 아키텍처와 운영, 기술 표준, 기타 모범 사례를 고려할 가능성은 적다. 더 최악은, 비즈니스 이해 관계자가 목표 결과물이나 중기 로드맵을 모를 경우, 교육과 변경 관리 등의 다운스트림 비즈니스 프로세스를 수용하기 어렵다는 것이다. 

지속적인 애자일 계획과 프로그램 구현 계획, 기타 분기별 계획 관행을 비롯해 백로그를 계획하는 몇 가지 모범 사례가 있다. 이런 관행은 여러 애자일 팀이 서사를 브레인스토밍하고, 기능을 분석하고, 종속성을 확인하고, 사용자 스토리 작성의 우선순위를 정하는데 도움이 된다. 


스프린트와 출시가 약속을 지키지 못한다

필자는 ‘애자일 팀이 스프린트 약속을 지키는 5가지 방법’을 쓴 후 트위터에서 몇몇 사람들로부터 약속이 사라졌고 스크럼(Scrum)에서 칸반(Kanban)으로 옮기는 팀이 증가하고 있다고 들었다.  

스크럼과 칸반이 장점을 갖고 있는 다른 사례를 추천할 때도 있지만, 필자는 애자일 개발 팀이 수용하는 작업에 전념할 것을 강력히 지지한다. 이 약속은 제품 소유자와 이해 관계자에게 누가, 왜, 무엇이 필요한지에 대해 공통된 이해가 있으며, 구현 계획을 정의하기 위해 애자일 팀이 필요하다는 신호를 보낸다. 

약속은 예측을 나타내며, 팀이 지속적으로 목표를 달성하거나 초과할 것으로 예상하는 것은 현실적이지 않다. 애자일 개발 팀이 사용자 스토리를 완료하기 위해 전념할 때, 종종 구현과 팀 종속성(team dependencies), 기술 가정(technology assumptions)과 관련해 여러 가지 알려지지 않은 문제가 종종 발생한다. 

애자일 팀이 지속적으로 약속을 지키지 못할 경우, 변화와 개선을 고려해야 할 때다. 더 적은 수의 스토리에 전념하는 것이 쉬운 해답처럼 보일 수 있지만, 스프린트 또는 출시 기간 내에 요구사항을 충족하기 위한 조정이 문제인 경우에는 아니다. 

최고의 자기조직(self-organizing) 팀은 기대치 충족의 실패를 인식하고, 재점검을 통해 근본 원인을 진단하고 개선에 전념한다. 


참석률이 높은 데모 없이 스프린트 종료

스프린트 검토 회의의 의제는 완성된 사용자 스토리를 제품 소유자와 이해 관계자에게 시연하고 초기 피드백을 수집하는 것이다. 스프린트 리뷰는 참석자가 많아야 하며, 팀은 보여줄 것이 많아야 한다. 

필자가 함께 일해 본 최고의 애자일 팀은 스프린트 리뷰를 극장 공연처럼 했다. 이 애자일 팀은 스토리를 어떻게 시연할지, 그리고 시연을 누가 이끄는지, 언제 순서를 정해야 하고, 어떤 종류의 피드백을 포착해야 하는지 논의한다. 행사 주관자는 스프린트 리뷰가 일정에 맞게 진행되고, 피드백이 포착되며, 이후 장시간의 토론이 이어지도록 보장한다. 

수준 미달의 시연은 다음과 같은 몇 가지 문제를 지적할 수 있다. 
  • 스토리가 사용자 관점에서 작성되지 않아 시연하기가 더 어렵다.
  • 개발자는 진행중인 사용자 경험을 보여주는 것을 염려한다.
  • 팀은 리뷰 직전까지 작업하며 좋은 시연을 진행할 준비가 돼있지 않다. 
  • 제품 소유자는 이해 관계자와 비현실적인 기대치를 설정하고 팀을 시연 중에 곤경에 처하게 한다. 
  • 이해 관계자는 이전의 저조한 성과로 인해 시연에 참석할 가치를 알지 못하거나 자신의 피드백을 귀담아 듣는 사람이 없다고 느낀다. 

스프린트 리뷰는 팀의 발전을 축하하는 시간이어야 한다. 부실하거나 참석률이 저조한 시연은 팀 사기 문제로 이어질 수 있다. 


프로덕션에서 발견되는 결함 증가

많은 애자일 개발 팀이 테스트를 자동화하고, CI/CD 파이프라인을 구성하며, 인프라를 코드로 배포해 릴리즈의 안정성을 개선하고, 프로덕션 변경사항을 더 자주 배포한다. 더욱 발전된 기업일수록 시프트 레프트(Shift-left) 테스트 전략과 성숙한 데브옵스(Devops)를 사용해 개발 프로세스 초기에 보안을 포함한다. 

배포를 자주 할수록 사용자 만족도가 높아지고 기술 종속성 문제가 줄어든다는 것이 일반적인 생각이다. 2020년 데브옵스 현황 보고서에 따르면, 높은 발전을 이룬 엔지니어링 기반 기업의 45%는 온디맨드 배포 빈도를 수행한다고 주장하고, 38%는 변화를 위한 리드 타임이 하루가 채 되지 않는다. 더 보수적이고, 운영적으로 성숙하며, 거버넌스 중심의 기업은 비율이 낮다.

잦은 배포는 그렇지 않을 때까지 의미가 있다. 애자일 개발 팀이 너무 자주 배포하고 있다는 명확한 지표는 프로덕션에서 발견되는 결함이 증가하는 경우다. 

프로덕션 결함은 비즈니스 성과에 영향을 미칠 수 있으며 기업이 버그투성이 소프트웨어 배포로 악명을 쌓을 경우 매우 문제가 된다. 또한 개발 팀이 주요 프로덕션 사고에 대응하고, 긴급 문제 해결 릴리즈를 예약하거나, 다른 우선 순위 대신 결함 수정을 우선해야 하는 경우에도 어려운 문제다. 

프로덕션에서 발견하는 결함이 증가하는 팀은 근본 원인을 논의하고 해결책을 찾아야 한다. 대부분의 경우, 백로그를 조기에 계획하고, 요구 사항을 개선하며, 테스트 자동화에 투자하고, 다양한 테스트 데이터를 늘리거나, 지속적인 테스트를 계측하는 모든 단계는 프로덕션 결함을 줄이는데 도움이 된다. 


애자일 팀이나 이해 관계자의 불만족

변화를 고려하는 가장 중요한 요소는 애자일 팀이나 이해 관계자가 만족하지 않는 경우다.

스프린트 혹은 심지어 릴리즈를 놓쳤다고 해서 변화의 신호를 알리는 것은 아니지만, 리더는 피드백을 공식적으로 포착하기 위한 접근방식을 정의해야 한다. 일대일 대화도 도움이 되지만, 대기업은 고객 만족도와 애자일 팀원의 설문조사를 고려해야 한다. 

통제할 수 없는 문제로 인해 장애를 안고있는 팀을 찾는다. 애자일 팀 간에 종속성이 너무 많거나, 사람이나 역량, 기술, 공급업체가 실행 능력을 방해하는 경우 장기간 해결되지 않는 문제가 팀의 만족도에 영향을 미칠 수 있다. 

불만족한 이해 관계자 역시 똑같이 우려할만한 원인이다. 불만족은 지나치게 높은 기대치나 낮은 배포 품질, 애자일 팀과의 협업을 벗어난 작업 현실로 인해 발생할 수 있다. 필자의 경험상, 행복한 애자일 팀은 이해 관계자의 만족도와 관련이 있다. 사람들이 좌절감을 느끼면 적절한 변화에 귀를 기울이고 우선할 때다. 

가장 좋은 방법 가운데 하나는 애자일 팀이 프로세스와 원칙, 협업, 표준에 대한 점진적인 조정을 찾고 우선순위를 정하는 것이다. 애자일 기업이 더 작은 수정을 추구할수록 더 어려운 문제를 피할 수 있다. 바로 그것이 애자일의 전부다. editor@itworld.co.kr 


X