DACI
의사 결정을 위한 애자일 의식은 다씨(DACI)라고 부르는데 팀단위나 그 상위 조직의 의사결정을 효율적이고 효과적으로 할 수 있게 도와준다. 아틀라시안에서는 보통 개발자가 아키텍처의 변경이나 여러 팀에게 영향을 미치는 의사 결정을 할때 사용한다. 다씨는 Driver(드라이버), Approver(승인자, 주로 엔지니어링 매니져 또는 아키텍트 ), Contributors(기여자, 동료 개발자들), Informed(결정 사항을 알아두면 좋은 사람들)로 구성 된다.
1단계는 의사 결정을 추적하기 위한 컨플루언스 페이지를 만든다.
2단계에서는 10분 정도 시간을 할애해 역할을 할당한다. 보통 다씨를 여러번 수행 했고 역할이 대략적으로 이미 정해져있다면 이 단계는 생략 한다.
3단계에서는 드라이버가 각 항목 들을 입력 한다. 모든 항목 들을 반드시 채워넣어야 하는 것은 아니다. 템플릿은 템플릿일뿐 상황에 맞게 응용한다.
- 의사 결정 데드라인
- 결정이 필요한 배후사정, 컨텍스트.
- 현재 상태, 결정중, 결정됨, 연기 등
- 의사 결정을 위해 실행한 관련 조사
- 선택 사항들. 각 항목들의 장단점, 예상 비용 또는 필요한 노력등을 표시한 테이블
- 추천, 기여자들의 추천 사항
- FAQ
이렇게 작성한 페이지를 팀원들에게 공유하고 커멘트를 통해 의견을 받는다. 보통 이와 같은 방식으로 특별한 회의 없이 컨플루언스 페이지 만으로 여러 다양한 의사 결정이 가능하다. 다시는 의사 결정을 효율적이고 신속하게 만들어 줄 뿐만 아니라 기록을 확실히 남김 수 있는 장점도 존재한다. 이는 Github에서 AWR을 작성하는 이유와 비슷하다.
참조
프로젝트 포스터(Project Poster)
서비스를 개발하면서 여러가지 새로운 프로젝트들을 진행하게 되는데 그때 관련 정보의 시작점이 되는 의식이 프로젝트 포스터이다. PO(Project Owner)와 구성원들을 나열한뒤 프로젝트가 풀고자 하는 문제 영역에 대해서 서술한다. 검증(Validation) 영역에서는 현재 알고 있는 것과 모르는 것을 구분한다.
이 문서는 주로 PM이나 PO들이 주로 작성을하는 문서다. 개발자로서 프로젝트 포스터는 사내에 진행되는 프로젝트 들의 개요를 파악하는데 아주 유용한 문서가 된다.
참조
스파링
애자일 스파링은 동료들에게 피드백을 구할 때 사용하는 의식이다. 스파링의 주제는 여러가지가 될 수 있다. 개발시 진행 방법에 대해서도 스파링을 할 수 있지만 주로 스파링의 대상이 되는건 제품이나 디자인 관련된 주제들이 많다. 스파링에 앞서서 참가자들에게 관련 자료 링크를 첨부한다. Garbage In, Garbage out , 입력이 좋아야 출력이 유의미하다. 회의 시간은 30분으로서 다음과 같은 절차를 거친다
1단계는 참가자들에게 원하는 피드백의 수준과 비평받길 원하는 영역에 대해서 언급한다. 예를 들어 너무 세세한 디테일에 신경쓰지 않아도 된다는 언급을 해주면 참석자들의 시간을 아낄 수 있을 것이다. (5분)
2단계는 다루는 주제에 대해 설명한다. 시간이 없으므로 내용은 모두 간략하게. 큰 방향을 잡기 위한 정보만 제공하고 주장을 정당화 하기 위해서 사용하지 않는다. (5분)
3단계는 참가자 들에게 피드백을 받는 시간이다. 참가자들은 직접적인 피드백이나 질문을 포스트잇을 통해 제출한다. 진행은 조용하게 필요한 질문만 한다. 그렇지 않으면 또 시간이 길어진다. (10분)
4단계는 3단계에서 나온 내용들을 가지고 토론하는 시간이다.
5단계는 유의미한 질문이나 피드백을 정리하고 필요한 경우 다음 스파링 세션을 정한다.
스파링에서 다루기 적합한 주제로는 성공에 대한 정의, 문제 영역에 대한 정의, 우선순위등이 될 수 있다. 문제는 발견했지만 어떻게 성공을 정의할 것인가. 수치는 있지만 목표를 어떻게 정해야 할지 모를 때. 스파링을 통해 자신이 보지 못한 답을 얻을수 있을 것이다. 컴포트 존에서 나올 수 있도록 도와주는 것이 애자일 스파링이다.
참조
https://dzone.com/articles/sparring-how-to-get-peer-feedback-you-can-actually
GSD(Get Shit Done)
GSD는 실제 문제 해결에 집중하는 의식이다. Get Stuff Done, Get Things Done등과 같이도 부른다. 내 경험상으로는 GSD를 위해 별도의 문서작성이 필요 하진 않지만 다른 팀원 들을 위해서 GSD가 필요한 이유와 원하는 커뮤니케이션 방법등을 따로 남겨두면 더 좋을 것이다. 현재 팀에서는 주로 월요일을 GSD 하는 날로 정하고 있다. 주말에서 돌아오자마자 플래닝 미팅을 한시간 하게 되면 팀원 들은 보통 괴로워 한다. 그래서 월요일을 GSD로 정해 스프린트를 마무리하고 보통 화요일날 플래닝 미팅과 회고를 진행한다.
참조
팀 상태 모니터
프로젝트 팀의 전반적인 상태를 알아보기 위해 사용하는 의식이다. 팀 멤버들은 각자 주어진 팀 상태 평가에 대해 답을하게 되고 개선이 필요한 영역을 도출하게 된다. 미진한 부분을 개선 시키는 것이 목적이며 해당 영역에서 실행 가능한 방법이 무엇인지 도출할 수 있게 된다.
엘리베이터 피치
진행하는 프로젝트의 일관되고 간단히 설명하기 위해 진행하는 의식. 각 팀원들이 포맷에 맞춰서 입에 달라 붙는 문구를 나열한다. 마지막에 투표를 통해 하나의 통일된 표어를 결정한다.
참고
https://www.atlassian.com/ko/team-playbook/plays/elevator-pitch
5 Why 분석
5 Why 분석은 장애 원인 분석이나 회고(Postmortem)시에 많이 사용하는 의식이다. 이 의식은 실제 문제가 무엇인지 명확히 드러나 있지 않았을 때 5 Why 방법을 사용해 문제 도출을 위해 사용한다.
참고
업무 능력 계획(Capacity Planning)
팀의 처리 능력을 확인하기 위해서 수행하는 의식. 첫번째로 팀원 들에게 각자 1주일 동안 수행하는 업무를 나열하게 한다. 해당 작업에 얼마 만큼의 시간을 소모하는지 예상치를 적는다. 슬랙, 컨플루언스, 이메일, 지라 이슈등을 사용해 최대한 정확히 밑그림을 파악한다.
다음 단계에서는 팀이 1주일에 얼마 만큼의 업무를 수행하는지 테이블로 표현한다. 마지막으로 작성한 테이블을 기반으로 미래나 현재의 프로젝트에 어떻게 사람을 할당해야 할지 판단한다.
참고
https://www.atlassian.com/ko/team-playbook/plays/capacity-planning
교전 규칙(Rule of Engagement)
팀의 규칙들을 명문화 시키는 의식이다. 얼마나 세세하게 어디까지 정할 지는 팀별로 다르다. 먼저 원하는 팀의 방향에 대해서 간단히 토론을 한다. 다음과 같은 내용들을 공유 문서에 정리한다. 이어서 소개하는 ‘나의 사용 매뉴얼’과 함께 사용하면 더욱 효과가 있다.
- 월요일은 회의 금지..
- 코드 리뷰는 어떻게 진행해야 할지
- 어떤 방식으로 피드백을 주고 받을지.
- 팀내 공유 활성화 하기
참고
https://www.atlassian.com/team-playbook/plays/rules-of-engagement
나의 사용 매뉴얼
새로운 팀원이 팀에 들어오거나 하면 나의 사용 매뉴얼을 작성해 공유하는 동료들을 꽤 보았다. 자신의 업무 스타일과 과거 프로젝트 배경들을 아주 가벼운 분위기에서 동료들에게 설명하는 것이다. 이 설명서는 보통 새로 들어오는 팀원별로 아주 각양각생 이기 때문에 동료들에게 조금 더 허물없이 다가갈 수 있도록 도와준다.
첫 만남을 위해서만 사용하는 것은 아니고 매뉴얼을 작성해 블로그 형태로 게시해 두면 다른 팀 사람들도 더욱 쉽게 커뮤니케이션할 수 있을 것이다.
참고
블릿츠 (Blitz)
블릿츠(Blitz, 전격전) 는 말그대로 신속하게 문제를 찾아내기 위해서 진행하는 세션이다. 프로젝트나 기능 완성 후에 QA를 특별히 거치지 않는 상황에서 조금 더 자신감을 가지고 기능을 런칭하기 위해 여러 인원들이 모여서 동시에 사용자 시나리오를 재현하는 의식이다. 보통 드라이버가 블리츠 전에 여러가지 예상 가능한 시나리오들을 정리해 놓는데 참가자들은 해당 시나리오들을 따라가면서 이전에는 보지 못한 버그나 유의미한 피드백등을 발견하게 된다.
참고
워게임 (Wargame)
워게임은 애자일의 의식은 아니지만 장애 시나리오를 미리 예상해보고 팀이 미리 대책을 세울 수 있도록 도와준다. 보통 워게임에 앞서서 1-2시간 정도의 브레인 스토밍 세션을 가진다. 세션에서는 시스템의 다이어그램을 크게 그려 놓고 예상되는 실패 모델과 실험들을 나열한다. 일반적으로 FEMA(Failure Model and Effect Analysis)를 사용한다. 가장 발생할 것 같은 우선순위가 높은 시나리오들을 먼저 실험하게 된다.
댓글을 달려면 로그인해야 합니다.