호우동의 개발일지

Today :

article thumbnail

애자일 프로젝트 관리

  • 소프트웨어가 계획된 예산 내에서 기한 내에 개발되어 배포되도록 하는 것
    → 소프트웨어 관리자들의 주요 업무

  • 계획 주도 접근법에서의 관리자들의 역할

  • 애자일 개발은 팀이 사용할 수 있는 시간과 자원을 최대한 잘 이용하도록 애자일 기법을 관리
    • 점증적 개발 및 애자일 방법에 사용되는 방식에 맞게 조정된 접근 방식 필요

 


스크럼

  • 애자일 프로젝트를 조직화하기 위한 프레임워크를 제공,
    진행 중인 내용에 대한 외부 가시화 제공하는 기법

    • 조직에게 애자일 프레임워크를 제공하는데 초점(특정 개발 방법 강요 x)

  • 스크럼 단계
    • 1. 개요 계획 단계: 프로젝트의 일반적인 목표 설정 및 소프트웨어 구조 디자인
    • 2. 일련의 스프린트 사이클들: 각 사이클은 시스템의 증가분을 개발
    • 3. 프로젝트 종료 단계: 필수 문서(도움말 프레임 및 사용자 매뉴얼) 완성 및 프로젝트 리뷰 평가

 


스크럼 용어

  • 개발팀
    • 자체 개발한 소프트웨어 개발 그룹, 7명을 넘기면 안 됨
    • 소프트웨어 및 필수적인 다른 프로젝트 문서 작성에 대한 책임을 가짐

  • 잠재적으로 전달 가능한 제품 증가분
    • 스프린트에서 정한 소프트웨어의 증가분
    • 최종 제품에 포함시키기 위해 추가적인 작업이 필요 없는 완벽한 상태 ← 실무적으로 힘듦

  • 제품 백로그
    • 스크럼 팀이 해결해야 하는 To do List
    • 소프트웨어 특징, 요구사항, 사용자 스토리에 대한 정의,
      아키텍처 정의 등 추가적으로 필요한 업무에 대한 설명 일 수도 있음

  • 제품 소유권자
    • 프로젝트가 지속될 수 있도록 비즈니스 요구를 만족하도록 우선순위를 정하고,
      제품 백로그를 검토하는 역할을 맡은 사람(또는 그룹)

    • 제품 소유권자는 고객일 수도 있지만 소프트웨어 회사의 제품 관리자이거나 다른 이해당사자 대표 일지도

  • 스크럼
    • 매일 이루어지는 전체 팀이 직접 만나서 진행하는 짧은 회의
    • 그날 처리해야 하는 일에 대한 우선순위를 매긴다.

  • 스크럼 마스터
    • 스크럼 프로세스를 따르고, 팀이 스크럼을 효과적으로 활용할 수 있도록 보장하는 역할을 맡는다.
    • 스크럼 마스터는 회사의 나머지와 접점 역할,
      팀이 외부의 간섭에 방해받지 않도록 하는 책임을 가진다.
    • 스크럼 마스터 = 프로젝트 관리자인가? 아닌가 의견 분분함

  • 스프린트
    • 개발에서 이루어지는 반복, 주로 2~4주 길이로 구성

  • 속도
    • 한 번의 스프린트에서 한 팀이 어느 정도의 제품 백로그를 감당할 수 있는지에 대한 추정치
    • 팀의 속도를 이해하면 성과 향상을 측정하기 위한 기초 제공에 도움이 된다.

 


스크럼 스프린트 주기

스크럼 스프린트 주기

  • 각각의 증가분을 반복함으로써, 고객에게 전달할 수 있는 제품의 증가분을 만들게 됨
  • 고정된 길이(보통 2~4주)만큼 진행
    • 정해진 시간 동안 작업을 마치지 못하면, 해당 항목을 다시 제품 백로그를 돌림

  • 제품 백로그
    • 스크럼 스프린트 사이클의 출발점
    • To do List
    • 제품 사용자가 우선순위를 정함

  • 항목 선정
    • 고객과 일하는 프로젝트 팀 전체가 참여
    • 제품 백로그에서 스프린트 동안 개발할 항목들을 선택

  • 스프린트 계획
    • 선택한 항목 처리 완료 시간 예측
      • 이전 스프린트 처리 속도 사용해서 예측

    • 특정 스프린트 동안 처리해야 할 스프린트 백로그 작성

  • 스프린트
    • 팀 스스로 역할을 정해서 스프린트 시작
    • 매일 스크럼 진행
      • 진척도 점검, 업무 우선순위 변경
      • 정보 공유, 이전 미팅 이후 진척 사항 설명, 문제 발생, 계획 공유, 재계획 등

  • 스프린트 검토
    • 스프린트가 끝날 때마다 가지는 점검 미팅
    • 프로세스 개선을 위한 수단 → 진행 방식 점검 및 보완
    • 다음 스프린트에 앞서 선행할 제품의 백로그 점검을 위한 준비

 


스크럼 보드

  • 스프린트 백로그, 완료 작업, 팀원 상황 등에 대한 정보와 포스트잇 노트를 가지고 있는 일종의 칠판
  • 전체 팀이 사용하는 공유 자원 → 누구나 항목 변경 및 사용 가능
  • 팀 사이에서 이뤄지는 상호 작용은 이 보드를 통해 이뤄짐
    → 모든 구성원이 진행상황을 한눈에 알 수 있음

 


스크럼 마스터

  • 일반적으로 관리자 역할 수행
    • 공식 관리자 x
    • 상급 관리자한테 진척 사항 보고
    • 더 장기적 계획이나 프로젝트 예산에도 관여
    • 행정이나 하드웨어/소프트웨어 구매에도 참여

 


스크럼의 장점

  • 제품이 이해당사자들이 관련될 수 있는 관리 가능하고 이해할 수 있는 조각들로 나뉘게 됨
  • 불안정한 요구사항 때문에 지연되지 않음
  • 모든 팀이 모든 것을 볼 수 있고, 결과적으로 팀 의사소통과 의욕 향상
  • 고객은 제때 증가분을 받아 볼 수 있고, 제품 동작 방식에 대한 피드백을 확보
  • 고객과 개발자 사이의 신뢰 형성 → 프로젝트 성공에 대한 기대하는 긍정적 문화 형성

 


분산 스크럼

  • 팀 구성원이 세계 곳곳에 흩어져 있는 경우

분산 스크럼
분산 스크럼

 


다중 팀 스크럼

  • 대규모 시스템에 애자일 시스템을 적용할 때 다중 팀 스크럼 사용
  • 역할 복제
    • 각 팀은 해당 작업 컴포넌트에 대한 제품 소유자와 스크럼 마스터가 있음
    • 전체 프로젝트에 대해서 제품 소유자와 스크럼 마스터가 있을 수도 있음

  • 제품 아키텍트
    • 각 팀은 제품 아키텍트를 선발
    • 아키텍트들은 전체 시스템 아키텍처를 설계하고 진화시키기 위해 협업

  • 릴리스 정렬
    • 각 팀은 제품 릴리스 날짜를 정렬하고 데모 시스템과 완전한 시스템을 개발

  • 스크럼의 스크럼
    • 각 팀의 대표가 모여 매일 스크럼의 스크럼 진행
      • 진척사항 논의, 문제점 찾고 업무 계획

    • 개별 팀 스크럼이 시차를 두고 진행되기도 함
      • 필요한 경우 다른 팀의 대표가 참여할 수 있게 함