"A Disciplined Approach to Adopting Agile Practices: The Agile Adoption Framework"
Tangible SW 의 Ahmed Sidky 가 Agile 을 프로젝트나 기관에 적용하는 실질적인 방법을 논하는 방법입니다.
짧은 영어 실력으로 번역한 글이라 의역이나 오역이 있을 수 있습니다.
- 개요 -
많은 기관 들이 여러가지 이익들을 보장하는 애자일 방법론을 수용하려고 애쓰고 있다. 이 이익이란 바로 빠른 투자로 이어지게 만드는 더 나은 소프트웨어의 품질과 높은 고객 만족이다. 그러나 아쉽게도 현재까지 이를 적용하는 구조적인 접근 방법이 없었다. 이 글을 통해 그 구조적인 방법인 Agile Adoption Framework(이하 AAF)을 제안한다.
AAF는 크게 두가지 구성요소로 나뉜다 첫번째는 Agile 측정 인덱스 이며 두번째는 4 Stage 프로세스 이다. 이 들 둘이 같이 융합하여 어떤 기관의 Agile 방법론의 적용을 위한 가이드와 보조역할을 하게 된다. 더 상세하게 말하면, Agile 측정 인덱스는 프로젝트나 기관의 Agile 메서드를 적용할 수 있는 잠재력을 발견한다. 그리고 4 Stage 프로세스는 이 기관이 혹시 Agile 을 적용할 준비가 되었는지, 그리고 그들의 잠재력으로 어떤 것들을 이끌어 낼 수 있는지, 또는 어떤 Agile 실천방법을 소개하고 적용할 수 있는지 알게 된다.
1. 소개와 동기
정말 많은 기관들이 수년간 이러한 질문을 해왔다. "우리는 왜 Agile 을 적용해야 하는가?" 그리고 Agile 을 잘 적용한 기관들의 수많은 성공 사례들을 우리는 접해왔다. 이 결과로 많은 기관들이 Agile 방법론을 적용하는데 나서고 있다.
그 변화로, 그들은 이제 다른 방식으로 Agile 커뮤니티에 접근한다 그것은 "어떻게 Agile 실천 방법들을 우리 회사에 적용할 수 있는가?"이다. 불행히도 지금까지 구조적으로 그 접근방법을 논의한 사례는 없었다. 가이드나 보조장치가 없을때 기관에 Agile 을 적용하기는 사실 굉장히 어렵다.
이를 해결하기 위해 성공적인 Agile 실천 방법들이 수반된 구조적인 접근이 반드시 이루어져야 한다. 그리고 이 구조적인 접근은 아래와 같은 이슈들을 고려하고 결정되어야 한다.
(1) 기관의 Agility 에 대한 이해도
(2) 적용해야할 Agile 실천방법
(3) (2)의 실천방법을 적용할 때 잠재적인 문제점
(4) (2)의 실천방법을 적용하는데 필수적인 기관의 준비상태
여기서 소개하는 AAF는 위의 설명한 이슈들을 구조적이고 반복적인 접근을 통해 검토하여 진정한 Agile 방법론을 이룩하려는 가이드와 보조장치를 제시한다. 그러나 잊지말아야 할 사실은 AAF 는 사실 한가지의 필수적인 요소일 뿐 이를 적용할 줄 아는 Agile 컨설턴트도 반드시 필요하다. 이 컨설턴트가 프로젝트 안에 상주하며 이 프레임웍의 사용을 충분히 관장하고 교육 시킬 수 있어야 한
다.
AAF 는 서두에서 말한것처럼 두가지 구성 요소가 있다.
(1) Agile 잠재력의 측정을 위한 측정 인덱스
(2) 기관으로 적용할 Agile 실천방법이 어떤 것인지를 결정하고 무엇을 범위로 삼을 지에 대한 4 Stage 프로세스
그림 1은 이 두 가지 내용을 그리고 있다
첫번째 구성요소인 Agile 측정 인덱스는 코치가 사용하는 프로젝트나 기관에 Agile 잠재력을 식별하는 하나의 척도이다. 이 Agile 측정 인덱스는 기관에 가장 알맞는 agile 실천방법들을 찾아내는 4 Stage 로 구성된 프레임웍의 프로세스 구성 안에 사용된다.
이 스테이지는 아래와 같다.
Stage 1 : 문제요소들을 식별하기 - Agile 적용을 저해하는 요소들을 식별해내기
Stage 2 : 프로젝트 레벨 수준을 알아내기 - 특정 프로젝트를 위한 target 레벨을 Agile 측정 인덱스를 이용해 식별하기
Stage 3 : 기관의 레벨 수준을 식별하기 - 프로젝트에 식별된 target 레벨이 적용되고 성공 될 수 있는지 기관에 대한 범위를 확인하기
Stage 4 : 이에 대한 조정을 수행하기 - 프로젝트를 위한 target Agile 레벨을 조정하여 적용될 마지막 Agile 실천방법을 결정하고, 기관의 Agile 이해도를 구체화한다.
2. Agile 측정 인덱스
기관에서 애자일의 실천 방법을 찾을때 가장 걱정하는 것중 하나가 어떻게 그들이 'Agile화' 될 것인가 이다. 프로젝트와 기관의 Agile 잠재능력은 그들이 처해 있는 환경에 영향을 받는다. Agile 잠재력을 결정할때 코치는 측정 인덱스나 개체의 Agility를 가늠할수 있는 척도가 필요하다. 이 AAF는 프로젝트와 기관의 Agile 잠재력을 결정하기 위해 Agile 측정 인덱스를 사용한다. 이 측정 인덱스는 네 가지로 나뉜다.
(1) Agile 레벨
(2) Agile 원리
(3) Agile 실천방법과 개념들
(4) 지표들
2.1 Agile 레벨
그림 2A 에서 묘사되듯이 Agile 레벨은 프로젝트나 기관을 위한 agility 의 다른 가능 정도를 측정하는 단위로 사용될 수 있다. 프로젝트나 기관의 Agile 잠재력은 성취 할 수 있는 가장 높은 것으로 나타낸다. 이런 특정 레벨로 달성하는 것은 프로젝트나 기관이 어느 정도의 Agile 효과를 낼수 있는 요소들을 수용하느냐에 따라 결정된다. 예를들어 이 본래부터 개발 프로세스 안에 커뮤니케이션 증진 과 협조을 수용하는 수준의 요소들을 가지고 있었다면 이는 레벨 1을 얻게 된다. 이 프로젝트나 기관이 Level 2 로 가기 위해서는 모든 레벨 1의 요소를 얻어야 한다.
Agility 의 레벨 5는 Agile 성명의 핵심 퀄리티를 나타낸다. 이 선언을 주위깊에 분석 한 후에 5개의 필수적인 Agile 퀄리티를 가진 것으로 식별한다. 이 5개 식별된 퀄리티들은 Agile 측정 인덱스에서 5 Agility Level 로 성립된다.
* 레벨 1 ( 협조적인 ) : 이 레벨은 모든 stakeholder들 간에 커뮤니케이션과 협조가 잘 이루어지는 상태를 말한다. 이 협조 차원은 Agile SW 개발의 초석이다.
* 레벨 2 ( 진화하는 ) : 진화하는 개발은 소프트웨어의 조기의 지속적인 delivery 를 수행하는 것을 말한다. 이는 모든 애자일 방법이 실재하는데 매우 기본적인 상태이다
* 레벨 3 ( 효과적인 ) : Agile 개발 프로세스의 다음 가치는 효율적이고 효과적인 방법안의 높은 품질의 소프트웨어 개발을 수용하는 것이다. 이 가치는 개발 프로세스를 준비하는데 필요하며, 이것은 프로젝트를 위험에 빠트리지 않고 끊임없이 변화할 수 있도록 이끈다.
* 레벨 4 ( 적용하는 ) : 이 레벨은 프로세스 안에서 변화에 대해 반응하기 위한 Agile 가치를 이룩하도록 구성하는 것이다. 다양한 피드백의 레벨들을 정의하고 반응하는 것이 이 레벨에서 필수적이다.
* 레벨 5 ( 숨쉬는듯한 ) : 마지막 레벨은 기관에 활발한 활동을 통해 agility 의 육성을 지속적으로 퍼트릴 수 있는 분위기를 가진 상태를 말한다.
2.2 Agile 원리들
Agile 원리들을 Agile 을 고려하기전에 반드시 먼저 반영해야할 필수적 특성이다. 예를들어 Agile 의 원리는 크게 두가지로 볼수 있는데 이는 사람과 사람 사의의 의존관계와 상호작용을 이야기하는 인성중심과 가장 높은 코드의 픔질을 보장하는 기술적 성숙도이다. Agile 선언 outline들은 개발 프로세스를 12개의 원리들로 나누는데, 12가지의 본질을 5가지의 Agile 원리로서 통합했다. 이 5가지는 아래와 같다
(1) 고객의 가치를 전달하는 변화를 포용한다 : 소프트웨어 개발 노력의 성공은 고객의 가치를 전달하는것에 얼마만큼의 도움을 주느냐에 달려있다. 이는 고객 뿐만 아니라 많은 개발팀 안에서 부가적인 고객의 가치를 실현하는데 지속적인 프로세스 학습을 수행하는 것을 말하며 이 변화를 수용하는 태도는 소프트웨어 개발을 통해 유지되어야 한다.
(2) 보다 자주 계획하고 소프트웨어를 배포한다 - 자주 계획하고 소프트웨어를 배포하는 것은 매우 중요하다. 왜냐하면 이것은 고객에게 기능에 대해 보자 자주 피드백 할 수 있게 해주기 때문이다. 이 피드백은 다음 iteration에서 소프트웨어 개발의 범위나 방향을 정하는데 필수적인 요소이다.
(3) 인성중심 - Agile 소프트웨어 프로세스의 정의 안에 사람사이의 의존과 상호작용은 주춧돌 역할을 한다
(4) 기술적 성숙도 - Agile 개발자들은 코드의 가장 높은 픔질을 실현하기 위해 빠른 페이스의 개발 환경을 구축하는 것이 중요하다
(5) 고객 협조 - Agile 선언문의 기본 조건처럼 모든 stakeholder 간 상호작용이 매우 중요하다.
(중략 이를 위한 Agility 레벨 5 표에 대한 설명)
2.3 Agile 실천방법
Agile 실천방법들은 Agile의 원리와 함께 프로젝트 내에서 개발시 수행될 수 있는 수행방법과 실천적 기술들이다. 예를들어 pair programming, user stories, collaborative planning 등이 그들이다. 여러 실천 사례들로 이를 40가지로 나누고 또한 이를 레벨 5로 카테고라이징 했다.
2.4 지표들
지표(혹은 질문)들의 집합은 측정 인덱스 안의 Agile 실천방법이나 개념들과 같이 수반되어야 한다. Agile 코치는 이 지표들로 기관이 어떠한 Agile 실천방법이나 개념들을 적용할 준비가 되었는지 범위를 측정한다. GQM(Goal Question Metric) 이나 OPA(Objectives Principles Attributes) 프레임 웍을 사용하여 각 실천방법들을 위한 지표를 만들어 내었다. 각 지표들은 진표들과 연관된 Agile 실천방법들을 성공적으로 적용하는데 필요한 특정한 기관의 특성들을 측정하기 위해 만들어졌다. 이 질문들에 준하여 매니저, 개발자 또는 Agile 코치는 주관적으로 또는 객관적으로 대답을 하도록 한다.
예를들어 코치가 코드 표준(레벨1 기술적성숙도) 을 기관에 적용할 준비가 되었다고 결정하고 싶다면 두가지 기관특성들을 만족해야 한다.
(1) 개발자들은 코드 표준에 대한 이득을 이해하고 있는가?
(2) 이 코드 표준을 수행 할 의지가 있는가?
만약 (2) 번의 대답을 얻었다면 질문자는 '시간 제약사항이 있는데도 불구하고 코드 표준을 준수할 수 있는지?' 여부를 개발자들에게 물 을 수 있다
테이블 1에서의 5가지의 Agility 레벨은 Agile 측정 인덱스에 한가지 예일 뿐이나 이 예가 변경되거나 대체 될 수 있는지 이제부터 알아보겠다.
2.5 Agility 5 레벨의 변경
Agile 커뮤니티 담당자들에게 Agiltiy 5레벨은 그들의 실천방법 + 지표들을 검토받았었다. 여러 커뮤니티의 리더들이 여러가지 Agility 5 레벨의 그림을 수정해줌으로써 우리를 고무시켰다. 이러한 요소들은 이 프레임웍의 완성도를 보다 높여준다
2.5.1 비지니스 가치의 통합.
2.5.2 실험을 거친 성공을 기반으로 한 실천방법의 재구성
Tangible SW 의 Ahmed Sidky 가 Agile 을 프로젝트나 기관에 적용하는 실질적인 방법을 논하는 방법입니다.
짧은 영어 실력으로 번역한 글이라 의역이나 오역이 있을 수 있습니다.
- 개요 -
많은 기관 들이 여러가지 이익들을 보장하는 애자일 방법론을 수용하려고 애쓰고 있다. 이 이익이란 바로 빠른 투자로 이어지게 만드는 더 나은 소프트웨어의 품질과 높은 고객 만족이다. 그러나 아쉽게도 현재까지 이를 적용하는 구조적인 접근 방법이 없었다. 이 글을 통해 그 구조적인 방법인 Agile Adoption Framework(이하 AAF)을 제안한다.
AAF는 크게 두가지 구성요소로 나뉜다 첫번째는 Agile 측정 인덱스 이며 두번째는 4 Stage 프로세스 이다. 이 들 둘이 같이 융합하여 어떤 기관의 Agile 방법론의 적용을 위한 가이드와 보조역할을 하게 된다. 더 상세하게 말하면, Agile 측정 인덱스는 프로젝트나 기관의 Agile 메서드를 적용할 수 있는 잠재력을 발견한다. 그리고 4 Stage 프로세스는 이 기관이 혹시 Agile 을 적용할 준비가 되었는지, 그리고 그들의 잠재력으로 어떤 것들을 이끌어 낼 수 있는지, 또는 어떤 Agile 실천방법을 소개하고 적용할 수 있는지 알게 된다.
1. 소개와 동기
정말 많은 기관들이 수년간 이러한 질문을 해왔다. "우리는 왜 Agile 을 적용해야 하는가?" 그리고 Agile 을 잘 적용한 기관들의 수많은 성공 사례들을 우리는 접해왔다. 이 결과로 많은 기관들이 Agile 방법론을 적용하는데 나서고 있다.
그 변화로, 그들은 이제 다른 방식으로 Agile 커뮤니티에 접근한다 그것은 "어떻게 Agile 실천 방법들을 우리 회사에 적용할 수 있는가?"이다. 불행히도 지금까지 구조적으로 그 접근방법을 논의한 사례는 없었다. 가이드나 보조장치가 없을때 기관에 Agile 을 적용하기는 사실 굉장히 어렵다.
이를 해결하기 위해 성공적인 Agile 실천 방법들이 수반된 구조적인 접근이 반드시 이루어져야 한다. 그리고 이 구조적인 접근은 아래와 같은 이슈들을 고려하고 결정되어야 한다.
(1) 기관의 Agility 에 대한 이해도
(2) 적용해야할 Agile 실천방법
(3) (2)의 실천방법을 적용할 때 잠재적인 문제점
(4) (2)의 실천방법을 적용하는데 필수적인 기관의 준비상태
여기서 소개하는 AAF는 위의 설명한 이슈들을 구조적이고 반복적인 접근을 통해 검토하여 진정한 Agile 방법론을 이룩하려는 가이드와 보조장치를 제시한다. 그러나 잊지말아야 할 사실은 AAF 는 사실 한가지의 필수적인 요소일 뿐 이를 적용할 줄 아는 Agile 컨설턴트도 반드시 필요하다. 이 컨설턴트가 프로젝트 안에 상주하며 이 프레임웍의 사용을 충분히 관장하고 교육 시킬 수 있어야 한
다.
AAF 는 서두에서 말한것처럼 두가지 구성 요소가 있다.
(1) Agile 잠재력의 측정을 위한 측정 인덱스
(2) 기관으로 적용할 Agile 실천방법이 어떤 것인지를 결정하고 무엇을 범위로 삼을 지에 대한 4 Stage 프로세스
그림 1은 이 두 가지 내용을 그리고 있다
첫번째 구성요소인 Agile 측정 인덱스는 코치가 사용하는 프로젝트나 기관에 Agile 잠재력을 식별하는 하나의 척도이다. 이 Agile 측정 인덱스는 기관에 가장 알맞는 agile 실천방법들을 찾아내는 4 Stage 로 구성된 프레임웍의 프로세스 구성 안에 사용된다.
이 스테이지는 아래와 같다.
Stage 1 : 문제요소들을 식별하기 - Agile 적용을 저해하는 요소들을 식별해내기
Stage 2 : 프로젝트 레벨 수준을 알아내기 - 특정 프로젝트를 위한 target 레벨을 Agile 측정 인덱스를 이용해 식별하기
Stage 3 : 기관의 레벨 수준을 식별하기 - 프로젝트에 식별된 target 레벨이 적용되고 성공 될 수 있는지 기관에 대한 범위를 확인하기
Stage 4 : 이에 대한 조정을 수행하기 - 프로젝트를 위한 target Agile 레벨을 조정하여 적용될 마지막 Agile 실천방법을 결정하고, 기관의 Agile 이해도를 구체화한다.
2. Agile 측정 인덱스
기관에서 애자일의 실천 방법을 찾을때 가장 걱정하는 것중 하나가 어떻게 그들이 'Agile화' 될 것인가 이다. 프로젝트와 기관의 Agile 잠재능력은 그들이 처해 있는 환경에 영향을 받는다. Agile 잠재력을 결정할때 코치는 측정 인덱스나 개체의 Agility를 가늠할수 있는 척도가 필요하다. 이 AAF는 프로젝트와 기관의 Agile 잠재력을 결정하기 위해 Agile 측정 인덱스를 사용한다. 이 측정 인덱스는 네 가지로 나뉜다.
(1) Agile 레벨
(2) Agile 원리
(3) Agile 실천방법과 개념들
(4) 지표들
2.1 Agile 레벨
그림 2A 에서 묘사되듯이 Agile 레벨은 프로젝트나 기관을 위한 agility 의 다른 가능 정도를 측정하는 단위로 사용될 수 있다. 프로젝트나 기관의 Agile 잠재력은 성취 할 수 있는 가장 높은 것으로 나타낸다. 이런 특정 레벨로 달성하는 것은 프로젝트나 기관이 어느 정도의 Agile 효과를 낼수 있는 요소들을 수용하느냐에 따라 결정된다. 예를들어 이 본래부터 개발 프로세스 안에 커뮤니케이션 증진 과 협조을 수용하는 수준의 요소들을 가지고 있었다면 이는 레벨 1을 얻게 된다. 이 프로젝트나 기관이 Level 2 로 가기 위해서는 모든 레벨 1의 요소를 얻어야 한다.
Agility 의 레벨 5는 Agile 성명의 핵심 퀄리티를 나타낸다. 이 선언을 주위깊에 분석 한 후에 5개의 필수적인 Agile 퀄리티를 가진 것으로 식별한다. 이 5개 식별된 퀄리티들은 Agile 측정 인덱스에서 5 Agility Level 로 성립된다.
* 레벨 1 ( 협조적인 ) : 이 레벨은 모든 stakeholder들 간에 커뮤니케이션과 협조가 잘 이루어지는 상태를 말한다. 이 협조 차원은 Agile SW 개발의 초석이다.
* 레벨 2 ( 진화하는 ) : 진화하는 개발은 소프트웨어의 조기의 지속적인 delivery 를 수행하는 것을 말한다. 이는 모든 애자일 방법이 실재하는데 매우 기본적인 상태이다
* 레벨 3 ( 효과적인 ) : Agile 개발 프로세스의 다음 가치는 효율적이고 효과적인 방법안의 높은 품질의 소프트웨어 개발을 수용하는 것이다. 이 가치는 개발 프로세스를 준비하는데 필요하며, 이것은 프로젝트를 위험에 빠트리지 않고 끊임없이 변화할 수 있도록 이끈다.
* 레벨 4 ( 적용하는 ) : 이 레벨은 프로세스 안에서 변화에 대해 반응하기 위한 Agile 가치를 이룩하도록 구성하는 것이다. 다양한 피드백의 레벨들을 정의하고 반응하는 것이 이 레벨에서 필수적이다.
* 레벨 5 ( 숨쉬는듯한 ) : 마지막 레벨은 기관에 활발한 활동을 통해 agility 의 육성을 지속적으로 퍼트릴 수 있는 분위기를 가진 상태를 말한다.
2.2 Agile 원리들
Agile 원리들을 Agile 을 고려하기전에 반드시 먼저 반영해야할 필수적 특성이다. 예를들어 Agile 의 원리는 크게 두가지로 볼수 있는데 이는 사람과 사람 사의의 의존관계와 상호작용을 이야기하는 인성중심과 가장 높은 코드의 픔질을 보장하는 기술적 성숙도이다. Agile 선언 outline들은 개발 프로세스를 12개의 원리들로 나누는데, 12가지의 본질을 5가지의 Agile 원리로서 통합했다. 이 5가지는 아래와 같다
(1) 고객의 가치를 전달하는 변화를 포용한다 : 소프트웨어 개발 노력의 성공은 고객의 가치를 전달하는것에 얼마만큼의 도움을 주느냐에 달려있다. 이는 고객 뿐만 아니라 많은 개발팀 안에서 부가적인 고객의 가치를 실현하는데 지속적인 프로세스 학습을 수행하는 것을 말하며 이 변화를 수용하는 태도는 소프트웨어 개발을 통해 유지되어야 한다.
(2) 보다 자주 계획하고 소프트웨어를 배포한다 - 자주 계획하고 소프트웨어를 배포하는 것은 매우 중요하다. 왜냐하면 이것은 고객에게 기능에 대해 보자 자주 피드백 할 수 있게 해주기 때문이다. 이 피드백은 다음 iteration에서 소프트웨어 개발의 범위나 방향을 정하는데 필수적인 요소이다.
(3) 인성중심 - Agile 소프트웨어 프로세스의 정의 안에 사람사이의 의존과 상호작용은 주춧돌 역할을 한다
(4) 기술적 성숙도 - Agile 개발자들은 코드의 가장 높은 픔질을 실현하기 위해 빠른 페이스의 개발 환경을 구축하는 것이 중요하다
(5) 고객 협조 - Agile 선언문의 기본 조건처럼 모든 stakeholder 간 상호작용이 매우 중요하다.
(중략 이를 위한 Agility 레벨 5 표에 대한 설명)
2.3 Agile 실천방법
Agile 실천방법들은 Agile의 원리와 함께 프로젝트 내에서 개발시 수행될 수 있는 수행방법과 실천적 기술들이다. 예를들어 pair programming, user stories, collaborative planning 등이 그들이다. 여러 실천 사례들로 이를 40가지로 나누고 또한 이를 레벨 5로 카테고라이징 했다.
2.4 지표들
지표(혹은 질문)들의 집합은 측정 인덱스 안의 Agile 실천방법이나 개념들과 같이 수반되어야 한다. Agile 코치는 이 지표들로 기관이 어떠한 Agile 실천방법이나 개념들을 적용할 준비가 되었는지 범위를 측정한다. GQM(Goal Question Metric) 이나 OPA(Objectives Principles Attributes) 프레임 웍을 사용하여 각 실천방법들을 위한 지표를 만들어 내었다. 각 지표들은 진표들과 연관된 Agile 실천방법들을 성공적으로 적용하는데 필요한 특정한 기관의 특성들을 측정하기 위해 만들어졌다. 이 질문들에 준하여 매니저, 개발자 또는 Agile 코치는 주관적으로 또는 객관적으로 대답을 하도록 한다.
예를들어 코치가 코드 표준(레벨1 기술적성숙도) 을 기관에 적용할 준비가 되었다고 결정하고 싶다면 두가지 기관특성들을 만족해야 한다.
(1) 개발자들은 코드 표준에 대한 이득을 이해하고 있는가?
(2) 이 코드 표준을 수행 할 의지가 있는가?
만약 (2) 번의 대답을 얻었다면 질문자는 '시간 제약사항이 있는데도 불구하고 코드 표준을 준수할 수 있는지?' 여부를 개발자들에게 물 을 수 있다
테이블 1에서의 5가지의 Agility 레벨은 Agile 측정 인덱스에 한가지 예일 뿐이나 이 예가 변경되거나 대체 될 수 있는지 이제부터 알아보겠다.
2.5 Agility 5 레벨의 변경
Agile 커뮤니티 담당자들에게 Agiltiy 5레벨은 그들의 실천방법 + 지표들을 검토받았었다. 여러 커뮤니티의 리더들이 여러가지 Agility 5 레벨의 그림을 수정해줌으로써 우리를 고무시켰다. 이러한 요소들은 이 프레임웍의 완성도를 보다 높여준다
2.5.1 비지니스 가치의 통합.
2.5.2 실험을 거친 성공을 기반으로 한 실천방법의 재구성
덧글
2008/03/07 11:12 # 삭제 답글 
비공개 덧글입니다.