프로젝트 일정관리
- 다음의 항목들을 결정
- 프로젝트 내용을 분리된 작업들로 조직하는 방법
- 각각의 작업들이 실행되는 시점
- 각각의 작업들을 실행할 방법
- 다음의 업무를 수행
- 각각의 작업을 완료하는데 필요한 시간과 노력 추정
- 작업 수행 인원 제안
- 각 작업을 완료하는데 필요한 하드웨어와 소프트웨어 자원들 추정
→ 초기 프로젝트 일정은 프로젝트 시동단계에서 생성되며, 자주 갱신되고 수정됨
계획 주도 및 애자일 프로세스에서의 프로젝트 일정
- 두 경우 다 초기 프로젝트 일정 필요
- 계획 주도 프로젝트
- 프로젝트 관련 업무를 분리된 작업들로 나누고 각각의 작업을 완료하는데 필요한 시간 추정
- 프로젝트 관련 업무를 분리된 작업들로 나누고 각각의 작업을 완료하는데 필요한 시간 추정
- 애자일 프로젝트
- 계획 주도 프로젝트보다는 덜 상세한 내용
- 프로젝트 주요 단계들이 언제 완료될지 식별하는 전반적인 일정이 있어야 함.
- 계획 주도 프로젝트
프로젝트 일정관리 프로세스
프로젝트 일정 관리 주의점
- 여러 개로 나눈 작업들을 조정하고, 작업 능력이 최적으로 사용되게 해야 함
- 여러 개로 나눈 작업들을 병행해서 수행
- 중대한 작업이 완료되지 않아 전체 프로젝트가 지연되는 상황을 피하는 것이 중요
- 작업들 사이에 불필요한 종속성이 생기지 않도록 작업을 편성
- 일정 관리 측면에서 신중하게 접근해야 함
- 프로젝트 수행하면서 지속적으로 최신 진행 정보를 확보하고 일정을 수정해야 함
- 일정을 추정할 때에는 뭔가 일이 잘못될 가능성을 반드시 고려
- 뭔가 일이 잘못될 가능성이 없다는 가정하에 일정을 추산하고,
다음에 예상되는 문제들을 다루기 위한 추정치를 추가하는 방법도 있음
- 비상시에 대비한 추정치는 프로젝트에 필요한 노력과 시간 대비 30~50% 추가 가능
일정 표현
- 프로젝트 일정은 작업, 노력 추정치, 지속기간, 작업 종속성들을 보여주도록 간단히 기록
- 표 또는 스프레드시트를 이용하여 기록
- 표 또는 스프레드시트를 이용하여 기록
- 프로젝트 일정의 그래픽 시각화가 개발됐음 → 읽고 이해하기 쉬워짐
간트 차트(달력 기반의 바 차트)- 각 액티비티의 책임자, 예상 경과 시간, 액티비티들의 시작과 종료를 보여줌
- 각 액티비티의 책임자, 예상 경과 시간, 액티비티들의 시작과 종료를 보여줌
액티비티 네트워크- 프로젝트를 구성하는 여러 액티비티들 사이의 종속성을 보여줌
프로젝트 액티비티
- 기본적인 계획 수립 요소
- 구성요소
- 일 또는 월로 표현되는 소요시간
- 작업을 완료하기 위한 노력 추정치(person-days or person-months로 표기)
- 액티비티가 완료되어야 하는 마감일
- 정의된 종료점
- 문서, 검토 회의의 개최, 모든 테스트의 성공적인 수행 등
- 문서, 검토 회의의 개최, 모든 테스트의 성공적인 수행 등
- 이정표
- 작업의 진도가 검토될 수 있는 프로젝트 단계의 논리적 끝을 의미
- 프로젝트를 계획할 때 프로젝트 이정표를 정의해야 함
- 하나의 작업 혹은 관련된 활동들의 그룹과 연관될 수 있음
액티비티 바 차트
직원 할당 차트
애자일 계획 수립
- 애자일 방법
- 소프트웨어가 증분 단위로 개발되고 고객에게 인도되는 반복적인 접근법
- 증분은 미리 계획되지 않고 개발 중에 결정 → 계획 주도 접근법과의 차이
- 증분은 미리 계획되지 않고 개발 중에 결정 → 계획 주도 접근법과의 차이
- 고객의 우선순위와 요구사항들이 계속해서 변하므로 유연한 계획 수립이 필요
- 소프트웨어가 증분 단위로 개발되고 고객에게 인도되는 반복적인 접근법
- 애자일 계획 수립 2단계 접근법
릴리스 계획 수립- 수개월 앞을 내다보고 시스템의 릴리스에 포함되어야 하는 기능들에 대한 결정
- 수개월 앞을 내다보고 시스템의 릴리스에 포함되어야 하는 기능들에 대한 결정
반복 계획 수립- 단기 전망을 가지고 시스템의 다음 중분에 대한 계획 수립에 집중
- 대개 팀의 2~4주간의 작업을 나타냄
애자일 계획 수립 접근법
- 스크럼 접근법
- 수행된 작업과 문제에 대한 일일 리뷰를 바탕으로 한 프로젝트 백로그 관리
- 반복 계획 수립에 맞추어 조정
- 계획 수립 게임
- 최종 시스템에 포함되는 모든 기능들을 다루는 사용자 스토리의 집합
- 익스트림 프로그래밍의 일부분으로 개발
- 릴리스 계획 수립과 반복 계획 수립 모두에서 사용
계획 수립 게임(스토리 기반 계획 수립)
- 개발팀과 소프트웨어 고객은 스토리들을 개발하기 위해 함께 작업
- 프로젝트 팀은 스토리를 읽고, 토의하고, 순위를 매김
- 구현하는 데 걸리는 시간을 고려하여 순위를 매김
- 필요한 노력과 시간을 정확히 추정하긴 힘들기 때문에 각각의 스토리들을 비교함
- 한 번의 반복으로 구현되기에 너무 큰 스토리는 작은 스토리들로 나눔
- 팀이 하루에 구현하는 노력포인트를 측정 → 이를 팀의 속도로 추정
- 속도 추정치를 구하면 시스템을 구현하기 위해 필요한 총 노력 추정 가능
- 단위 : person-days
릴리스 및 반복 계획 수립
릴리스 계획 수립- 시스템의 한 릴리스에서 구현될 기능과 스토리가 구현되어야 하는 순서를 반영하여
스토리를 선택하고 계량하는 것을 포함 - 릴리스 날짜가 선택되고, 노력 추정치가 이 날짜와 일치하는지 알아보기 위해 스토리를 조사
- 그렇지 않은 경우 스토리들이 추가되거나 목록에서 제거됨
- 그렇지 않은 경우 스토리들이 추가되거나 목록에서 제거됨
- 시스템의 한 릴리스에서 구현될 기능과 스토리가 구현되어야 하는 순서를 반영하여
반복 계획 수립- 동작하는 시스템을 인도하기 위한 시간(2~3주)과 팀의 속도를 반영하여 여러 스토리와 함께,
그 반복동안 구현될 스토리들이 선택됨 - 인도 날짜가 다면 모든 스토리가 구현 안 됐어도 개발 반복 종료
- 팀은 구현된 스토리들을 고려하고 그들의 노력 점수는 증가함
- 속도를 다시 계산할 수 있고, 이 값이 다음 버전의 계획 수립에서 사용
- 동작하는 시스템을 인도하기 위한 시간(2~3주)과 팀의 속도를 반영하여 여러 스토리와 함께,
작업 할당
- 계획 수립 단계에서 스토리를 개발 작업으로 분할
- 하나의 개발 작업은 4 ~ 16시간 정도 소요되어야 함
- 모든 스토리 구현을 위해 반드시 완료되어야 하는 모든 작업들이 나열되어야 함
- 각각의 개발자는 그들이 구현할 수 있는 특정한 작업들을 신청
- 이러한 접근법의 장점
- 전체 팀은 하나의 반복에서 완료되어야 하는 작업들에 대한 전체적인 윤곽을 얻음
- 개발자들은 작업들에 대해 소유의식을 가지며, 작업 완료에 대한 동기부여가 됨
소프트웨어 인도
- 소프트웨어 증분은 매 프로젝트 반복이 끝날 때에 항상 인도됨
- 증분에 포함된 기능이 허락된 시간 이내에 완료될 수 없으면 작업의 범위가 줄어듦
- 인도 일정은 절대 연장되지 않음
← 고객의 계획이 영향을 받을 수 있다는 의미이므로 문제 발생 가능
애자일 계획 수립의 어려움과 적용 가능성
- 애자일 계획 수립의 어려움
- 고객 참여와 이용가능성에 의존
- 일부 고객들은 전통적인 프로젝트 계획에 더 익숙
→ 애자일 계획 수립 프로세스가 어렵게 느껴짐
- 애자일 계획 수립 적용 가능성
- 애자일 계획 수립은 작고 안정적인 개발팀에서 잘 동작
- 대형 프로젝트 → 전통적인 접근법 사용
- 팀이 대규모이고 지리적으로 흩어져 있거나 팀 멤버가 자주 바뀜
→ 애자일 관리에서 필수적인 협력적 계획 수립에 모두 참여하는 것이 불가능
- 팀이 대규모이고 지리적으로 흩어져 있거나 팀 멤버가 자주 바뀜