많은 개발자가 자기 조직화된 애자일 팀에 소속돼 혁신적인 솔루션을 개발하는 것을 좋아한다. 이들은 스프린트 리뷰에서 문제 논의, 장애물 해결, 회고, 결과 공유의 필요성도 인지하고 있다.

하지만 개발자는 너무 많은 회의에 참석하거나 제대로 관리되지 않는 회의에 시간을 낭비하는 것을 극히 싫어한다. 쏟아지는 긴급 이메일과 즉흥적인 줌 회의, 잦은 슬랙 메시지는 생산성을 갉아먹을 수 있다. 코딩은 집중이 필요한 작업이다. 산만함은 소프트웨어 결함과 품질 문제로 이어질 수 있다.
 

회의 관행 및 방식 점검

애자일과 스크럼 초창기에는 화이트보드와 포스트잇을 사용해 백로그를 관리했지만 지금은 많은 팀이 지라 소프트웨어(Jira Software)와 digital.ai, 애저 데브옵스(Azure DevOps) 등 애자일 툴로 이런 아날로그 방식을 대체했다. 많은 애자일 전문가가 개방된 공간에 여러 팀이 모여서 작업하는 방식을 선호하지만 지리적으로 분산된 팀 환경에서의 애자일을 위한 지침도 많다.

어쩌면 지금이 바로 하이브리드 환경에서의 회의 방식을 점검해야 할 때일지도 모른다.

링크드인(LinkedIn) 생산성 엔지니어링 부문 부사장 사브리 토진은 “최상의 툴을 사용하는 것은 엔지니어링 및 개발자 커뮤니티에서 중요하며, 개발자의 행복과도 직결된다. 개발자는 중단 없이 작업을 완료하는 것을 선호하기 때문에 하이브리드 환경의 조직은 더욱 매끄러운 하이브리드 작업 경험을 실현하면서 인재를 유인하고 보존하는 툴에 투자해야 한다”라고 말했다.

데브그래프(DevGraph) 최고 제품 책임자인 라비 두두쿠루 역시 토진과 입장을 같이하며 개발 관리자와 제품 소유자, 스크럼 관리자가 회의 관리 방식을 조정해야 하며 시간과 의제를 관리하는 것은 더욱 중요하다고 말했다. 두두쿠루는 “모두가 사무실에서 일했던 시절에는 스탠드업 미팅으로 회의의 효율성을 달성했다. 원격 애자일 및 앱 개발 회의에도 동일한 방법을 적용해야 한다. 목적과 의제가 명확하고 모두가 무엇을 보고해야 하는지를 정확히 알아야 하며, 회의는 적당한 시점에 끝나야 한다”라고 말했다.

두두쿠루는 “주간 회의는 캘린더에 항상 표시해 둬야 하지만, 회의는 필요할 때만 진행하고 개발 작업에 더 많은 시간을 투자해야 한다”라고 말했다.

필자는 이전 기사에서 회의 관리 팁과 하이브리드 작업 모델로 일하는 애자일 및 데브옵스 팀을 위한 몇 가지 권장 사항을 제시했다. 예를 들어, 특히 활성 스프린트 보드에 진행 상황을 수시로 업데이트하는 팀은 슬랙이나 마이크로소프트 팀즈에서 일일 스탠드업을 할 수 있다. 또한, 개발자가 코딩이나 기타 개발 활동에만 온전히 집중할 수 있는 회의 금지 기간을 설정하는 것도 좋다.

하이브리드 회의를 관리하기 위한 기타 권장 사항은 다음과 같다.
 

• 회의 일정을 잡을 때 회의 리더가 의제를 확실하게 정해야 한다.
• 주요 협업자와 의사 결정자만 회의에 초대한다.
• 가능할 때마다 항상 비디오를 켠다.
• 회의 진행 담당자가 모든 참석자에게 의견과 아이디어를 묻도록 한다.
• 회의를 녹화하고 회의록을 작성해 다른 직원이 검토하도록 한다.
• 회의 의사결정과 후속 조치를 파악한다.

툴 사용법의 중요성

하이브리드 작업을 위한 툴 선택이 원격 협업의 간소화를 좌우하는 경우도 있다.

예를 들어, digital.ai의 15번째 연간 애자일 현황(State of Agile) 보고서에 따르면 응답자의 81%가 지라 소프트웨어를 사용하며, 많은 사용자가 스크럼을 관리하기 위해 프로젝트와 보드, 백로그를 만든다. 이런 기본적인 툴은 애자일 팀이 스프린트와 릴리스를 완료하기 위한 우선순위와 요구사항, 상태를 관리하는 데 도움이 된다. 또한, 고급 로드맵을 사용하고 컨플루언스(Confluence) 페이지에서 지라 이슈를 공유해 제품 소유자 및 이해관계자와의 협업을 개선하는 기회도 된다.

또다른 방법은 로우코드 및 노코드 툴을 사용해 애플리케이션, 대시보드, 데이터 통합 개발의 복잡성을 낮추는 것이다. 이런 툴은 기능을 프로토타입, 개발, 테스트, 배포에 필요한 시간과 협업을 줄이며, 시각적 프로그래밍 방식을 통해 세부적인 구현 문서를 생성할 필요성을 덜어주기도 한다.

나임(KNIME) 수석 데이터 과학자 로사리아 실리포는 “로우코드 툴은 점점 인기를 더 많이 얻고 있으며, 프로토타입을 빠르게 제작할 수 있는 자유를 부여한다. 간단한 앱부터 복잡한 앱 개발까지, 기술 및 기술 외 이해관계자가 단계별로 작업할 수 있는 통합 플랫폼 안에서 협업하도록 한다”라고 말했다.

협업을 개선하고 길거나 잦은 회의의 필요성을 낮추는 기타 툴은 다음과 같다.
 

• 미로(Miro), 발사믹(Balsamiq)과 같은 디자인 툴은 사용자 경험을 구상하고 사용자 인터페이스를 디자인하며, 스크럼에서 디자인 사고가 가능하도록 한다.
• 데브옵스 CI/CD 파이프라인 툴은 빌드를 자동화하고 통합 문제를 보고해 팀이 코드를 진단하고 테스트 이슈에 대처하며, 배포 문제를 해결하는 데 필요한 시간을 줄인다.
• 지속적 테스트 툴은 회귀 테스트를 자동화하고 보안의 시프트-레프트를 실행해 문제가 프로덕션 결함이나 보안 사고로 이어지기 전에 발견되도록 한다.
• 애자일, 데브옵스, IT 서비스 관리 및 기타 IT 워크플로우를 통합하는 툴은 스크럼을 지원하는 팀 간의 협업과 사고 관리, IT 요청 관리 및 기타 서비스 기능을 개선한다.
• AI옵스(AIops) 플랫폼은 데브옵스 팀이 관찰 가능성과 모니터링 데이터를 중앙화하고, 사고를 해결하거나 반복되는 문제의 근본 원인을 해결하는 데 필요한 조율 과정을 간소화한다.

장비도 원격 개발자와 협업을 지원하는 데 있어 중요하다. 리더는 개발자에게 빠른 인터넷 속도와 보안 연결, 강력한 컴퓨팅 리소스, 충분한 비디오 및 오디오 장비가 있는지 확인해야 한다. 회의에서 한 사람이 겪는 기술 및 연결 문제가 모두의 생산성을 저하시킬 수 있기 때문이다.

팀의 툴 사용법을 개선하고 데이터 수집의 일관성을 보장하며, 플랫폼 간의 통합을 더욱 자동화하는 데 목표를 둬야 한다. 개발 팀이 일관된 방식으로 툴을 사용하면 누락된 정보나 낮은 데이터 품질에 관한 회의와 긴 토론의 필요성이 줄어든다.

팬데믹 상황에 따라 더 많은 대면 활동이 가능해지면 리더는 어떤 회의가 현장 참석 인원이 많을수록 유리한지에 대해서도 생각해야 한다. 혁신과 주요 워크플로우 변경, 또는 문제 분류에 대한 브레인스토밍 세션은 보통 회의실에 직접 참석하는 사람이 많을수록 좋다. 하지만 모든 회의마다 원격 참석자가 있을 가능성이 높은 만큼, 회의 진행 담당자는 여전히 이런 점을 감안한 장비와 툴, 진행 방법을 고려해야 한다.

애자일 팀을 위한 마지막 지침은 회고를 통해 협업을 개선하고 회의 시간을 줄이며, 워크플로우 툴 사용을 개선할 방법을 논의해야 한다는 것이다. 현재 상황에 대한 이의 제기에 개방적인 팀일수록 생산성과 개발자의 행복 지수가 향상될 가능성이 더욱 높다. 
editor@itworld.co.kr 

출처 : IT World(https://www.itworld.co.kr/mainnews/229884)