노무현 대통령 배너
어제는 XPer 3월 정기모임이 명동 LG CNS 사무실에서 열렸습니다. 경험을 발표하는 형식에서 참가자들의 토론식으로 바뀐뒤 첫 모임이라 약간 낯설었습니다. 이날 토론은 2가지 주제로 진행됐습니다.
  • 레베카 -- 애자일 소프트웨어 설계
  • 패턴, 위키, XP
5~6명이 한조가 되어 토론이 진행됐고 중간에 잠깐 휴식후 다시 같은조가 다른 주제로 토론을 재개하는 식이었는데 저와 한조가 된 분들이 애자일에 대한 경험이 많지 않은 분들이었습니다. 그래서 애자일 설계나 패턴에 대한 내용은 많이 이야기 못하고 설계가 현재 업무에서 주는 어려움 등을 이야기 했습니다. 기억나는 내용을 적어봤습니다.
  • 문서는 결국 유지보수를 위해 필요하다.
  • 문서가 유용했던 적은 개발자가 자주 바뀌는 바람에 인수인계를 해야 할때였다.
  • 장애가 발생했을때 관리자는 문서를 가져오라고 한다. 이때 내용은 보지 않으니 차라리 영어로 문서를 작성해서 적당히 갖다 주는게 편할 수도 있다. ^^;
  • 문서는 과거의 유물이 아닐까. 개발 초기 스냅샷이 아닐까.(이건 제 생각)
마지막에 각 조별 토론 내용을 공유하는 시간이 있었습니다. CRC 카드 이야기가 나왔는데 CRC를 모르는 분들이 있어서 즉흑으로 비디오 가게를 테마로한 CRC 카드 역할극을 진행했습니다. 교육에서 CRC를 종이 카드로만 사용했는데 역할극을 가미하니 또 새롭더군요.

CRC 카드

공유때 나온 이야기중 애자일툴 삼합이 있었습니다. : 위키, 소스 컨트롤, 버전 트래킹

"애자일스럽다."는 과연 어떤 의미일까에 대한 토론도 자연스레 진행됐습니다.
  • 변화에 대한 용기다.
  • 마인드다.
  • 애자일을 마인드라고 말하는게 애자일 남용을 불러 일으킨다.
4/21일 HP 후원으로 애자일 테스트툴에 대한 세미나가 열린다는 창준님의 광고가 있었습니다. 좋은 세미나가 될거 같은데 문제는 평일이라 갈 수 있을지 걱정입니다.

과거 발표내용에만 흥미가 있어 참석하는 분들이 없어서 그런지 더 단촐했지만 몰입도는 더 좋아진 느낌입니다. 아쉬웠던 점은 참여하는 분들이 좀 더 토론 내용에 대해 고민하고 왔으면 좋겠습니다.

ps) 그나저나 청하님 오셨었나요? 저도 직접 뵙고 싶어 사진과 동일인물 열심히 찾았는데..^^

저작자 표시 비영리 변경 금지
크리에이티브 커먼즈 라이선스
Creative Commons License
애자일쪽 이야기를 많이 하면서도 정작 설계에 대해서는 크게 고민 안했던거 같습니다. 그래서 이번에는 애자일 모델링에 대해 생각해 보려 합니다.

애자일 모델링 하면 나오는 첫번째 레퍼런스가 스캇 앰블러(Scott W. Ambler)가 쓴 agile modeling입니다. 대머리여서 발표할때 반짝반짝 빛나던(?) 모습의 스캇 앰블러가 생각납니다. Agile2009 마지막 날에 CSM의 유효성을 꼬집는 그의 세션을 들은 적 있습니다.

애자일 모델링의 근본을 이루는 원칙에는 다음과 같은 것들을 들 수 있습니다.
  • 모델이 단순해지도록 합니다.
  • 변화를 기꺼이 받아들입니다.
  • 조금씩 추가해 나갑니다.
  • 빠른 피드백을 받습니다.
  • 모델은 목적이 있어야 합니다.
  • 필요하면 여러개의 모델을 유지합니다.
이런 원칙에서 가장 중요한 것은 모델을 어떻게 표현하느냐 보다는 어떤 내용을 표현할 것인가(content is more important than representation)에 집중해야 한다는 것입니다.

아래 그림은 위 원칙을 기반으로 어떻게 애자일 모델링을 해야하는지 애자일 모델링의 전체 프로세스를 상위 수준에서 보여줍니다.
[AMDD, Agile Model Driven Development]

프로세스가 있으면 이 프로세스에 따라 실제 모델링 작업을 진행합니다. 이때 사용할 수 있는 기법들 입니다.

애자일 모델링에서는 여러 모델을 동시에 작업하면서 점진적으로 조금씩 키워 나갑니다. 그러면서 여러사람의 피드백을 받아서 확신을 가져야 합니다. 모델은 코드가 아니기 때문에 이 모델이 정말 맞는지 확신을 갖기 어렵습니다. 실제 코드를 짜보기 전까지는...

시간을 두고 공부해 볼 주제인거 같습니다.
저작자 표시 비영리 변경 금지
크리에이티브 커먼즈 라이선스
Creative Commons License
평소 비형식 컨퍼런스, 열린 모임에 관심이 많습니다. 그래서 이런 모임에는 어떤 것이 있는지 찾아봤습니다.


바캠프((Bar Camp)
자발적인 참여를 기반으로 하는 비형식 컨퍼런스
열린 환경에서 서로 배우고 공유하기 위해 만들어 졌으며 심도있는 토론과 상호 교류, 데모 등이 이루어 진다. 모든 참가자는 하나의 발표를 하거나 자원 봉사자로 참여해야 한다. (출처: BarCamp Seoul, BarCamp)
사례: UX Camp Seoul


푸캠프(Foo Camp)
오렐리에서 매년 여는 해커들의 이벤트
미리 초청자 명단을 정하고 이들이 모두 참여할 수 있는 일정을 화이트 보드에 썼다 지웠다를 반목하며 정하는데서 위키 컨퍼런스라고도 부름. 새로운 기술을 알고자 하는 사람들간에 교류를 높히기 위해 시작함.
(출처: Foo Camp - Wikipedia)


OST(Open Space Technology)
사전에 모임의 상세한 진행이나 발표자를 정하지 않은채 특정 주제나 목적만을 갖고 진행하는 참여 주도형 모임.  적게는 5명에서 많게는 2000명까지 가능하다. 주관자는 모임의 목적을 공지하고, 참여자들이 스스로 세션을 개최한다.(앞에 있는 보드에 세션을 적는데 이 보드를 'Market'이라 부름)
세션별로 둥그렇게 모여 토론을 진행하는데, 참여자들은 자유롭게 세션들을 돌아다니며 중간에 새로운 세션이 열리기도 하고 진행되던 세션이 닫히기도 한다. 이런 OST의 특징을 '주체적 이동의 법칙 The Row of Two Feet'이라 부른다.(출처: Open Space Technology-Wikipidia, 오픈스페이스란?)

대안 언어 축제
다양한 프로그래밍 언어와 관련 기술을 통해 개발자들의 사고와 문제 해결 방식의 지평을 넓히기 위해 발표자와 참여자가 상호 교류하는 축제형식의 컨퍼런스(출처: P-Camp & 대안언어축제 2008)

P-Camp
같은 가치를 추구하지만 상호 이질적인 도메인들간에 커뮤니케이션 통로를 확보하자는 차원에서 기획된 모임으로 IT 개발환경 개선을 지향한다.(출처: P-Camp)

Ignite
오렐리 후원으로 시애틀에서 처음 시작. 발표자는 20장의 슬라이드가 15초 간격으로 자동으로 넘어가는 5분동안 발표를 진행한다. 자유로운 주제를 가지고 전문가가 아닌 일반사람이 참여하는데, 발표자료 역시 글 보다는 그림, 사진, 메시지 위주가 된다.(출처: Ignite-Wikipidia, Ignite Seoul Intro)
 
페차쿠차(Pecha Kucha Night)
영국출신 건축가 부부가 여행사진을 친구들과 나눠 보고 싶다는 동기에서 처음 시작.
페차쿠차라는 이름은 재잘재잘 이라는 일본어에서 유래했다. 건축, 아트, 디자인에 대한 주제를 다루는데 발표는 20장의 슬라이드를 20초 간격으로 자동으로 넘기면서 6분 40초동안 진행된다. 이를 '20-20'의 규칙이라 부름.(출처: W-Korea 6월,)

제가 아는 것은 여기까지 입니다. 다른 형태를 추가하고 싶으신 분은 댓글 부탁드립니다. 사내에서 맡고 있는 커뮤니티가 하나 있는데 이런 모임들중 하나라도 해봐야 겠습니다.

저작자 표시 비영리 변경 금지
크리에이티브 커먼즈 라이선스
Creative Commons License

Java 교육과 애자일의 만남

Work & Study/TechTalk 2009/06/24 14:24 posted by k16wire
지난번에 이어 다시 강의를 진행했습니다. 정확히 말하면 'J2EE 개발을 위한 교육'이었는데 간단하게 교육내용을 정리해 봤습니다.
  • 교육의 목적: J2EE 시스템을 잘 개발 할 수 있도록 여러 기법들을 학습하기
  • 대상자: 저희 팀원 23명(이중 반은 Java를 몇년전에 해봤음, 심지어 10년된 분도..)
  • 교육내용:
    • 주어진 문제 영역을 이해한다.
    • 산출물(ex 화면정의, ERD, 클래스 다이어그램 등)을 이해한다.
    • Anyframe 기반으로 시스템을 개발한다.
    • 새로운 기법에 대한 강의를 듣는다.
    • 배운것들을 바로 개발에 적용해 본다.
  • 주요 학습 내용: Spring, SpringMVC, TDD, Refactoring, Scrum, Pair programming, Design patterns, Code review, Retrospective, 등
  • 특징: 이론 학습 + 툴 실습 + 개발 이 혼합되어 진행
이외에도 몇가지 학습의욕을 고취하기 위한 장치들이 있었는데 교육을 계속 진행해야 하기 때문에 여기에 적지 못하는게 아쉽네요. (혹시 수강할 팀원들이 알면 재미가 떨어질까 우려되서..^^)

일주일, 40시간을 진행했는데 기대했던 것 이상으로 많은 효과를 얻었습니다. 크게 세가지로 정리해 봤습니다.

첫째, 교육 자체에 대한 만족도가 매우 높았다.
프로젝트에 힘들게 일하다가 교육에 들어오게 되면 일단 교육 받는것 만으로도 즐거워 합니다.^^ 이런 것을 감안해도 다들 교육과정에 대해 "정말 좋은 교육이다."는 소감을 많이 주었습니다. 그것도 한두명이 아니라 거의 전부가 그랬습니다.

둘째, 학습 성취도가 매우 높았다.
사실 J2EE가 그렇게 쉽지는 않습니다. 그럼에도 불구하고 3일(강의등의 활동을 제외 했을때 실질 개발시간)이라는 짧은 시간에 꽤 많은 화면을 개발해 내는것을 보고 정말 놀랐습니다. 여기에는 페어의 역할이 매우 컸다고 생각합니다.

셋째, 팀워크가 좋아졌다.
저희 팀은 팀원들이 너무 많고 서로 다른곳에서 일하다 보니 팀원간에 끈끈함이 부족합니다. 5일간 정말 많이들 친해지더군요. 개중에는 그렇지 못한 친구들도 몇명 보이는걸 보니 개인성향은 어쩔 수 없는 듯 합니다.

그럼 어떻게 이런 효과가 난 걸까요? 전 이전에도 멀티캠퍼스에서 여러 교육과정을 만들고 강의를 한 경험이 있습니다. 그걸 비춰봐도 이건 잘 이해가 안가는 현상입니다. 그래서 나름 그 원인을 분석해 봤습니다.
  • 교육 자체가 즐겁다. 감정이 풍부한 사람이 기억력도 좋다고 합니다. 기억력이 좋으면 당연히 공부도 잘하겠죠. 이번 과정은 재밌게 만들려고 많이 노력했습니다. 웃고 떠들면서 공부하다 보면 지루한지 모르고 교육을 받게 되고 자연스레 집중을 하는거 같습니다.
  • 자기 주도형으로 학습한다. 과거 방식이 개발 분량을 강사가 할당하는 형식이었다면 이번에는 스크럼을 가르치고 스스로 교육기간에 개발할 분량을 스스로 산정합니다. 그리고 개개인의 책임을 강조하니 자습이나 과제를 따로 요구하지 않아도 팀단위로 토의하며 개발을 진행합니다.
  • 팀단위로 학습하고 평가한다. 모든 액티비티를 팀체제로 운영하니 팀원간에 커뮤니케이션이 많아지고 팀간에 선의의 경쟁을 통해 열심히 하게 됩니다.
저를 포함해서 강의를 진행하는 강사들이 교육과정을 만들고 강의하는것 자체를 즐기다 보니 수강하는 팀원들도 과정 자체를 즐기게 된다고 생각합니다. 앞으로 7~8개 차수를 더 진행해야 하는데 다 끝나고 나면 과연 팀이 어떻게 변할지 저도 궁금합니다.

이 다음에는 일전에 애자일컨설팅 블로그에서 본 커크패트릭 모델(Kirkpatrick Model)을 가지고 성과를 측정해 보려고 합니다. 하지만 쉽지는 않아 보이네요.

저작자 표시 비영리 변경 금지
크리에이티브 커먼즈 라이선스
Creative Commons License
ZD Net, 분석, 설계 기법으로서의 테스트 주도 개발, 이종국
이런 제목의 글이 ZD Net에 실리는것을 보니 우리나라에도 애자일이 많이 확대되고 있는거 같아서 기분은 좋네요. 그런데 글 내용은 그냥 그런거 같습니다. 제가 그렇게 생각하는데는 몇가지 이유가 있는데요..
  • 너무 어렵게 설명하고 있습니다.: 관련내용을 잘 알고 있다고 생각했는데 무슨 말을 하는지 이해하느라 몇 번 읽어봐야 했습니다. 나름 이해를 잘한다고 생각하고 있는데..^^
  • 영어를 번역해 놓은것 같은 문장이 많습니다.: 글이 잘 익히지 않는게 마치 번역을 해 놓은듯한 느낌이네요.
  • 내용상에 몇가지 오해의 소지가 있습니다.: TDD를 하면 시스템을 전부 재개발해야 하는 것처럼 설명한 부분, TDD를 하면 더 이상의 테스트가 필요없다 식의 논리는 비 현실적이라 생각됩니다.
요즘들어 글쓰기가 어렵다는걸 부쩍 느끼고 있습니다. ZD Net과 같은 기사는 더 엄히 확힌해야 하지 않을까요.



저작자 표시 비영리 변경 금지
크리에이티브 커먼즈 라이선스
Creative Commons License
TAG TDD, 애자일
지난주 저희회사 신입사원들을ㄹ 대상으로 강의를 했습니다. 강의 내용은 'J2EE 기반의 애플리케이션 개발' - 문제가 서술되어 있고 관련 산출물이 주어지면 이를 가지고 개발을 진행하는 과정

이미 만들어진 강의를 받아서 하는거라 큰 부담은 없었습니다. 하지만 강의전에 같은 강의를 들은 사원들을 인터뷰한 결과 "도무지 뭘 공부한 거야." 하는 말이 절로 나올 정도로 학습 효과가 낮다는걸 확인했습니다.

그래서 강의 내용 자체는 바꿀 시간이 없는 관계로 강의중 진행되는 실습에 스크럼을 접목하기로 했습니다. 제가 기존 강의와 다르게 진행한 부분을 뽑아 봤습니다.
  • 강의 시작전에 체크아웃
  • 강의가 끝나고 매일 매일 팀별로 회고, 전체 공유
  • 첫날 강의 중 진행되는 실습에 대한 계획게임 실시
  • 실습전에 데일리 스크럼 진행
  • 실습을 페어로 진행하도록 가이드
  • 2일 주기로 이터레이션 진행
  • 매  이터레이션마다 스프린트 리뷰 미팅(시연회) 실시
이런식으로 진행하기 위해서 중간중간 미리 준비한 강의자료로 애자일, 스크럼에 대한 강의를 진행했습니다. 그 결과 거의 대부분의 학생들이 "기존에 본인이 받은 교육보다 훨씬 좋다. 이제는 뭘 배웠는지 알거 같다."는 자신에 찬 이야기를 해 주었습니다.



본인이 뭘 공부할지에 대해 명확히 알고, 그걸 학습하고, 학습결과를 매일 검토하면서 학습효과가 높아졌다고 생각합니다. 이를 가능하게  하는데 들어간 돈은 채 3만원도 안들었을거 같습니다.
  • 3M 포스트 잇 소형: 10개
  • 마커펜: 20개
  • 3M 대형 포스트 잇: 2개
작은 실험이었지만 매우 좋았다고 생각하며, 앞으로 저희팀에서 받게될 개발자를 위한 교육과정을 모두 이런 방식으로 운영할 생각입니다.


크리에이티브 커먼즈 라이선스
Creative Commons License
TDD 그룹에서 날라온 메일을 통해 IBM의 스캇 앰블러(Scott Ambler)가 ZD Net에서 인터뷰한 기사를 읽어봤습니다. 본인이 사람들이 애자일을 종교처럼 신봉하게 만든것은 실수였다라고 말하네요.
Agile is a process and is sometimes thought of as a religion, but this just gets in the way in my opinion – I want to get past the rhetoric and get down to fact-based arguments,
그런데 저는 이 말 보다는 아래에 나온 Scale Agile에 대한 의견이 더 끌리네요. 큰 조직에서 개발하다 발생하게 되는 아키텍처에 대한 이슈를 팀웍(teamwork)과 화합(collaboration)으로 해결해야 한다고 조언합니다. 하지만 IBM은 공식으로 그런 용어를 잘 사용안하죠.

중간에 John Collins라는 분석가는 이렇게 말합니다. "애자일은 실패할 여지가 있기 때문에 그냥 집어서 사용해서는 안된다." 맞습니다. 애자일은 보기는 쉬워 보여도 실제 적용하는것은 어렵습니다.

인터뷰 끝부분에 볼랜드사의 애자일 도입 효과가 간단하게 소개되고 있습니다.
우리는 분산환경에서 개발하는 300명의 개발자중 65%가 애자일을 사용하며...그 결과 제품 릴리즈가 100% 성장했다. 릴리즈간에 발견되는 이슈도 50% 줄었으며...그렇다고 내가 애자일 적용이 쉽다는 말은 아니다.
저도 애자일은 좋아하지만 무의미한 애자일 전쟁따위를 하고 싶은 생각은 눈꼽만큼도 없습니다. 그저 즐겁게 잘하고 싶을뿐이죠. ^^


크리에이티브 커먼즈 라이선스
Creative Commons License
좀 됐습니다. 10월 19일부터 4일간 탐험적 테스트에 대한 대가라고 하는 제임스 바흐(James Bach)의 탐험적 테스트 교육을 듣고 왔습니다.
교육은 sten에서 제임스 바흐를 초청하면서 이루어 졌다고 하네요.

교육장은 구로역 근처 가산 디지털 단지에 있는 마리오 타워 8층 STA교육장에서 열렸습니다.

첫날은 제임스 바흐가 진행하지 않고 STEN의 권원일님이 탐험적 테스팅에 대한 일종의 예습으로 진행했습니다,

제임스 바흐가 강연한 첫째날 실습 진행하고 나서 서있는걸 한장 찍어봤습니다.

강연에 사용한 자료를 포함하여 대부분의 문서는 Satisfice.com에 가시면 받아 보실 수 있습니다. 제가 이번 교육을 통해서 배운것들을 몇 가지 정리해 보았습니다.

교육은 수강생들이 이해 할 수 있게 해야 한다는 것
부족하지만 저도 가끔 강의나 발표를 나가기도 합니다. 이 분 강의 참 재밌게 합니다. 강의만 하는게 아니라 간단한 실습을 통해서 사람들이 느낄 수 있게 강의를 합니다.
작은 볼을 가지고 하는 실습이 있었습니다. 한 명을 나오라고 합니다. 고무된 것처럼 보이는 볼을 줍니다. 이 볼을 가지고 테스트 해 보라고 합니다. 볼에 대한 정보를 얻기 위해 질문하면 기밀이기 때문에 말할 수 없다고 합니다. 이 실습은 테스터가 테스트 오라클을 대하는 자세에 대한 실습이었습니다.

수강생들의 참여를 적극적으로 유도합니다.
많은 질문을 던집니다. 슬라이드의 답을 사람들이 줄 때까지 줄기차게 물어봅니다. 아시죠 ? 우리나라 사람들 누가 물어보면 대답 잘 안하는거. ^^; 이분 끈질기게 물어보십니다. 대답 할 수 밖에 없게 만듭니다.
저도 한 가지 대답한게 기억 납니다. "니가 탐험적 테스팅을 수행한다고 가정하고 MS의 모든 솔루션의 Date입력에 대한 부분을 테스트 한다고 했을때 어떻게 테스트를 하겠느냐?" 팀으로 묶어서 이야기 할 시간을 줬는데도 마이크를 가져다 대니 당황되더군요. 그래서 이렇게 답했습니다. "하루에 몰아서 모든 시스템을 테스트 해 보겠다. 그리고 나서 감을 잡은 다음에 세션별로 솔루션을 잡아서 테스트를 진행하겠다." 그랬더니 의외로 좋아하면서 그런 대답을 한건 내가 전 세계를 돌아다니면서 강의하면서 니가 처음이다라고 하더군요. ^^;

탐험적 테스팅에 대해서 배웠습니다.
애자일 시범적용 프로젝트를 수행하면서 이미 탐험적 테스팅을 써봤다고 생각했습니다. 하지만 역시 처음 적용한거라 부족했던 부분이 많더군요. 제가 탐험적 테스팅에 갖고 있던 오해를 많이 없앨 수 있었습니다.
"그냥 스크립트를 테스트를 수행하면서 쓰는거 아냐."라고 생각했는데 스크립트 테스팅과의 결정적 차이는 그게 아니더군요. 반복을 통해서 테스트 프로세스를 지속적으로 개선하고 테스터가 테스트 작업 자체에 더 집중하도록 하는것이 탐험적 테스팅에서 정말 중요한 포인트 같습니다.

영어로 잘 말하는 것
동시통역이 있었지만 그냥 들었습니다. 제가 영어를 잘해서라기 보다는 이분이 정말 영어를 아주 또박또박 말해주더군요. 보통은 첨에는 천천히 말하다 갈수록 빨라지던데 이분은 강의를 많이 해서 그런지 다르더군요.
사실 저도 영어를 말할 때 괜히 빨리합니다. 잘하지도 못하면서 -_-;; 여러분 영어 천천히 합시다.

끝으로 세미나에 참가 못한 분들을 위해 구글 비디오의 동영상 강의를 링크합니다. 애자일 이야기에 올라온 탐험적 테스팅에 대한 글도 읽어보세요.




크리에이티브 커먼즈 라이선스
Creative Commons License
이번주 일요일(26) 저녁에 강남대로점 토즈에서 애자일 컨설턴트인 스티브 프리만(Steve Freeman)씨의 강연이 있습니다. 현재도 온오프믹스에서 신청을 받고 있으니 관심 있으시면 얼른 신청하세요.
저는 당연히 갑니다. ^^

구글 비디오에서 FIT에 대해 설명하는 동영상을 찾았습니다.



크리에이티브 커먼즈 라이선스
Creative Commons License