• 개발 업무 진행상황의 가시성 향상
– 적용 전에는 개발자들이 무슨 일에 보틀넥이 걸려있으며 어떤 애로사항이 있는지 알기 어려워 팀장 입장에서 업무
진행 현황을 일일이 물어보아야 파악 할 수 있었는 데 지금은 타스크 보드와 데일리 미팅을 통하여 일일이 물어보
지 않아도 팀원들이 어떤 문제에 애로사항이 있으며 어떤 업무에 버틀넥이 있는지 쉽게 알개 되었고 당면한 문제
점들을 바로 바로 해결할 수 있게 되었다.
• 통합테스트 단계에서 발생하는 결함 감소
– 평균적으로 QA팀에서 개발팀으로 매달 8~9여건 정도의 크고 작은 재 작업 요청이 있었으나 애자일을 적용하고
나서부터는 1~2건 정도로 줄어든 상태이며 그나마도 마이너한 작업이 되어 품질이 많이 향상되었다.
(70% 이상 감소)
• 개발과정의 효율성이 높아지고 생산성 향상
– 상호간의 협업 증대로 월별 처리건수 향상 (50% 이상 향상)
1. 프로젝트 일정 및 태스크 공수 추정의 신뢰성 부족
• 전형적인 일정 및 공수 추정 형태
– 소수의 개발리더(전문가)를 중심으로 단독 추정
– 경영진및고객이제시한일정에WBS를끼워맞추는형태로일정개발
-
문제점
-
– 리더가 본인이나 잘하는 사람을 기준으로 공수를 추정하다 보니 항상 프로
젝트 공수가 부족
-
– 개인의 편차가 심하며 공수 추정의 신뢰성이 떨어짐
-
– 알려지지 않은(Unknown) 리스크를 고려한 일정 버퍼가 부족
-
애자일 해법
-
– 전문가 집단 추정(Planning Poker ) 기법을 활용하여 평균 공수를 추정함으
로써 추정의 신뢰성을 향상
-
– 평균 공수 추정에 따른 일정 산정과 알려지지 않은(Unknown) 리스크를 고
려한 일정 버퍼 삽입
2. 업무 성과 및 품질 불량으로 관리자와 팀원 간의 갈등 발생
-
전형적인 갈등 상황
-
– 팀원은리더의일방적지시에따라업무를진행하다보니해당업무에대한완
료 기준이 서로 상이함
-
– 태스크초기일정미준수에따른비난이나질책이발생
-
– 팀원이수행한태스크점검시결함이자주발생하는것에실망
-
애자일 해법
-
– 스프린트계획시고객및리더,팀원이함께토론하여해당업무혹은요구사
항에 대한 완료기준을 명확하게 설정함(Test Driven)
-
– 리더는 태스크 일정 수행의 불확실성을 인식하고 태스크 장애요소 해결에 집중
-
– 업무 수행에 대한 책임을 개인 책임보다는 팀 책임으로 설정하고
-
– 완료조건에크로스및QA테스트검증포함
3. 수동적인 팀원들의 자세 및 낮은 사기
-
전형적인 상황
-
– 업무계획시팀원의참여부족
-
– 업무수행의타당성및명확한목표가부재
-
– 대부분의 업무할당이 리더의 일방적 지시로 이루어짐
-
– 리더의 업무 관여로 업무수행의 자율성이 부족
-
– 유지보수 조직은 잘해야 본전
-
애자일 해법
-
– 릴리즈 및 스프린트 계획 시 팀원들이 주도적으로 업무를 계획하게 유도
-
– 스프린트 계획 시 사용자와 개발자가 업무수행의 타당성과 대안을 토론함
-
– 팀원들이 본인들이 잘할 수 있는 업무태스크를 스스로 선택하고 업무를 진행(Self-organizing)
-
– 팀원에게 업무수행의 자율성을 보장하고 리더는 문제해결에만 집중함
-
– 팀원과 함께 스프린트 목표(정성적/정량적)를 설정하고 리더는 이에 대한 피드백을 주기적으로 제공
-
– 주기적인 1:1 팀원 코칭
4. 프로젝트 및 팀 구성원들간의 소통 및 협력 부족
-
전형적인 상황
-
– 리더와 팀원, 리더와 리더간의 업무소통은 활발하게 이루어지나 팀원과 팀원, 타 팀원간의 소통과 협력은 부족
-
– 팀간에 발생하는 이슈 및 문제들이 리더들 미팅을 통해서만 해결됨
-
애자일 해법
-
– 데일리 스탠드업 미팅, 스프린트 리뷰, 회고, 오픈 스페이스 미팅 등을 활용하여 팀원들간의 소통과 협력을 제고
-
– 개인책임이아닌팀책임업무수행
-
– 동료평가 및 절대평가를 통한 팀원간의 협력 증진
5. 요구사항의 불확실성과 잦은 변경
-
전형적인 상황
-
– 고객 요구사항이 초기에 개략적으로 도출되며 제품 구현 후에 자주 변경됨
-
– 요구사항의 불확실성으로 인하여 범위 베이스라인 설정과 변경통제가 어려움
-
애자일 해법
-
– 주어진 일정과 비용 내에서 우선순위가 높은 기능 중심으로 개발
-
– 사용자스토리중심의릴리즈계획과상세태스크중심의스프린트계획으로구분하여전체범위및일정관리
-
– 요구사항에 대한 우선순위 관리와 스프린트 단위로 요구 변경을 통제함
6. 개발 산출물 및 업무 회의 과다
-
전형적인 상황
-
– 고객사혹은내부표준프로세스준수에따른개발산출물과다발생
-
– 고객이나 개발팀에게 의미 없는 산출물이 대량 발생
-
– 수시로발생하는각종업무회의로인하여실제일은저녁에나가능
-
애자일 해법
-
– 고객 및 개발팀에게 실질적으로 가치가 있는 산출물을 정의(유지보수에 필요한 산출물 중심)
-
– 스프린트 회고를 통하여 불필요한 산출물과 회의를 지속적으로 제거
(표준 프로세스는 준수해야 할 프로세스라기보다는 개선해야 할 프로세스로 인식)
-
– 아침회의는 데일리 스탠드업 미팅 시 혹은 이후에 바로 수행함으로써 업무시간과 회의시간을 구분
-
– 회의 방식을 Push 방식에서 Pull 방식으로 전환
7. 고객 및 사용자의 참여 부족
-
전형적인 상황
-
– 현업이 바쁜 관계로 프로젝트 참여가 제한적이며 보통 분석 및 테스트단계에 주로 참여
-
– 많은 경우 요구사항을 명확히 제시하지 못하며 개발자를 과신하는 경향이 있음
-
애자일 해법
-
– 프로젝트 초기에 제품책임자들을 선정하고 이들로 하여금 사용자 의견을 수렴
-
– 스프린트 단위로 사용자들의 피드백을 참조하여 개발
-
– 제품책임자들은 스프린트 계획과 리뷰에 참여하여 개발자들과 개발기간 동안 밀접하게 소통해야 함
-
– 고객과개발팀이활발하게소통할수있는프로젝트관리및커뮤니케이션도구제공
8. 진척상황의 불투명성
• 전형적인 상황
– 주간단위로 팀원들의 업무 진행상황을 점검하고 있으나 팀원들이 현재 어떤 업무에 어려움이 있고 도움이
필요한지 실시간으로 파악하기는 어려움
• 애자일 해법
-
– Visual Task Board를 활용하여 업무진행상황 및 이슈를 실시간으로 파악
-
– 데일리 스탠드업 미팅을 통하여 업무 진행현황과 장애요소, 이슈를 자연스럽게 파악하고 해결
