프로젝트 계획 요령

>Waterfall 방식

  - 프로세스들이 선행적이고 유기적으로 연결되어 있기 때문에 중간에 발생하는 문제를 해결하는데 어려움이 있다.

  (실제로 프로젝트에 들어가면 이 방식은 거의 쓰지 않는다)

  - 고객과의 커뮤니케이션 문제(ex. HTS)

  - 만들어 놓고 전화 받는게 일이 될 수 있음

  - FEP, 백오피스와 같이 고객과 크게 연관성이 없는 프로젝트에 한해서 유용한 방식

>Incremental development

  - waterfall 방식의 프로세스들을 순환하면서 반복한다.

  - 프로세스들이 더이상 진행할 것이 없으면 완료

  - 고객의 즉각 요구에 대응하기 용이하다(사용자 feedback)

  - 거쳐야 할 과정을 실시간으로 진행하기 때문에 고객이 '됐다'라고 하면 그들에게 제공할 수 있는 상태가 되었다고 

    생각하면 됨

  

  문제점

  - 작은 사이클을 계속 돌리고 있기 때문에 현재 프로젝트의 진행상황을 잘 관리해야한다

    (따라서 그때 그때의 산출물을 내놓아야 함)

  - 정기적인 refactoring([IT관련 잡지식] - 용어 간단 정리)이 필요하다

>Requirments vs Coding

  코딩은 20%로 하고 80%를 고객의 요구사항 분석에 주력해야함

>Agile 방법론

  - 반복 점진적

  - 자기 조직화 : 역할이 따로 정해져 있는 것이 아니라 팀원이 뭘하면 좋을 지 서로 의논하면서 유동적으로 하는 것

  - 교차 기능팀 : 하나의 역할만 하는 것이 아니라 멀티플레이어가 되는것

  - 고객중심(vs 계획중심)

  - 작은 릴리즈(vs 빅뱅 릴리즈) : 항상 테스트 할 수 있게 개발

  - 동작하는 SW 중심(vs 산출물 중심) : 고객은 프로그램 코딩을 보는 것이 아니라 프로그램의 버튼 색깔을 보고 평 

                                                      가한다.

  가장 적합한 두가지 방법

  - SCRUM

    

(SCRUM을 한눈에 알 수 있는 그림)

    - 제품책임자 : 제품에 대한 설명

    - 스크럼 마스터 : 프로젝트 진행에 발생하는 문제(술, 배고픔 등등) PM같이 쪼는 역할은 아니다

    - 스크럼 팀 : 테스팅

    * 이 역시 유동적으로 서로의 역할이 바뀔 수 있다.

    - 스프린트 : 반복개발기간(1~4주단위)

    - 세가지 미팅

      - 스프린트 계획 : 각 스프린트 목표 설정, 제품 백로그 부터 스프린트에서 진행할 항목 선택

      - 일일 스크럼 : 15분간 매일 프로젝트 진행상황 공유

      - 스프린트 리뷰 : 스프린트 목표 달성했는지 작업진행과 결과물을 확인하는 회의

    - 세가지 산출물

      - 제품 백로그 : '고객이 요구했던것이 무엇이냐' 이를 통해 우선순위를 도출

      - 스프린트 백로그 : 세부적인 테스크(상대적인 시간으로 나눈다 ex.tcp가 3일 걸리면 다른 테스크는 tcp보다 얼

                                마 더/덜 걸린다)로 나눔

      - 소멸 차트 : 작업량 그래프

(Post it 을 활용한 SCRUM 관리)

(SCRUM 카드 작성요령)

  - eXtreme Programming(XP)