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