1. AGILE이 잘 듣지 않는 프로젝트 유형은 어떤 것이 있는지? 반대로 잘 듣는 유형은?
대형 프로젝트에서 적용하기 어렵다는 인식이 일반적이긴 합니다. 대형 프로젝트에서 agile을 적용하는 방법들이 속속 나오고 있습니다. Scrum of Scrum 같은 접근방법이 있습니다. 대형 프로젝트도 결국은 관리 효율을 높이기 작은 팀 여러 개로 나누어 개발을 진행합니다. 그 소규팀을 효율적으로 관리하는 것이 결국은 대규모 팀을 효율적으로 관리하는 것이라는 생각을 밑바탕에 깔고 있습니다. 다만 팀 간의 효율적인 커뮤니케이션 방법과 팀을 묶어서 관리할 수 있는 뷰를 제공해야 합니다.
신기술 연구소와 같이 뚜렷한 성과물을 정의하기 어려운 곳에서 적용하는데 어려움을 호소하기도 합니다. 이런 곳은 agile을 적용하기 위해서는 agile 성숙도를 높일 필요가 있습니다. 제대로 적용하면 더 큰 효과를 볼 수 있습니다. 미리 모든 태스크를 정의해야 움직일 수 있는 기존의 접근방법으로는 수행이 불가능한 프로젝트를 진행할 수 있기 때문입니다.
산출물이나 결과물이 확실히 정의된 프로젝트에서는 바로 효과를 볼 수 있습니다.
요구사항이 명확하지 않거나 자주 변하는 프로젝트에서 기존의 방법보다 더 나은 성과를 기대할 수 있습니다.
2. 개인의 역량이 드러나면 고과와 연결이 될것이고, 그렇다면 자신의 역량 점수를 높이기 위해 자산의 TASK에 대해 UNDER ESTIMATION 을 하지 않을까 합니다.
일이라는 것이 난이도가 있기 때문에 개발자 자신이 자신의 일을 추정(estimation) 한다면 내 일은 어려운 일이라고 우기면 결국 추정 값에 대한 객관성이 떨어집니다. 추정(estimation)은 반드시 팀에서 해야 합니다. 개발자 개인이 하면 절대 안됩니다. 추정의 기본은 팀에서 모두 동의해야 한다는 것입니다. 추정에 대해서는 포커플래닝을 참조하시면 좋습니다. 팀원 모두가 함께 추정하면 결국 팀의 평균 값으로 나올 것입니다. 예를 들면, 개발역량이 뛰어난 개발자 A가 4시간 만에 할 수 있는 일을 개발 역량이 상대적으로 낮은 개발자 B는 12시간이 걸릴 수 있습니다. 이 때 팀의 추정 시간은 8이 되어야 합니다. 이 일을 A가 했을 때는 A는 4시간 만에 끝냄으로써 태스크 수행역량이 높아지고 B는 12시간이 걸림으로써 태스크 수행역량이 평균보다 낮아집니다.
3. 일반적으로는 팀/프로젝트 단위의 MEASURE는 OK 이나 개인에 대한 MEASURE는 절대로 하지 말라고 합니다. 이것에 대한 견해는 어떠신지요?
애자일 접근방법에서 개인별 측정은 다루지 않습니다. 팀역량이 중요하기 때문입니다. 이러한 사상에는 저도 전적으로 동감합니다. 개인의 측정은 평가에 사용하기보다는 모니터링에 주로 이용합니다. 개인의 측정을 통해 그 사람이 팀에 어떤 도움을 주는지 그리고 주목할 만한 문제는 없는지를 파악하고 발생 가능한 위험을 제거하는데 사용합니다. 이런 방법으로 개인별 측정 데이터를 축적하면, 팀을 구성할 때 팀에 필요한 역량을 가진 팀원으로 팀을 채울 수 있습니다. 무조건 코드 생산성만 높은 팀원으로 구성하는 것도 문제일 수 있습니다. 때로는 태스크 수행능력이 높거나 의사소통이 원활해서 협업(coordination)을 잘하는 팀원들이 더 많이 필요할 때도 있습니다. 소스코드 생산역량, 작업 수행 역량, 의사소통 스타일 등을 측정하는 것은 바로 이러한 목적을 위해서 입니다.
물론 이렇게 수집된 데이터를 개인을 평가하는 어떤 활동에 사용할 수는 있습니다. 그런 상황에서 조차도 A는 상대적으로 소스코스 생산역량이 뛰어나다라는 식의 평가를 하려는 노력이 선행되어야 합니다. A는 B보다 뛰어나는 식의 비교평가로 이어진다면 구성원들은 이러한 환경으로부터 탈출하려는 노력을 할 것입니다.
비젠드에서는 개발자 역량 요소를 세 가지로 설정하였습니다. 소스코드 생산 하나로만 개발자의 역량을 측정한다면 팀에 긍정적인 영향을 주는 다른 역량 요소들이 묻힐 수 있습니다. 따라서 소스코드 생산, 태스크 수행, 의사소통 세 가지 역량 요소 측정을 통해서 어느 것 하나라도 뛰어난 것이 있다면 그 역량으로 팀에 기여할 수 있도록 유도해야 합니다. 이러한 접근방법을 통해 팀과 개인 모두 윈-윈하여야 합니다.
조직 관리자 입장에서 정량 데이터 기반 평가라는 유혹을 벗어나긴 힘듭니다. 하지만, 조직의 궁극적인 목표가 개인평가인지 생산성과 품질 향상인지를 항상 기억해야 합니다. 관리를 위해서 개인 평가에 집착하다가 팀의 품질과 생산성에 부정적인 영향을 주는 잘못을 범하지 말아야 합니다.
4. 개발자들의 설계 능력을 향상시키기 위해 어떻게 해야 할까요?
예측능력을 향상시키기 위한 유일한 방법이 “예측하고, 기록하고, 반영하라”입니다. 마찬가지로 설계 역량을 향상시키기 위한 유일한 답은 “설계하고, 구현하고, 반영하라”입니다. 소프트웨어 개발팀 어디서나 설계의 중요성을 강조하지만 아이러니 하게도 설계처럼 무시되거나 대충 수행하는 활동도 없습니다. 그 결과 주니어 엔지니어 시절부터 제대로 설계된 것을 본적이 없고 따라서 설계를 어떻게 하는지 배울 기회를 얻지 못합니다.
이런 환경에서 개발팀의 설계 역량을 향상시키기 위해서는 다음과 같은 절차가 필요합니다. 물론 조직의 설계 참조모델과 참조시스템을 개발하여 활용하면 학습효과를 높일 수 있습니다.
① [객체지향개념] 객체지향 기본 개념을 철저히 이해한다.
② [객체모델링 1] 실세계를 시스템 세계를 매핑하는 연습을 한다.
③ [객체모델링 2] 객체 모델링을 이해하고 실행한다.
④ [컴포넌트 모델링] 컴포넌트 모델링을 이해하고 실행한다.
⑤ [아키텍처 모델링] 아키텍처 설계의 개념을 이해하고 실행한다.
각 활동을 판정할 어떤 규칙이나 공식이 있는 것은 아닙니다. 단지 설계 원칙을 준수했느냐 정도가 기준이 됩니다. 반복적인 모델링 활동을 통해서 개념을 습득하고 내재화하는 과정에서 모델링 대상을 바라보는 통찰력을 얻을 수 있습니다. 향상을 위한 과정은 강의보다는 도제(apprenticeship)식 훈련을 통해서 얻을 수 있습니다. 조직 내에 올바른 설계를 위한 12단계를 설정하고 실행하는 것도 실행을 위한 하나의 아이디어일 수 있습니다.
여기서도 중요한 것은 객체 모델을 검수할 대상으로써의 산출물로 바라보면 안된다는 것입니다. 설계의 사고활동의 결과로써의 산출물로 바라보아야 하며 표현의 범위에 많은 자유를 부여해야 합니다. 기능 하나에 클래스 다이어그램 하나와 시퀀스 다이어그램 하나… 이런 방식으로 접근한다면 설계자들도 그에 상응하는 낮은 수준의 설계 모델로 대응할 것입니다. 자유롭지만 높은 수준의 사고활동을 통해서 목표 시스템의 품질 목표를 달성할 수 있는 획기적인 또는 창의적인 아이디어가 나올 수 있습니다. 그런 아이디어를 기반으로 하는 설계를 진정한 설계라고 할 수 있습니다. 창의적인 사고활동 과정이 설계입니다. 검수받기 위해 설계 모델을 만든다면 그것은 시간을 소모하는 활동 이상도 이하도 아닙니다.
5. AGILE로 하면 설계 산출물이 잘 남지 않는데, 만약에 패턴 같은 것을 쓸 때 이것을 기록으로 남기지 않으면 나중에 유지보수가 어렵지 않을까요?
agile을 한다고 설계 산출물이 없는 것은 아닙니다. 오히려 더 활발히 설계를 해야 합니다. 단 일반적으로 설계 산출물을 작업으로 잡았을 때 문제는 설계만 해서는 이것이 끝났다고 말하기 어렵기 때문입니다. (구현 중 설계의 변화가 나타날 것이기 때문입니다.)
먼저 전체적인 그림(아키텍처 수준, 컴포넌트 수준)의 설계는 별도 작업으로 잡아 설계를 합니다. 그리고 구체적인 설계는 각 작업내에서 합니다.
agile은 요구사항의 변화를 적극수용하는 개발방법이기에 아키텍처나 설계에 신경을 많이 써야 하며 당연히 설계나 문서는 꼭 필요한 만큼 접근하기 쉬운 곳에 남겨야 합니다. agile을 하면 산출물이 필요없다는 것은 많이 오해하고 있는 부분입니다. 그러나 프로그램 확장이나 유지보수에서 꼭 필요한 산출물만 만든다는 사실은 중요합니다.
다만 기존의 산출물 작성방법 중에서 복잡하거나 무거운 산출물 검토절차는 가볍게 하여야 합니다. 짧은 반복 주기를 중시하는 애자일에서 분석, 설계, 구현 절차는 2주 또는 한 달을 주기로 매우 빠른 속도로 진행됩니다. 이 과정에 과거와 같은 산출물 검수 과정을 거친다면 애자일의 빠른 리듬은 깨어질 수 밖에 없습니다. 애자일에서는 산출물 검수 보다는 반복의 끝부분에서 실행 가능한 기능에 초점을 두는 것이 바람직합니다. 물론 이로 인한 산출물이 부실해진다면 릴리즈의 마지막 반복은 기능 목표를 줄이고 산출물을 보완하는 활동을 추가하여 반복을 수행하며 됩니다.
6. 개발자들의 개발시간을 측정하기 위해서는 일을 시작할 때와 마칠 때 시스템에 로깅을 해 주어야 하는데, 어떻게 하는지요? 일반적으로 PSP를 하면 TIME LOG 때문에 대부분 실패하는 것 같습니다.
비젠드는 개발자가 개발에 사용하는 시간을 직접 측정하지 않습니다. 다만 작업을 완료하였을 때 사용한 시간을 작업자가 입력하게 합니다. 이 데이터를 기반으로 추정 시간과 실제 사용한 시간의 차이를 분석합니다. 이 차이값은 앞으로의 추정을 도와주기 위한 것일뿐 생산성에 영향을 주지 않습니다. 개발자의 commit 현황을 통해 개발패턴을 시간으로 분석하고는 있습니다. 하지만 commit한 시간과 개발자의 개발 시간에는 차이가 있으므로 commit 시간은 참조용으로 사용합니다.
개발자가 일을 시작한 시간과 끝내는 시간을 직접 측정하여 개발에 들인 시간을 얻을 수 있습니다. 하지만, 이 데이터를 얻는데 너무 많은 노력과 시간이 들어갈 뿐만 아니라 정확성을 유지하기 어렵습니다. 가장 골치 아픈 것은 Time log 자체가 개발자를 성가시게 합니다. 개발자가 이러한 활동을 진지하게 수행해주리라 기대하지 마십시오. 따라서 이러한 접근방법은 바람직하지 않습니다.
개별 개별자의 Time log보다는 개별 태스크를 끝내는데 들인 시간을 기록하여 그 데이터를 기반으로 작업시간을 추적하는 것이 바람직합니다. 예를 들면, 어떤 개발자 이번 반복(iteration) 안에서 주어진 태스크를 완료하는데 사용한 총 시간을 개발자의 반복기간 근무시간에서 빼서 나오는 시간은 개발자가 태스크 수행 이외에 다른 활동을 한 시간입니다. 태스크 수행 전후 개발자가 직접 기록한 시간이나 이렇게 간접 계산을 통해 나온 시간이나 별반 차이가 없지만 개발자 입장에서는 후자가 훨씬 더 편리합니다.
7. Task의 크기를 어는 정도로 하시는지요?
1~3일 정도가 적당하며 5일을 넘기지 않도록 합니다. Task의 크기가 클수록 추정(estimation)이 불안해집니다.
8. Task를 종료할 때 시스템에 입력하는 것은 무엇이 있나요?
태스크 수행에 사용한 시간을 입력합니다.
9. Unit test 시 발견된 결함을 기록하는지, 아니면 test case 통과 & coverage만 확인하는지?
Test case가 실패하면 CI 서버에서 통보해줍니다. 내가 지금 하고 있는 작업외에 따로 확인하지 않습니다. 자동화하는 것이 중요합니다. coverage는 주기적으로 확인합니다.
결함을 보고받거나 발견하면 해당 결함을 테스트할 수 있는 테스트 케이스를 추가합니다. 그리고 이 테스트 케이스를 해결하는 방식으로 결함을 해결합니다.
나머지는 CI 서버에서 주기적으로 모든 테스트를 회귀테스트하기에 같은 결함이 발생하지 않습니다.
10. 코딩 표준에 대한 준수 check를 하시는지?
기본 코딩 표준에 대해 측정합니다. 그 동안의 경험으로 미루어 볼 때, 품질에 미치는 영향은 그리 크지 않다고 판단하며, 관리자의 관심도 대체로 낮습니다. Java 언어의 경우, 과거 Sun사에서 제시한 코딩표준이 Java 개발자 사이에 많이 전파되었고, 오픈 소스 진영의 코딩 표준 역시 Java 개발자에게 익숙해져 있는 까닭에 더 이상 큰 이슈가 되지 못하는 것 같습니다. 비젠드 Capa에서 40여 종의 코딩 표준에 대해 스타일 체크를 수행합니다.
11. 코드 리뷰를 하는지? 한다면 요구되는 coverage와 결함에 대한 기록/지원 도구를 쓰는지?
코드 리뷰는 효과가 매우 큽니다. 작업 완료시 완료된 작업결과를 보고 주요 소스에 대해 작업자와 같이 코드를 살펴봅니다. 또 다른 방법은 페어(pair) 프로그래밍인데 이는 생산성을 높일 뿐만 아니라 코드 리뷰 효과도 얻을 수 있습니다. 코드 리뷰는 강력히 추천합니다.
코드 리뷰는 선임자나 동료가 코드를 검토하는 것이기에 도구 보다는 코드 리뷰하는 문화가 더 중요합니다. 코드 리뷰하고 메일이나 도구로 수정사항을 전달하는 것보다는 직접 문제가 될 것 같은 코드에 대해 작성자와 의논하는 것이 현실적입니다.
코드 리뷰를 도구에 의존하는 리뷰어는 리뷰를 할 자격요건을 갖추지 못했다고 볼 수 있습니다. 그리고 어떤 도구도 경험이 많은 개발자의 조언을 뛰어넘지 못합니다. 코드 리뷰는 리뷰어와 개발자 간의 자연스러운 의사소통을 통한 경험이나 지식 전수 활동입니다. 따라서 도구를 이용한다거나 코드 리뷰 결과를 기록하는 활동은 매우 비생산적입니다. 도구에 의존하고 기록하는 방식의 리뷰는 코딩 표준 준수나 매트릭 체크와 같은 기계적이며 단순한 내용들이 대부분입니다. 이런 내용은 개발자 스스로 체크하여 스스로 개선할 수 있는 것들입니다. 이런 내용을 파악하고 기록하기 위해 절차를 만들고 시간을 들이는 것은 매우 비생산적일 뿐만 아니라 개발자들의 반감을 높여 팀워크를 저해할 수 있습니다.
12. 회사 내에 프로세스 개선 담당 인원수와 품질관리 인원(tester 제외)은 어떻게 되는지? 그리고 tester 는 얼마나 되는지. %로 알려 주시면 좋겠습니다.
애자일 문화는 개발자 스스로 자신의 소스코드에 자긍심을 가질 수 있어야 한다고 강조합니다. 따라서 개발자 스스로 소스코드 품질을 높이려는 노력을 해야 하며, 조직은 간단한 프로세스 정의하고 시행을 강요합니다. 넥스트리의 경우, 개발을 끝내면, CodePro라는 도구를 이용하여 잠재적인 오류, 매트릭 기준값 위배 등을 스스로 체크하여 기준값 범위 안에서 코드 오류가 0(zero)가 되게하며, 다음으로 FindBugs라는 정적분석 도구를 이용하여 마찬가지 기준값 범위 안에서 코드 오류가 0(zero)가 되게하며, 다음으로 Code Coverage가 목표치에 이를 때까지 단위테스트를 작성한 후 모두 성공 상태가 되게 합니다. 스크럼 마스터는 경험자가 인지할 수 있는 오류 가능성 부분을 집중적으로 확인합니다. 과거의 개발 프로세스에서 이런 일련의 활동은 품질 담당자가 수행했습니다.
애자일 프로세스는 릴리즈와 반복을 기본틀(frame)로 하는 프로세스로써 프로세스 자체의 개선 사항을 존재하지 않습니다. 팀원이 얼마나 애자일 개발 방식에 적응하는가 그리고 팀의 애자일 성숙도가 얼마나 높은가가 관심사입니다.
따라서, 넥스트리는 별도의 품질관리 담당자가 없습니다. 각 개발팀의 애자일 성숙도를 높이기 위해 노력하고 있습니다. 대신 애자일 성숙도가 낮은 팀을 위해 회사 내의 애자일 전문가가 코치 역할을 수행하고 있습니다.
'Vizend' 카테고리의 다른 글
| Vizend 언어/시간대 설정하기 (1) | 2010.11.04 |
|---|
