티스토리 뷰
원본글은 github에 있습니다.
애자일은 태생이 포괄적이다. 그래서 추상적이다.
Plan(Predictive) Driven
마틴파울러에 따르면,
90년대 전통적인 개발방식(traditional plan-driven software engineering)의 문제점을 보완하려고 나타난 여러가지 방법론들이 있었다.
XP, Scrum, Crystal, DSDM, FDD 등등의 방법론들이 발전하고 있었지만, 소수의견 이었고,
주류(전통적인 개발방식)에 대항하기 위해 힘을 모은 것 같다.
그 방법론들을 만든 사람들과 대표자들이 모여서 통합 선언문 만들었다.
Agile이란 이름으로 결정되기전, 또 하나의 이름 후보는 'Adaptive'였다고 한다.
나는 그 동안 XP가 애자일의 구현체라고 생각했다. 모호한 애자일의 내용을 구체적으로 설명해줬기 때문이다.
그런데 아니였다. 스크럼 아저씨의 이야기처럼 XP, Scrum같은 lightweight 방법론들이 오히려 애자일의 부모이다. 애자일 밑에 있지 않다.
애자일을 보고 이해하기 어렵다면, 그 부모를 보면 될 것 같다.
애자일 선언문
에는 애자일이 추구하는 4개의 가치와 12개의 원칙이 있다.
문서에도 잘 나와있지만, 머리에 넣고 꺼내기쉽게, 내 나름대로 요약을 해보았다.
Agile's Values
'a보다 b를 더 중요하게 여긴다.'의 형식을 사용하는데,
a가 기존 개발방식의 문제점이었던 것 같다.
- 프로세스보다 사람
- 문서보다 작동하는 결과물
- 계약보다 고객과 협업
- 예측보다 대응
어떤 팀/회사가 이 가치들을 실제로 중요하게 여긴다면 애자일하다고 할 수 있겠다.
반대로
- 사람보다 프로세스
- 작동하는 결과물보다 문서
- 고객과 협업보다 계약
- 대응보다 예측
을 실제로 중요하게 여긴다면 애자일 하지 못하다고 할 수 있겠다.
추상적인 가치들을 설명하기 위해, 선더버드 회의 이후 원칙이 추가 되었다고 한다.
Agile's Principles
- 고객만족 최우선
- 요구사항변경 환영
- 동작하는 결과 수시제공
- 매일협업
- 동기부여된 사람
- 면대면 대화 지향
- 동작하는 결과로 진척확인
- 일정한 속도유지
- 기술적 탁월함/좋은 설계에 관심
- 꼭 할일만 함
- 스스로 팀 지향
- 정기적 팀 반성/변화
어떤 팀/회사가 원칙들을 잘 지키고 있다면 애자일 하다고 할 수 있겠다.
원칙의 목적은 가치를 얻기 위함이니 가치를 잊고 원칙만 고수한다면 애자일하다고 하기 어렵겠다.
클린 애자일을 보면, 애자일의 4가지 가치가 '밥먹으면 배부르다' 수준을 넘어서,
'실제로 일하는 방식'을 바꾸기 원했고, 12가지 원칙을 만들어진 것 같다.
그래서?
소프트웨어를 만들며 고통의 시간을 보내본 사람들은,
가치와 원칙을 보면서 참 좋은 말들이라고 고개를 끄덕일만 하다.
하지만 특히 개발자 입장에서, 실제로 어떻게 해야하는지, 가치와 원칙만 읽고 행하기는 어려운 것 같다.
엉클밥은 책에서 그 해결책으로 익스트림 프로그래밍의 실천방법을 이용한다.
나도 그 영향을 받아 이렇게 하고 있다.
- Total
- Today
- Yesterday
- 도메인주도설계
- Yegor
- 익스트림 프로그래밍
- agile
- repositorytest
- strategic design
- 객체지향
- 테스트코드
- 객체지향프로그래밍
- 기본은 테스트코드
- 테스트 코드
- 취업
- 도메인 주도 설계
- OOP
- 애자일
- repository test
- Object Oriented Programming
- 앨런 캐이
- Domain Driven Design
- testcode
- 자소서
- Object Oriented
- OO
- nhn
- akoop
- 전략적설계
- DDD
- XP
- Alan Kay
- Test Code
일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | 2 | 3 | 4 | 5 | 6 | |
7 | 8 | 9 | 10 | 11 | 12 | 13 |
14 | 15 | 16 | 17 | 18 | 19 | 20 |
21 | 22 | 23 | 24 | 25 | 26 | 27 |
28 | 29 | 30 |