Younghoe.Info v3

파워포인트 2007로 작업한 것을 2003 호환으로 저장을 해도 이미지가 회색 음영만으로 보인다. 모든 이미지가 그런 것은 아니다. 이유가 무얼까? 차이를 확인해보니 클립보드에 올린 것을 붙여넣은 경우에 한해서 이런 문제가 생겼다. 해결책은? 번거롭지만 서식복사를 통해 해결할 수 있다.

파워포인트2007을 기준으로 하면, (1) 원하는 서식을 적용한 도형을 선택하고 아래 그림과 같이 (2) 서식 복사 아이콘을 클릭합니다. 커서 모양이 바뀌는데 이 때 (3) 서식을 바꾸고 싶은 도형을 찍어주면 됩니다. 서식 아이콘 클릭할 때 여러 도형에 적용하려면 두 번 클릭해야 합니다.

Booch가 쓴 OOAD 책에 반추할만한 내용이 나온다. primitive는 상대적이라는 의미이다. 모델링을 하다 보면 추상화 수준(Level of Abstraction)을 맞추려고 노력한다. 모델링에 익숙지 않은 사람도 경험적으로 수준을 고민한다. 종종 팀 작업을 할 때 보면, 인내심이 부족하거나 촉박한 일정(혹은 부실한 계획)으로 인해 절대적인 혹은 변경하지 않을 기준을 만들려고 한다. 아래 내용은 아주 기본적인 내용이다. 하지만, 항상 아는 바와 맞게 행동하지 못해서 문제다.


primitive를 위키피디아에서 찾아보았다.


컴퓨터 과학에서 용례는 다음과 같다.


경험적으로는 primitive와 atomic이 유사한 어감이 아닌가 싶다.


단위 테스트의 "단위" 등도 관련 문제 중에 하나다.

소위 SM 인력이라고 불리는 유지보수(?) 개발자 혹은 업무에 대해 이야기하다 보면 어색하다. 유지보수라는 표현과 실제 행위가 어울리지 않기 때문이다. 이런 상황은 우리나라만의 일은 아닌가 보다. Booch가 쓴 OOAD 책에 유사한 내용을 담은 글이 있다.


maintenance와 evolution은 대개 의뢰인과 개발자 모두 구분할 수 있고 어렵지 않게 합의 가능한 경우가 많아 큰 문제는 아니다. 유지보수 인력으로 evolution 하기 어려운 경우는 SI 프로젝트를 만드는 등 적절한 조치를 한다. 하지만, maintenance와 preservation은 의뢰인과 개발자의 입장 차가 뚜렷해 쉽게 합의하기 어렵다. 아쉬운 점은 종종 프로젝트 초반부터 자 preservation을 예측할 수 있고, 더러는 제안 단계에서 개발팀 구성만 보고 냄새를 맡을 수도 있다는 사실이다. preservation을 maintenance으로 바꾸려면 엄청난 비용을 치러야 한다. 대개는 새로 프로젝트를 하는데, 'ABC 시스템 OO化' 등으로 이름 짓는 작명지침(?)을 준수하기도 한다.

개념 구분에 대해 메모를 하려고 쓴 글인데, 씁쓸한 현실 성토가 되어 버렸나?

고객이 Spring을 써달라고 썼다는 분을 만난 적이 있는데...
이제 담배도 Spring .. :)

오랜만에 서점에 가서 책을 훑어 보는데 2가지 책이 눈에 띄었다.

하나는 ray님 추천도서 목록에서 봤던 이클립스 프로젝트 필수 유틸리티 : subversion, Ant, JUnit, Trac 이다. 필요할 때 딱 맞춰서 나온 좋은 책이다. 말 그대로 필수 유틸리티를 잘 정리했다. 책을 훑어보니 초심자가 반드시 알아야 할 내용을 적절한 수준으로 정리했다.


책에 대한 아쉬움은 아니지만, 좀 더 깊이 있는 내용을 원하거나 실무에서 문제 해결을 위해 참조하려는 독자를 위한 내용으로는 다른 책이 필요할 듯하다. 과연 그런 책이 나온다고 해도 얼마나 팔릴 수 있을지 의문이지만...

두 번째 눈에 띈 책은 SPRING 2.5 실무 프로그래밍이다. 스프링 2.5 책이라곤 하나밖에 없는 줄 알았는데 처음 보는 책이다. 전체적으로 초보자가 접근하기 좋은 흐름으로 구성했다. 저자 약력을 보니 강의 경험이 많은 베테랑인 듯하다. 예제도 어렵지 않아 처음 따라 해보기엔 좋을 듯하다. 내가 못 찾았는지 모르지만, 2.5 고유한 기능에 대한 설명은 없고, 설정은 모두 xml을 이용했다. 출판 시점에 맞춰서 판매 촉진을 위한 2.5를 붙여둔 듯하다.


서점을 나서면서 막연히 생각해봤다. 이런 책을 통해 천천히 예제를 따라 해보는 방법이 효과적인지. 배우는 이의 성향 문제가 중요하겠지만, 영어 읽기가 가능하다면 스프링 배포 파일에 들어 있는 예제를 돌려보면서 분석하는 방법을 권하고 싶다. 아마 그 정도를 해보면 위 책의 내용과 비슷한 수준의 지식을 얻을 수 있다. 물론, 영어 읽기, 스프링 레퍼런스 찾아보기, 왜 이렇게 만들었을까 고민해보는 인내의 시간을 감당해야 한다.

지인의 블로그를 보니 내가 위 책을 폄하하는 듯이 느낄 수도 있을 듯 하여 사족을 단다. 나는 이 책을 스프링을 공부하는 가까운 지인에게 추천한 바 있다. 하나의 시스템이 여러 개의 인터페이스를 갔듯 사람마다 다른 책을 원할 수 있다. 나는 스프링을 학습하는 방법으로 책과는 다른 방식을 조언했다. 위 책에서 불편하게 느껴지는 부분은 단 하나다. 스프링 2.5 고유의 내용을 살펴보기 힘든데, 2.5 라고 붙어 있어서 잠재적인 독자/스프링 사용자의 오해를 조금이나마 막고 싶었다.

요즘 3,000 원으로 무엇을 할 수 있을까? JUnit Max 월간 사용료(subscribe 방식)를 보자 논란을 일으켰던 모 커피 선전이 떠오른다.


나는 소프트웨어 개발자임에도 소프트웨어를 산 기억이 별로 없다. 아니 컴퓨터를 구매할 때 번들로 제공하는 소프트웨어 이외에는 10년에 하나 정도 사나 보다. 일민형이 JUnit Max – Kent Beck 포스트에 이어 메신저로 무조건 사라고 압박(?)해서 JUnit Max를 샀다. 월 3만 원 정도 하면 고민했겠지만, 2달러다. 높아진 환율을 적용해도 3천 원이다.

연간으로 해도 3만 원이 조금 넘는 금액이다. 효용성은 TDD를 하느냐 혹은 TestCase를 얼마나 작성하느냐에 달렸다. 사실 1년에 3만 원 투자를 놓고 효용성을 따지는 일은 우스운 짓이다. JUnit Max 페이지 슬라이드를 단 몇 분만 훑어봐도 뭐하는 녀석인지 알 수 있다. 마치 IDE가 자동 빌드를 보급한 것처럼 JUnit Max는 저장하면 자동으로 테스트를 실행한다.

설치 후 몇 번만 써도 Run As... 콤보 키를 누르는 시간과 JUnit 뷰를 보는 시간을 절약했다. 더불어 JUnit 뷰를 열 필요가 없어 노트북 사용자에겐 모니터 공간 활용도 유리하다. 월 3천 원에 생산성 향상이면 가격 대 성능 비로 대적할 상품은 없을 듯하다. PM이라고 코딩할 일이 없다가 모처럼 지저분한 빌드 파일 테스트를 해보는 때마침 JUnit Max를 만났다.


안내 표시인 i는 테스트 성공을 의미한다.


TDD를 하지 않고, 기존 파일을 테스트 하니 안내 표시만 본다.


실패하면 컴파일 오류 비슷하게 취급해서 보여준다. 저장하면 잠시 경고 표시를 볼 수 있는데, 바로 테스트를 실행해서 아주 짧은 순간만 만날 수 있다. :)

JCO 발표 연장 선상에서 받은 또 다른 질문이다. 답변과 더불어 앞선 글에서 소개하지 않은 세 번째 사용법을 소개한다.

예를 들려고 우리가 초기에 사용한 요구 사항의 단위를 설명하겠다. 우리 팀은 유스케이스^[각주:1]를 뽑는 일 자체를 그만두었다. 고객이 초기에 정의한 요구 사항이 있었기 때문에 이를 그대로 사용했다. 2주 정도 요구 사항을 구체화하는 시간을 갖고, 마지막에는 무엇을 기준으로 해당 요구 사항을 만족 여부를 판단할지 근거를 마련했다. 검증 기준을 나누다 보니 자연스럽게 요구 사항을 몇 개의 검증 기준으로 나누었다.

해당 검증 기준은 Trac 작업 단위의 출발점이 될 수 있다. 우리는 최초에 시범적으로 Trac을 운영했기 때문에 이를 Trac에 넣지 않고, 엑셀로 만든 백로그라는 파일에 넣어 관리했다. 그 후 스프린트 초기에 백로그 중에서 어떤 작업을 먼저 할지 결정했다. 

시간이 흐르면서 잦은 배포를 통한 구체적인 피드백이 작업을 기민하게 해준다는 사실을 체험할 수 있었다. 고객이 초기의 모호한 요구 사항만 주고 별 반응 없이 기다리는 상황에 비해 눈에 보이는 무언가를 제시한 후의 양상은 많이 달라졌다. 요구 사항이 작고 구체적으로 변했다. 작고 구체적이기 때문에 구현에 소비하는 시간이 작아져 부담이 덜하다. 반면에 피드백 형태의 요구 사항 항목이 많아져서 관리 부담이 생긴다. 또한, 애초 요구 사항에 대한 보완 정도로 이들을 취급하면 개발팀은 무언가 덜했기 때문에 부가 작업을 하는 것으로 비친다.

반면 이를 별도 요구 사항으로 식별하고 서로 확인하고 작업을 하면 양상은 달라진다. 가령 이들 피드백을 한 주 동안 고객 쪽 실무자가 Trac에 등록하거나 PM이나 PL이 등록한다. 그럼 개발팀 PM이 올라온 항목 전체를 모아서 백로그라는 문서를 만들고, 다음 주 월요일 오전에 고객과 개발팀이 회의를 열어 필요한 작업이 이 정도인데, 이 중에서 우선순위를 부여해 달라고 한다. 시간이 지나면 우선순위 부여 자체도 더욱 기민하게 할 수 있다. 고객 모두가 관심이 있는 부분이 아닌 소소한 부분은 PM/PL이 관계자와 구두로 짧게 확인하고 나서 처리하고 다음 주 초에 작업 완료 항목을 공유하면 그만이다.

우리 팀은 실제로 위와 같은 방식으로 작업하고 있다. SI 프로젝트가 마치 유지보수처럼 변하는 데 필요한 숙련기간은 약 4개월 정도였고, 6개월이 지난 시점부터는 일하는 방식을 프로세스로 그려보고 부분적인 최적화를 시도할 수준이 되었다.

대부분의 작업 관리를 Trac을 써서 하면 Trac의 실제 사용자는 꼭 개발팀 모두일 필요는 없다. 사실 규모가 큰 경우라면 연륜이 있는 PM이 필요하고, 그가 Trac과 같은 시스템으로 직접 정보를 조회하거나 관리하기 원하지 않을 수도 있다. 반면에 고객 중에도 Trac과 같은 시스템을 발견하면 직접 보고자 하는 이가 있기 마련이다. 아이러니하게도 시스템 사용에 거부감이 없는 사용자가 Trac 사용자 후보일 수도 있다. 중요한 사실은 Trac으로 실제 작업 관리를 하는 사람은 개발자와 개발자의 작업을 실제로 관리할 대상이라는 점이다. 프로젝트나 팀 문화에 따라 자율적인 구조면 그가 반복 관리자와 같은 구실을 할 것이고, 전형적인 SI 프로젝트에서는 PL일 가능성이 크다.

2009. 3.14 다음 글에서 소개한 방법도 현실에서 활용할만하다 생각합니다.

효과적인 회의록 정리를 통한 요구 사항 추출 방법

질문에서 산출물과 Trac의 상충 관계를 의미하는 듯한 뉘앙스가 있어 오해했다. 다시 받은 질문인데, 산출물이라고 표현하셨으나 요체는 산출물을 활용하는 절차 즉, 프로젝트에서 이미 익숙한 개발 프로세스 하에서 Trac을 활용하는 방안을 묻는 듯하다. Trac를 처음 활용할 때 빠지기 쉬운 함정은 모든 작업을 넣어서 관리하려는 시도이다. 만일 시스템/솔루션 유지보수 조직이라면 Trac 활용이 원활할 수 있다. 그러나 개발 프로젝트에서는 대개 WBS나 PMS의 일정을 기준으로 진척을 확인한다. WBS의 하위 항목을 Trac에 넣으면 유용할까? 내가 Trac으로 작업관리를 해본 결과 Trac의 작업이 1일 이내의 작은 단위일 때 팀에 유연성을 제공했다. 과거에 우리 팀은 1, 2개월 간격으로 배포(release)를 했으나 지금은 매주 배포를 한다. 따라서, 매주 월요일에 고객이 기대할 기능이 빠져 실망하지 않게 하려고 목요일 이후쯤 조정을 해야 한다. 작은 단위의 일은 남은 이틀 안에서 조정할 수 있지만, 이틀을 넘어서는 일은 조정 자체가 힘들다. 테스트 주도 개발에서 켄트 벡이 보여준 것처럼 자신/팀의 리듬을 모르면 일단 작게 쪼개서 해라.

WBS와 Trac의 항목 일치는 힘들다는 사실을 알았다. 그렇다면, 서로 용도를 구분해서 사용해야 할까? 구분하는 방법과 연결 관계를 짓는 방법 모두가 있다. JCO 발표에서도 언급했지만 처음 Trac을 적용하는 경우라면 최대한 용도를 좁혀서 쓰는 방법을 권하고 싶다.

우리 팀은 처음에는 공식적인 작업은 백로그라는 엑셀 파일을 만들어 관리했다. Trac은 사전에 계획한 작업 이외에 반드시 추적할 필요는 없는 작업에 실험적으로 썼다. 대개는 코드 검사(Code Inspection) 이후에 테스트 누락이나 주석, 리팩토링 지시 등에 썼다. 용도에 대해 이름을 짓자면 개발팀 내 품질보증 활동을 위한 의사소통 도구 정도라고 할 수 있을까? 두 번째 쓰임새는 검수 과정에서 고객과의 의사소통 촉진용이다. 이미 개발자 테스트도 어느 정도 수행했고, 데모를 통해 정상 작동을 확인한 이후인지라 소소한 문제에 대한 보고이기 때문에 구체적인 설명이 필요했고, 경우에 따라서는 화면 캡처가 유용했다. 따라서, 시간을 정해서 회의하는 방식보다는 Trac에 관련 내용을 보고하고, 관계자가 해당 내용을 확인해서 바로 조치하는 방식은 시간을 절대적으로 절약해주었다.

후자는 고객의 적극적인 참여가 필수 전제 조건이다. 하지만, 웹이나 이클립스 화면(Mylyn 활용)을 써서 요구사항을 기록할 만큼 적극적인 고객을 만나기는 쉽지 않다. 적극성을 발휘하게 하려면 고객이 진심으로 관심을 가질만한 결과를 내놓아야 한다. 대개 요구 사항이나 화면 설계 등은 진정한 관심을 끌지 못한다. 요구 사항 검증이나 화면 설계서/정의서 검증에 고객을 참여시키려고 하면, 고객이 얼마나 관심이 없는지(?)는 확인할 수 있다. 하지만, 이는 고객의 문제로 보긴 어렵다. 동작하는 시스템을 써서 본인의 업무가 어떻게 바뀌고, 프로그램이 사용하는데 얼마나 편리한지/불편한지 느낄 때만 비로소 관심이 생긴다. 반복하지 않는 경우 프로젝트 막판에 가서야 구체적인 요구 사항을 들을 수 있다. 결국, 조기에 배포할수록 개발팀이 구체적인 피드백을 받는데 유리하단 이야기다. 조기 배포를 하려면 모든 기능을 한 번에 다룰 수는 없다. 애자일과 Trac의 시너지는 바로 이 부분에서 포착할 수 있다.

세 번째 활용 방식은 다른 질문 사항에 대한 답변이기도 해서 별도의 글로 나누어서 쓰겠다.

Trac에서 이미 제공하는 필드 이외의 내용을 trac.ini에 설정하여 추가할 수 있다. 제공하는 필드 유형이나 설정할 내용은 다음과 같다.

   * text: 한 줄 텍스트 필드
         o label: 표시 이름(이하 동일 적용)
         o value: 기본 값
         o order: 순서를 나타내는 정수 값 (낮을수록 위에 나타나며 역시 이하 동일) 
   * checkbox: 선택 여부
         o value: 0 이나 1
   * select: 드롭다운 선택 박스
         o options: 값의 목록이며, | (파이프) 문자로 구분
         o value: 기본 값은 항목 번호로 입력(0부터 시작)
   * radio: 라디오 버튼으로 기타 속성 등은 select와 같음
   * textarea: 여러 줄 텍스트 영역

더 자세한 내용은 웹상의 도움말을 참조할 수 있다.

적용한 예를 보자. trac.ini 파일이 다음과 같다.


마일린 티켓 편집 화면은 이제 이렇게 바뀐다.


몇 가지 주의사항. 순서는 정수로 입력해야 한다. 문자를 입력하면 마일린에서 다음과 같은 오류를 확인할 수 있다.


또 설정을 변경해도 마일린에 바로 반영되지 않을 수 있다. 편법으로 동기화하고 있어서 깔끔하게 동기화하는 방법은 아직 모르겠다.

2009. 3. 5 일부 갱신: 캐빈님 글 소개 및 견해 덧붙임

마치고 나서 기분이 좋았다. 기대하는 수준 정도는 교감이 있었다고 느꼈기 때문이다. 예년보다 늘었지만 60분도 여전히 짧다. 창준님처럼 주어진 시간을 활용할 능력이 부족해서이니 분발한 일이다. 자칭 성공적인 발표를 하는데 참가자가 일조했다. 준비가 충분하면 긴장을 하지 않는다. 전날 예행연습을 하고 자겠다던 약속을 지키지 못하고 잠들고서 아침에 후다닥 약식으로 한 시간 정도 연습을 했다. 그래서 부족한 만큼 긴장을 했는데, 강연 시작 후 호의적인 눈빛 그리고 열심히 메모하는 분 덕분에 용기를 얻었다. 이분들의 격려 덕분에 자신에 찬 목소리로 강연을 마칠 수 있었다.

청자의 의견을 들어보고 싶어 구글링을 해보았는데 결과가 많지 않다. 뒤풀이도 행사 담당자 위주라서 아예 세션을 듣지 못하는 사람이 많았다. 그나마도 제 세션을 들은 분을 만났는데 외국인(Michael Isvy) 옆자리를 지키느라 대화할 시간도 짧았고, 구체적인 피드백은 발표 초반 여친에게 감사하는 발언에 대한 의견뿐이었다. 하지만, 반갑게도 serapian님 블로그에서 사진 한 컷을 구했다.


내 모습이 잘 보이지 않는다. 오랜만에 만난 지인이 한결같이 하는 말은 살이 쪄서 못 알아보겠다는 말이었다. ㅡㅡ;

준비한 발표 자료는 총 78쪽이고 발표 시간은 60분인지라 분량이 많다. 더구나 사용자 정의 슬라이드를 추가한 터라 실제 화면 장수는 88장이다. 애초부터 무리인 시간싸움이지만, 현장에서 상황에 맞게 추릴 예정이었다. 전에 발표 장소에 시계가 없어서 낭패를 본 일이 있어 시계를 빌렸더니 조절을 할 수 있었다. 중간에 약간 흥분해서 불필요한 이야기를 더 한 점을 빼면 주어진 시간을 최대한 활용을 했다. 발표를 마치고 질문까지 받느라 현장 지휘하는 jco 스태프를 곤란하게 했다. 발표 직전에 아셈에서 이희승님 랩 시간이 늦어져 압박을 가하다 온 터라 느낌이 묘했다.

소감은 이 정도로 마치고, 발표 이후 질문이 오간 내용과 온라인의 다른 글에 대해 소견을 밝혀보겠다.

1. 포크맨님 글을 보면, 제 발언이 약간 잘못 전달된 듯하여 교정합니다.


애자일' 도입과 상관없이 '문제를 현장에서 해결하는 능력'은 과거부터 강조되었다는 내용에서 비롯한 오해인 듯합니다. RUP 등이 주도적으로 쓰일 때 문제 해결에서 아키텍트라는 특정한 역할이 강조되었다면, 유사한 역할에 대한 다른 이름으로 반복 관리자, 애자일 코치, 스크럼 마스터 등은 팀의 협업을 강화하는 촉매제로서의 역할이라고 전달하려 했습니다.

현장에서 질문을 대여섯 개는 받았는데 두 개 밖에 생각이 나지 않는다.

2. 유스케이스나 사용자 스토리 크기 기준
유스케이스 크기 기준을 잡느라 지나친 소모를 말자고 했는데, 그렇더라도 유스케이스 크기 기준은 필요하지 않느냐며 질문을 주셨다. 일반화 한 형식으로 산출물을 수정해야 하기 때문에 우리의 진화 과정을 공개하긴 힘들다. 그래서 핵심만 제시하면, 린 소프트웨어 개발 방식에서 취하는 적시 JIT(Just-in-Time) 의사결정이다. 유스케이스를 사용하든 사용자 스토리를 사용하든 그 단위의 중요함은 고객과 개발자 사이에서 효과적인 대화가 가능한 항목으로 정의해야 한다는 점이다. 항목이 다소 많고 레벨이 다르면 그저 대, 중, 소 등으로 분류하면 그만이다. 요구사항 설명에 있어서도 뻔히 아는 내용이나 이슈가 없는 부분을 기술하며 인생과 프로젝트 비용을 허비할 필요가 있을까?

물론 투영하는 관점을 명확하게 하면 MECE 등이 주는 효과처럼 결과물 분류가 쉬워 중복 작업을 줄이는 등의 효과는 있지만, 기준이 되는 요구사항 분류 항목을 개발 과정에서 나누고 합치고 한다고 해서 문제가 생기지는 않는다. 물론 누락은 없어야 한다.

캐빈님이 올려준 덧붙임은 마치 내 생각을 조리 있게 설명한 글처럼 시원한 느낌을 받았다:유스케이스나 사용자스토리 크기 기준

유스케이스에 대한 캐빈님의 견해에 100% 동의한다. 다만, 유스케이스가 사용자스토리와 분명히 다르지만, 프로젝트 현장에서 둘을 혼용하지는 않기에 무엇을 쓰든 크기에 대한 기준보다는 크기에 집착하지 않는 실용적 태도가 더 중요하다. 작업하기에 너무 크면 일정 관리에 탄력이 줄어든다. 또, 너무 작으면 관리의 복잡도가 늘어난다. 적절한 기준을 찾으려는 시도는 논문을 준비하는 사람에게 맡겨놓고, 프로젝트를 기간 내에 높은 품질로 완수하는데 시간을 써야 한다.

3. 팀 구성이 전부 초급 개발자인 터라 협업 도구/인프라 소프트웨어(svn, ant, hudson, trac) 사용이 어려울 때 어찌해야 하는가?
질문하신 분이 전제하길 '보통 개발 2~3년차 정도에 PM을 하지 않느냐?'라고 했다. 경험이 참 다르구나 싶었다. 나는 개발 9년차에 처음으로 PM을 했다. 게다가 개발자 역할만을 수행하지 않았다. QA, 방법론 tailoring, 업무 분석, 기술 책임자(Technical Lead) 등을 하면서 프로젝트를 다양한 시각으로 보는 능력을 키워왔다. 그런 경험이 성공적인 첫 프로젝트 관리 사례를 만든 근간이다. 아마 2~3년차 PM은 프로젝트에서 특정 부분을 담당해 개발하는 보통 PL이라고 부르는 역할에 대한 소규모 개발 업체의 호칭이 아닐까 싶다. 이렇든 저렇든 한창 배워야 할 2~3년차에 누군가 가르쳐서 끌고 간다는 점은 안타까운 현실이다. SI를 표방한 직업소개소 업주가 만들어낸 현실이다. 나는 이들이 곧 문 닫을 것이라 확신한다. 인터넷 등장으로 단순 중개인(intermediary)이 사라진 것처럼.

열악한 상황이지만 2~3년차 개발 리더가 초급 개발자를 데리고 개발할 경우라면 다른 도구에 욕심을 부리지 말고 최우선으로 svn/cvs부터 확실히 가르쳐서 소스 공유와 작업 결과의 투명한 노출을 장려하라고 조언하고 싶다.

4. 고객이 요구하는 산출물 형식에 맞추기
아래는 장선진님께서 현장에서 마지막에 주셨던 질문이 길어지자 메일로 보내신 내용입니다.

산출물 형식은 프로젝트 초기에 결정하기 마련이죠. 정부 관련 프로젝트는 경험이 없으나, 대부분 조직에서 품질 관련 부서나 품질 보증 담당자가 표준으로 제시하는 형식이 있습니다. 현실적으로 Trac의 내용으로 요구 분석이나 설계 산출물을 그대로 대치할 수는 없습니다. 따라서 공식 산출물에 등장하는 내용과 Trac 항목을 연결짓는 수준이 바람직합니다. 고객이 인지하는 활동과 산출물이 작업 관리에 쓰이는 Trac 작업 및 결과물과 구분해서 쓰이면 의사소통 혼선이나 오해가 빚어질 수 있습니다.

* 참석하신 분들의 피드백 기다리고 있습니다. 질문도 좋고, 비평도 좋습니다. :)

일단 27분 이상의 여유가 있으시면 무조건 보시길 ~
IT에 종사하거나 IT를 활용하고자 하는 분이라면 27분 투자로 충분한 보상을 받을 수 있다.



공교롭게 JCO에서 '애자일'에 관한 세션을 하고 나서 RSS 피드를 통해 창준님 발표를 봤다. 와우~ 99.9점을 줄 만한 발표다. ^[각주:1]27분의 제한시간을 그대로 지키면서 어떻게 저 내용을 다 전할까 하는 스킬에 관한 면도 그렇고...