실패의 원인
요구사항을 초기에 완벽하게 수집하기 어려움
요구사항 수행 결과로 나타나는 새로운 문제점을 예측하기 어려움
문서의 요구사항 간 불일치가 잘 드러나지 않음
주변 상황이 빠르게 변함
Ad-Hoc 방법론
특별한 방법론 없이 개발하는 것을 의미
Code & Fix 방식의 개발이 많음
문제점
일정 추정의 신뢰성이 매우 낮음
재귀 오류가 빈번하게 발생
애자일(Agile)의 출현
요구사항의 불확실성을 기본 전제로 인정
완벽한 문서화 달성 및 요구사항 변경 억제를 목표로 하지 않음
한번에 모든 요구사항을 구현하지 않고, 점진적으로 기능 증가(이를 위해 여러 장치와 원칙 도출)
실제 업무에서 성공적인 실천법들을 정리
애자일 선언
프로세스와 도구보다 개개인과 상호 소통
포괄적인 문서화보다 제대로 동작하는 소프트웨어
계약 협상보다 고객과의 협력
세워진 계획을 따르기보다 변화에 대응
왼쪽 항목을 무시하는 것이 아니라 인정하면서도 오른쪽 항목을 더 중요하게 여기는 것
애자일의 동작 원리
자기조직화(외부의 간섭이 최소화 된 상태로 자발적인 개발)
자발적인 피드백
피드백의 중요성
F-86 vs Mig-15
대등한 성능임에도 F86의 승률이 90%이상
원인을 조종사의 비행 중 행동을 OODA 루프로 설명할 수 있다
루프 수행 정확성보다 루프 수행 빈도가 높아야 유리
루프 수행의 차이를 결정지은 1%의 핵심 : mechanically assisted flight control
Observe -> Orient -> Decide -> Act -> .......
성공도 회귀 분석 (http://agile.egloos.com/5299932)
고객 참여(*, x2, 0.77) |
리팩토링(0.42) |
코딩 후 자동화 테스트 붙이기 (0.38) |
코드 공유 (0.37) |
성숙도 4이하일 때는 고객참여가 0.94를 차지하는 매우 관계 깊은 결과가 있 다
스크럼
제품 개발 프로세스
럭비의 전술 대형 이름에서 유래
자기조직적이고 기민하며 적응적
애자일 프로세스 중 가장 널리 사용됨
Product Backlog -> Sprint Backlog - 이 과정을 2~4주 사이클로 계속 반복 -> Potentially Shippable Product Increment
이 사이에 Daily Scrum Meeting을 24시간 주기로 반복
스크럼의 구성원
제품 책임자 - 제품 백로그를 정할 권한을 가진 한 사람
스크럼 마스터 - 참여자들이 스크럼의 가치, 실천법과 규칙을 이행하도록 하는 사람
스크럼 팀 - 스크럼 목표를 달성하기 위해 헌신할 전문가들로 구성된 팀
기타 이해관계자
프로젝트의 4개 축
기간 - 기능 - 비용 - 품질
4개의 축을 모두 고정할 수는 없음(품질을 움직이면 기간과 기능이 위협받을 수 있음)
품질을 고정하고 기간과 기능 중 하나를 협 상
스크럼 도입의 장점
프로젝트 가시성 증대
막바지에 큰 이슈가 터져 전체 프로젝트를 흔들지 않음
결정한 내용을 언제라도 변경할 수 있음
스크럼이 성공한 이유
규칙이 복잡하지 않다
사람들간의 상호작용을 촉진시킨다
팀 스스로 문제를 해결한다
위험을 조기에 드러내도록한다
프로젝트 가시성이 높다
제품 백로그
구현하고자 하는 모든 기능을 모아 놓은 목록
사용자 스토리 형태로 정리해두면 편함
제품 책임자는 백로그의 각 기능을 우선순위를 매겨 관리
스프린트 계획 회의
스크럼 팀은 이번 스프린트에 소화할 스토리 점수를 선언
스프린트 기간 동안 발생할 이슈(휴가, 워크샵 등)을 감안
지난 스프린트에 소화한 스토리 점수 감안
실제 소화 가능한 스토리 점수를 선언해야 함
제품 책임자는 이번 스프린트에 구현할 기능을 선택
단, 구현할 스토리 점수 총 합은 스크럼 팀이 선언한 스토리 저뭇보다 작거나 같아야 함
소화할 스토리 점수 선언에는 개입해선 안됨
번다운 차트
스토리의 처리 상황을 가시적으로 표현
스프린트 릴리즈
스프린트 기간 동안 구현된 내용 발표
기간 동안 구현한 기능 시연
프로젝트 이해관계자들이 최대한 회의에 참석해야 함
구현된 기능은 사용 가능한 상태여야 함
완료되지 않은 기능은 릴리즈에서 제외
이해관계자들은 제품을 직접 써보며 통찰을 얻음
얻은 통찰을 다음 스프린트 계획에 반영
고객 개발
개발하려는 제품/서비스의 사용자 가설 검증
'~한 사람들이 우리가 만들 서비스를 사용할 것이다'라는 가설
이 가설을 빨리 검증할수록 낭비가 줄어듬
예측한 고객과 실제 고객은 종종 매우 다름
예측과 실제 고객이 달랐다면 원인을 파악해야 함
파악된 원인을 바탕으로 방향성 수정 여부 결정
MVP
Minimal Viable Product (최소 생존 가능 제품)
고객 가설을 확인 가능한 가장 간단한 기능을 가진 제품
피드백을 얻기 위한 첫 단추
Google Analytics
사용자의 이용 행태 분석
사용자 환경 분석
인입/이탈 경로 분석
세그먼트 분할
회고
애자일에서의 회고는 잘한 부분을 계승하고 문제점을 개선하기 위한 행위
개인의 삶에도 적용할 수 있다 (ex일기)
회고의 효과
최종 목표에 과정을 정렬할 수 있다
팀이 느끼는 감정 신호를 체계적으로 풀어낼 수 있다
소프트웨어 품질 관리
품질 확보를 위한 핵심 요소
품질활동은 사람이 한다는 걸 이해해야 한다
품질을 향상시키려면 돈과 시간이 소요된다
그럼에도 불구하고 높은 품질은 달성할 가치가 있다
애자일에서 권장하는 품질 활동
테스트 자동화(Test Automation)
지속적 통합(Continuous Integration)
테스트 주도 개발(Test Driven Development)
짝 프로그래밍(Pair Programming)
코드 리뷰(Code review)
지속적 출시(Continuous Delivery)
기타 등등
모든 활동은 팀의 체력에 맞도록
지속적 통합
코드를 항상 사용 가능한 상태가 되도록 유지하는 활동
보통 CI(Continuous Integration)라고 부름
각 개발자가 코드를 커밋할 때마다 통합 절차를 수행
지속적 통합의 이점
항상 제품이 사용 가능한 상태이기 때문에 이해관계자들이 실물을 보며 의사결정하기 쉬움
조기에 QA 활동을 시작할 수 있음
빅뱅 통합(한꺼번에 통합)으로 인한 리스크 감소
CI 도구
CruiseControl
Hudson
Jenkins (hudson에서 분리되어 만들어진 것. 근래 많이 쓰임)
Bamboo
빌드 시간과 피드백
빌드가 길어지면 피드백이 늦어짐
가급적 10분 이내에 빌드가 가능하도록 해야 함
단계별 빌드(Staged Build)
주간에는 주기적으로 빌드, 단위테스트, 배포만 실행
야간에는 커버리지 검사, 정적 분석, 문서 생성까지 진행
테스트 커버리지
테스트 코드가 대상 코드를 얼마나 빠짐 없이 검사하는지를 나타내는 지표
라인 커버리지
전체 소스 라인 중 테스트 코드 실행 시 수행된 라인 수의 비율
브랜치 커버리지
전체 분기 경우의 수 중 라인 중 테스트 코드 실행 시 수행된 분기의 비율
코드 복잡도
단위 코드(함수/클래스)가 얼마나 복잡하게 짜여 있는지를 나타내는 척도
순환복잡도 수(Cyclomatic Complexity Number) 개념을 사용
분기문/반복문을 만날 때마다 순환복잡도 수가 1씩 증가
여러 번 중첩되어 있거나 조건이 복잡하면 복잡도가 높게 나타남
복잡도가 높은 코드는 결함 발생 가능성이 높음
유지보수에 어려움이 커짐
읽기 어려움
고치기 어려움
복잡도가 높고 커버리지가 낮으면 '건강하지 않은' 코드
리팩토링 순서는 commit이 많이 일어난 것부터 하는 것이 좋다
코드 리뷰
작성한 코드를 동료 또는 전문 리뷰어가 검토하는 절차
코드를 더 낫게 만들거나 코드의 버그를 제거하기 위한 목적
온라인 리뷰를 위한 도구도 있음(하지만 오프라인 리뷰 권장)
팀 전체의 코드 이해 수준을 높이는데 매우 효과적
코드 인스펙션과는 비슷하면서도 다른 활동
코드 리뷰 절차
사전에 코드 리뷰 단위 결정
얼마나 많은 코드를 할지
얼마나 자주 할지
최대 2시간, 최고 400라인을 넘지 않도록 범위 조정
설계 내역과 사전 지식은 미리 별도로 공유
미리 공유가 필요 없을 만큼 팀원 간 이해가 높으면 더 좋음
리뷰어는 코드를 검토하면서 작성자에게 질문
코드 리뷰의 결과로 분명한 action item이 도출되어야 함
팀 수준과 코드 리뷰
팀 수준이 낮을 때 코드 리뷰는 기본적인 체크에 머물게 됨
팀 수준이 고도화되면 설계 영역에까지 이름
더 간결하게
이미 존재하는 해법을 제시하여 재작업 방지
제품 전체의 방향성에 맞춘 설계 영역의 논의 진행
개발 환경 분리
앱의 빌드는 ant/maven/gradle 등으로 자동화 되어 있어야 한다
소스코드에서 직접 대상 서버를 변경하고 재컴파일 하지 않아야 함
서버도 dev/test/stage/production/으로 분리되어 있어야 한다(최소 dev/production 분리)
필요할 때마다 테스트 서버를 추가할 수 있도록 가상화 도입 권장
동시에 여러 브랜치 개발이 진행될 때 유리
단 가급적 여러 브랜치를 동시에 개발하는 일은 지양
Vagrant등을 사용하면 가상화된 테스트 서버 구축 용이
테스트
테스트의 종류
범위에 따라
단위 테스트(unit) - 함수 단위
통합 테스트(Integrated)
시스템 테스트(System)
목적에 따라
회귀 테스트(Regression) - 이전에 발생한 일이 다시 발생했는가
인수 테스트(Acceptance)
접근법에 따라
화이트박스 테스트 - 소스 코드를 놓고 테스트
블랙박스 테스트 - 테스트 하는사람이 코드를 모르고 명세만 아는 경우
그레이박스 테스트 - 구현은 알지만 명세를 이용해 테스트 하는 경우(ex TDD)
단위 테스트
개발중인 기능을 구성하는 각 코드 블록을 테스트하는 코드
테스트 프레임워크를 통해 자동으로 실행할 수 있음
단위 테스트 작성 시점은 기능 구현 이전이 바람직함
각 기능이 의존하고 있는 외부 기능은 Mock/Stub 등을 사용해 테스트
테스트 주도 개발(TDD)
기능을 만들기 전에 테스트 코드를 먼저 작성하는 개발 방식
단위 테스트 작성 != 테스트 주도 개발
장점
코드 품질이 비약적으로 향상
코드의 설계가 간결하고 우아해짐
필요할 때 언제든지 기존 기능을 수정할 수 있음
테스트가 갖춰야 할 특징
한 번에 한 가지 테스트만 해야 한다
상호 배제와 전체 포괄(MECE : Mutually Exclusive and Collectively Exhaustive)
외부 환경과 독립적으로 테스트를 실행할 수 있어야 함
인터넷이 끊어진 환경
특정 OS, 특정 개발 도구에서만 돌아가는 테스트는 부적절
단위 테스트 작성 기법
구현하고자 하는 기능을 대략적으로 설계
가장 뼈대가 되는단순한 기능을 하나 선정
이 기능이 동작하면 어떤 결과를 얻을 수 있는지를 테스트 코드로 작성
Given, When, Then 3개를 생각해서 작성
ex) Machine m = new Machine(); // given
Drink d = m.buy(Coke Class); // When
assertTrue(d instanceof Coke); // Then
테스트 메소드 이름 작성법
ex) 두 값이 같은지 비교할 경우
TDD st - testEqualsOnNotEqual()
DDD st - test_equals_should_return_true_if_value_is_not_equal()
equals_는_소스파일목록도_일치하지_않으면_false를_반환한다() // 한글로도 상관 없다
테스트 작성 팁
아기 걸음
안심하고 다음 단계로 넘어갈 수 있는지가 중요
한 번에 한 가지 테스트만
중간에 생각나는 새로운 아이디어는 노트에 작성
Given-When-Then
테스트를 간결하고 목적 중심으로 유지해주는 마법의 키워드
테스트 코드에는 조건문이나 반복문 지양
Private 멤버 접근 지양
테스트 코드는 대상 코드의 내부 구현과 밀접하게 얽히면 안된다
해당 멤버 변수를 실제로 사용하는 곳에 초점을 맞춰 테스트
배열 같은 것을 테스트할 때는 개수, 첫번째 값, 마지막 값만 테스트하면 된다
테스트 대상의 변화 검사 방법
반환값을 감지
외부의 환경 변화를 감지
자체의 상태 변화를 감지
테스트 대역
단위 테스트를 작성하기 쉽게 해주는 모의 객체
Dummy/Mock/Stub/Spy/Fake 등의 개념으로 나뉨
DB/파일 입출력 등을 대체할 때 가장 많이 사용
주의사항
테스트가 설계를 완전히 대처하지는 못한다
테스트 코드도 코드이므로 유지보수 대상이 된다
단위테스트는 테스트의 일부일 뿐이다
가능하면 적절한 수준의 통합 테스트도 해주는 것이 좋다
EclEmma
단위 테스트를 할 때 테스트 커버리지를 측정해주는 도구
eclipse 플러그인으로 제공
RUP(Iterative) - 가장 프로젝트 성공률이 높다 (검색)
참고 동영상
http://xper.org/LineReaderTdd/
조직에 애자일 도입하기
애자일 도입의 어려움 - 개발자들의 반발
개발 일정도 바쁜데 테스트를 짤 시간이 어디 있나
매일 하는 회의는 낭비다
기획자가 요구사항만 중구난방으로 만들어내는 것 아닌가
진행 현황을 너무 분명하게 드러내서 심리적 압박이 심하다
애자일 도입의 어려움 - 관리자들의 반발
개발자들이 일정을 마음대로 늘려 잡으면 어떻게 하나
설계를 안하고 진행하다가 나중에 누가 책임을 지나
요구사항을 초기에 드러내지 않으면 나중에 어떻게 감당하나
애자일 도입 방법
요구사항을 스프린트별로 나눠서 진행하기
테스트와 개발을 밀접하게 연결시키기
요구사항을 최소 사양 + 확장 사양으로 분해해 진행해보기
이름 없이 실행하기
애자일 관련 서적
린 소프트웨어 개발의 적용
출판사 : 위키북스
저자 : 메리 포펜딕, 톰 포펜딕
역자 : 엄위상, 심우곤, 한주영
단위 테스트를 하기 위해 자바에서 필요한 것
JDK
Eclipse
M2Eclipse
Infinitest
PMD for Eclipse
강사 이메일
댓글