간단한 개발관련 내용

1. xp란?

- 모호하고 빠르게 변하는 요구사항을 가지고 일을 하는 중소규모 팀을 위한 경량화된 방법론이다.

xp의 특징으로는

* 5명에서 10명 정도로 구성된 프로그래머가 고객과 함께 한 장소에서 일한다.

* 개발은 점진적으로 자주 이뤄지고 각 단계마다 산출물의 기능을 덧붙여 나간다.

* 요구사항 정의 시에는 사용자가 요구하는 새로운 기능을 스토리 형태로 구체적으로 작성한다.

* 프로그래머는 엄격한 코딩 규칙을 준수하고 짝을 이뤄 일하며 단위테스트를 실시한다.

* 요구사항, 아키텍쳐, 디자인은 프로젝트 중간에 언제든지 발생한다.

2. xp의 논쟁거리

- xp에서는 초기에 설계를 끝내고 진행하는 스타일(BUFD, Big Up-Front Design)을 지양한다.

- 짝(pair)프로그래밍

- TDD

3. xp의 무엇이 그토록 익스트림한 요소일까?

- 짝(pair)프로그래밍

- 사용자 기능 테스트.

- 리팩토링

- 가장 단순한 것이 작업을 가능케 한다.

- 메타포어.

- 지속적 통합.

4. xp의 기본 원리

xp의 단순성, 리팩토링, 전반부 설계의 최소화에서 알 수 있듯이, xp는 폭포수 모델이나 다른 방법론에서 기본적으로 갖고 있는 몇 가지 기본개념을 부정한다. xp에서 제공하는 여러 가지 활동(최신 프로그래밍 테크닉, 언어, 도구, 프로젝트 세분화)을 사용해 새롭게 개발되는 애플리케이션들은 비용을 효과적으로 분산할 수 있으며 짧은 주기로 좀더 나은 솔루션을 제공할 수 있다. 전통적인 소프트웨어 개발에서 분석에 많은 시간과 비용을 들였다면 xp에서는 코드를 작성하면서 잘못된 부분을 직접 발견하고 수정하면서 비용을 최소화한다.

5. xp의 가치와 원칙, 활동

- xp의 5가지 핵심 가치

* 의사소통(communication)

* 단순성(simplicity)

* 피드백(feedback)

* 용기(courage)

* 존중(respect)

- 기본원리

* 사람(humanity)

* 반성(reflection)

* 품질(quality)

* 잔걸음(baby step)

- 주요활동 13

* 함께 앉으라(sit together)

* 하나의 팀(whole team)

* 정보를 제공하는 작업공간(informative workspace)

* 열정적인 작업(energized work)

* 짝프로그래밍

* 스토리

* 주 단위 주기

* 사분기 주기

* 느슨함(slack)

* 10분 빌드(ten-minute build)

* 지속적인 통합

* 테스트 우선 프로그래밍

* 점진적인 설계

6.  xp 프로세스 모델

* user stories - 릴리즈할 때까지 앞으로 구현해야 될 기능들을 이야기한다.

* architectural spikes - 팀이 설계를 하거나 리팩토링을 하거나 새로운 기술을 적용실킬 때 그 바탕이 되는 것을 말한다.

위 2가지는 릴리스계획의 입력이 된다. 그리고 반복을 통해 인수테스트(acceptance test)에 이르며 user stories 와 비교되며 기능들이 검사된다. 이 프로세스의 결과로 고객이 제시하는 문제점에 대해 빠르게 대응하여 설명할 수 있는 작은 릴리스들이 나온다.

7. 방법론의 적용성

xp의 큰 프로젝트에서의 적용은 - 풀어야 할 문제의 규모가 작지 않다면, 충분히 작은 크기로 업무를 나눈 다음에 이를 소규모 팀들이 각각 맡아 해결하게 하면 된다.

xp는 끊임없는 의사소통, 협력, 꾸준한 코딩과 테스팅이 필요로 하므로, 기존 방법론에 비해 프로그래머나 테스터의 업무 강도는 훨씬 높으며, 초과 근무가 잦아지면 생산성을 급격히 낮아진다.

스크럼(Scrum)의 핵심 요소

1. 스크럼의 정의

 가. 소규모의 기능협업팀 CFT(Cross Functional Team)들은 30일간의 제품 릴리스를 점진적으로 수행하는 개방된 환경에서 모여 함께 일한다. 이 기간을 스프린트 sprint 라고 한다.

 나. 팀은 스프린트의 목적을 달성하기위해 스스로 방향을 잡고 권한을 갖는다.

 다. 스크럼 마스터 Scrum master 가 팀웍을 북돋운다. 스크럼 마스터는 기술적인 방향은 제시하지 않지만 스크럼의 핵심 원리를 강화하고 방해요인은 제거한다.

 라. 각 스프린트의 우선순위를 정의하는 제품백로그(product backlog)를 통해 작업을 구성한다.

2. 스크럼에서의 역할

 가. Product Owner는 고객의 의견을 대변하고 팀에 관련된 이해관계자의 관심사항을 표명하는 책임을 갖는다. 또한 Product Backlog(제품에 담고자 할 요구사항과 팀이 해야 할 일의 우선순위를 정리한 작업 리스트)를 관리한다.

 나. Scrum Master 는 팀이 목표를 성취하도록 돕고, 팀원 모두에게 Scrum을 지도하며 Scrum 활동과 규칙을 이행하도록 이끈다.

 다. Team은 기능을 구현해야 한다. 개발자, 테스터, 품질보증담당자 그리고 그 외 기능을 구현하고 출하해야 하는 담당자 드 팀 구성원은 업무를 정의하고 분배, 관리하는 작업을 스스로 진행하며, 다른 사람과 수행 업무를 교환하고 협업해야 한다.

3. Scrum 의 철학적 뿌리

 가. accelerated product-development

 나. concurrent engineering

4. Scrum 의 가치와 원리, 활동 6가지

Scrum을 이해하기 위해서는 '완전히 새로운 제품 개발 게임'의 주요 원리와 이것이 스크럼 상황에서 어떻게 적용되는지 이해하는 것이 필수적이다.

 가. 내재된 불안정성 - 관리의 핵심 철학

 나. 자체적으로 조직하는 프로젝트팀 - 자율성, 탁월성, 상호교류 세가지 요건을 갖춰야 한다.

 다. 개발 단계 중첩

 라. 다중 학습 - 다양한 학습기회의 제공은 다면적으로 신속하게 이루어져하 한다.

 마. 세밀한 제어 - 스크럼은 일 단위와 월 단위로 각 프로젝트에 대해 점검할 항목을 제공한다.

 바. 조직적인 학습 전이 - 스크럼팀은 프로젝트팀 외부로부터 학습 전이가 반복적으로 일어난다.

5. Scrum의 핵심 활동

 가. Cross-functional을 기준으로 배치된 8명 이하의 팀은 스프린트 단위로 소프트웨어를 개발한다.

 나 . 스프린트는 고정된 30일의 반복이다. 각 스픤트마다 테스트를 통해 완료된 기능을 사용자에게 점진적으로 릴리스한다.

 다. 스프린트 시 행하는 작업은 고정되어 있다. 일단 스프린트 범위가 확정되면, 개발팀 외에는 추가적인 기능을 넣을 수 없다.

 라. 스스로를 관리하고, 자체적으로 조직을 구성하는 팀을 스크럼 마스터가 관리하고 멘토링한다. 이러한 팀은 각 스프린트마다 성공적인 산출물을 만들어야 한다.

 마. 완료된 모든 작업은 제품 백로그에 기록된다 이 제품 백로그에는 전달해야하는 요구사항, 결함에 의한 과부하를 비롯해 내부 구조와 설계활동도 기록된다.

 바. 제품책임자는 팀의 구성원이며 최우선적으로 외부 고객과 교류할 책임이 있다. 또한 제품 백로그를 개발하고 관리하며 우선순위를 조정한다.

 사. 가장 우선하는 정보 교환 수단은 15분간 열리는 일일 스탠드업 미팅 또는 '일일 스크럼'이다.

 아. 정해진 시간은 철저히 지켜야 한다. 스프린트, 스탠드업 미팅, 릴리스 리뷰 미팅과 같은 일은 모두 제한된 시간 안에 완료해야 한다.

 자. 스크럼에서는 요구사항, 아키텍쳐, 설계가 프로젝트 전반에 걸쳐 잘 드러나야 한다.

6. Scrum의 기본 원리 : 경험적 프로세스 제어

 프로세스가 예측 불가능해서 계획과 예측으로 이뤄진 '정의'를 통한 접근법의 사용이 어려운 경우에는 측정과 조정으로 이뤄진 '경험'을 이용하는 접근법을 선택하는 것이 바람직하다.

 - 가시성(visibility), 정밀검사(inspection), 적응(adaptation)

7. Scrum의 프로세스 모델

 - 경험적 모델(empirical model)

8. Scrum 이 부적합한 경우

 가. 곳곳에 흩어져 있는 대규모의 팀

 나. 팀원에게 권한을 주지 않는 팀 문화

 다. 지속적인 통합과 테스트가 불가능한 프로젝트

 라. 변화를 수용하지 못하는 조직 문화