DevOps 2년차

Work & Study/애자일 개발 2014/12/01 10:19 posted by k16wire

처음 DevOps라는 용어를 접하고 내용을 살펴보면서 들었던 생각은

  • 실체가 뭐냐???
  • 애자일에 대한 새로운 키워드인가
  • CD가 전부 아닌가
이 정도였습니다. 그런데 작년부터 지금까지 나름 DevOps를 위해 일한지 2년이 다되가는 시점에 뭘 배우고 뭘 했는지 생각해보니 약간 달라졌네요.
  • DevOps는 운영을 편하게 한다.
  • 인프라스트럭처가 받쳐주지 않는 DevOps는 너무너무 어렵다.
  • Legacy 시스템은 DevOps 적용할때 중요한 장애요소이다.
개발과 애자일에 대한 경험이 많아서 큰 문제없을거라 생각했던 DevOps. 하지만 복병은 인프라였습니다. 1년반동안 인프라에대한 지식과 경험은 정말 많이 늘었습니다.

Docker 까지만 JARVIS에 붙이면 처음에 그렸던 아키텍처가 모두 완성될거 같네요.


저작자 표시 비영리 변경 금지

'Work & Study > 애자일 개발' 카테고리의 다른 글

DevOps 2년차  (0) 2014/12/01
레거시 코드 어디까지 가봤니  (0) 2014/09/18
Agile Korea 2013 발표 영상 - 켄지 히라나베  (0) 2014/07/09
PMI 회고  (0) 2013/12/15
스크럼 팀에서의 팀장의 역할  (2) 2013/12/10
자율이 오히려 부담이 될수있다.  (0) 2013/11/29
TAG DevOps

NIPA의 SW 자산뱅크는 공공 및 민간의 우수 SW 자산을 공유하는 서비스입니다. 지난달 매주 발행되는 웹진에 기사를 써달라는 요청을 받았습니다. 어떤 내용을 쓸까 고민하다가 평소 사내에서 진행하던 '클린코드와 코드리뷰' 교육 내용을 글로 정리해서 보내드렸는데 그게 오늘 나왔네요.


클린 코드에 관심있는 개발자 분이라면 한번 읽어보시길 권해드립니다.


SW 자산뱅크 기사 링크: https://www.swbank.kr/introduce/bbs/knowledgeChannelView.do?nttId=226

저작자 표시 비영리 변경 금지

'Work & Study > 애자일 개발' 카테고리의 다른 글

DevOps 2년차  (0) 2014/12/01
레거시 코드 어디까지 가봤니  (0) 2014/09/18
Agile Korea 2013 발표 영상 - 켄지 히라나베  (0) 2014/07/09
PMI 회고  (0) 2013/12/15
스크럼 팀에서의 팀장의 역할  (2) 2013/12/10
자율이 오히려 부담이 될수있다.  (0) 2013/11/29

작년에 진행했던 애자일 코리아 2013 컨퍼런스 발표 영상을 공개하려 합니다.

첫번째 영상은 켄지 상의 발표입니다.

 




http://www.youtube.com/watch?v=s72ElNxaGPE


저작자 표시 비영리 변경 금지

'Work & Study > 애자일 개발' 카테고리의 다른 글

DevOps 2년차  (0) 2014/12/01
레거시 코드 어디까지 가봤니  (0) 2014/09/18
Agile Korea 2013 발표 영상 - 켄지 히라나베  (0) 2014/07/09
PMI 회고  (0) 2013/12/15
스크럼 팀에서의 팀장의 역할  (2) 2013/12/10
자율이 오히려 부담이 될수있다.  (0) 2013/11/29

PMI 회고

Work & Study/애자일 개발 2013/12/15 23:32 posted by k16wire

PMI 회고는 가장 흔하게 많이 사용하는 회고입니다. 사용하기 쉽지만 Minus를 쓰라고 하면 주저하는 사람들이 많습니다. Minus를 내려면 훈련이 필요합니다. Minus에 익숙치 않은 사람들에게 어떤 말을 해주면 좋을까요.

Minus는 비판이 아니라 제안입니다. 현재 상태를 개선하고자 하는 제안이자 아이디어입니다.

개선을 하려면 문제의식이 있어야 하고, 제안을 하려면 유심히 살펴봐야 합니다. 건성으로 아무 생각없이 보면 어떤 제안도 떠오르지 않습니다. 회고를 해보세요. 그러면 평소 주의깊게 관찰하고 문제의식을 갖고있는 사람이 누구인지 알게될겁니다.

 

저작자 표시 비영리 변경 금지



애자일 방법론의 하나인 스크럼에는 크게 3가지 역할이 존재합니다.:제품책임자, 스크럼마스터, 스크럼 팀  스크럼 프로세스 모델 어디에도 팀장의 역할은 없습니다. 


스크럼팀의 궁극적인 형태는 자기 조직적인 팀(Self Management Team) 입니다. 자기 조직화된 팀이 무엇입니까? 팀장이 업무를 일일이 할당하는것이 아니라 각자가 직접 자기가 할일을 플래닝하고 진행하는 팀입니다. 자기 조직적인 팀은 팀장이 없는 팀일까요.


스크럼뿐 아니라 애자일 조직에서는 전통적인 형태의 관리 팀장은 설 자리를 잃어버립니다. 애자일 조직에 맞는 팀장 리더십은 섬김의 리더(Servant Leader)입니다. 과거처럼 통제하고 관리하려 든다면 애자일의 장점은 살릴수 없을뿐더러 효과도 볼 수가 없습니다. 


스크럼 도입시 실무를 진행하는 사람에게 최대한의 권한을 주는게 중요합니다. 하지만 권한 위임은 어렵습니다. 흔히 이렇게 말하죠.

권한은 위임할 수 있지만 책임은 위임할 수 없다.

 기존 조직구조는 그대로 남겨둔채 권한만 위임한다면 팀장은 책임만 떠안게 될 확률이 높습니다. 이런 상황에 팔짱끼고 가만히 앉아있을 팀장은 어디에도 없습니다. 프로젝트에 적극적으로 개입하게 됩니다. 

그래서 가능하다면 조직구조를 프로젝트에 맞게 바꿔야 합니다. 평가체계도 바꿔야 합니다. 개인평가보다는 스크럼 팀단위 평가가 이루어져야 합니다.


스크럼과 같은 애자일 개발을 적용한다면 팀장은 손 털고 나가야 할까요? 아닙니다. 오히려 더 고도의 교묘할 정도의 관리능력을 발휘할 수 있어야 합니다. 팀원에게 (일을) 시키고 쪼고 (했는지 안했는지) 일일히 체크해서 성과를 내는게 아니라 (팀원 각자가) 스스로 알아서 일을 챙기고 꾸려나가도록 만들어야 합니다. 비유를 하자면 공부 열심히 하라고 다그치는 부모에서 스스로 공부하도록 배려하는 부모가 되야 하는 것이죠.


어렵죠. 팀장의 역할이 사라지는게 아니라 한 차원 높아지는거라고 생각합니다.

  


저작자 표시 비영리 변경 금지



요즘 사내에서 애자일 교육을 진행하면서 몇가지 스크럼에 대한 단상이 떠올랐습니다. 


스크럼 프로젝트에서는 매 스프린트마다 누가 무슨일을 할지를 스스로 정하라고 이야기합니다. 하지만 모두가 이런 방식에 익숙한것은 아닙니다. 그래서 처음 이런 방식으로 업무배정을 하게되면 팀원들은 매우 불안해 합니다. 편안함을 느끼지 못합니다. 내가 할수 있을까. 해도 되나. 


팀의 리더도 불안해 합니다. 우리 팀에는 숙련된 팀원외에 아직 경험이나 역량이 부족한 팀원들이 많은데..이런 방식으로 일하는게 맞을까? 


자율이 오히려 부담으로 작용하는 것 입니다.

이런 부분을 배려하는게 필요합니다.


저작자 표시 비영리 변경 금지


출처: http://blog.jr0cket.co.uk/2010/08/my-favourite-estimation-technique.html


어느 팀장님이 개발자에게 물어봅니다. 


이 스토리 개발하려면 얼마나 걸릴까? 

한 3일이면 될거 같은데요.


정말 3일이면 될까요? 이런 경우는 2가지 입니다. 

정말 개발을 잘하는 슈퍼 개발자이거나 개발을 많이 안해본 초보 개발자이거나

여러분이 프로젝트에 참여했다고 했을때 여러분 주변의 개발자가 슈퍼 개발자일 경우가 많을까요? 아니면 보통내지는 초보 개발자인경우가 많을까요? 당연히 후자의 경우가 많을겁니다.

이런 개발자들이 말하는 개발완료는 무엇을 의미할까요? 좀 심하게 말하면 코딩 다했고 자기 로컬 PC에서 잘 동작하면 개발완료라고 말할수도 있습니다. 하지만 이게 다가 아니죠.

  • 테스트도 해야하고
  • 개발서버 내지는 운영서버에 배포하기 위해서 빌드/배포도 해야합니다. 
  • 정적분석으로 코딩 표준은 지켰는지 
  • 잠재결함은 없는지
  • 보안진단
  • QA의 제3자 테스트
한달이라는 기간이 긴것 같지만 주말 제외하면 20일입니다. 여기에 생산성 지표를 70%로 잡는다면 약 14일이죠. 여기에 앞서 이야기한 작업들이 선행되다거나 후행된다면 실제 개발에 쓸수있는 기간은 더 줄어듭니다. 이런 상호간의 차이를 줄이기 위해서는 개발완료(Definition of Done)에 대한 의미를 프로젝트에 참여하는 사람들이 똑같이 이해하도록 하는게 중요합니다.

팀장님들 개발자가 3일 걸린다고 말하면 최대 한달 걸릴지도 모른다고 생각하세요.


저작자 표시 비영리 변경 금지

오는 9월7일 토요일 열리는 애자일 코리아 컨퍼런스 2013의 참가 신청을 받고 있습니다. http://onoffmix.com/event/18754


자세한 프로그램은 아래 포스터를 참고하세요.




저작자 표시 비영리 변경 금지



2012년 9월1일에 열렸던 Agile Korea 2012 영상을 모두 공개합니다. Agile Korea Conference에 대해 잘 모르시는 분은 컨퍼런스 사이트(http://agilekorea.org/event/2012)를 참고하세요.

  1. 애자일을 실천하는 사람들이 격는 어려움(최보나)
  2. Lean Startup in Practice(정지웅)
  3. 애자일하게 스펙 작성하기(황상철)
  4. OEC facilitation Season2(채홍미)
  5. Traditional vs Agile(경기원)
  6. 애자일을 통하여 얻은것(황순삼)
  7. 협업도구를 활용한 Agile Practice 활용사례(한문근)
  8. 개인이 조직을 바꾸는 법(김창준)
  9. 유니콘 목장(정기원)
  10. User stories workshop(박준표, 최보나)
이번에 공개된 영상들은 발표자 분들로부터 사전에 영상촬영 및 공개에 대한 허락을 받은 영상들입니다. 컨퍼런스 프로그램에 있으나 영상이 없는 발표들은 다음과 같은 사항때문에 영상 자체가 없습니다.
  • 발표자 분이 영상촬영 거부하신 경우
  • 촬영 자체를 진행하지 못한 경우
  • 촬영을 했으나 잘못되어 제대로 촬영되지 못한 경우
2012년 행사에 참석하지 못하신 분들은 본 영상을 통해서 뒤늦게나마 행사를 즐기셨으면 좋겠습니다. 그리고 2013년 8월말에 개최될 Agile Korea 2013도 많은 성원과 도움 부탁드립니다. 

ps) 애자일 코리아 페이스북 그룹(https://www.facebook.com/groups/267408126612451/)에도 많이 참여해 주세요. 참석자 수가 많은것도 행사를 진행하는데 큰 힘이 됩니다.



저작자 표시 비영리 변경 금지

2012년 애자일 현황

Work & Study/애자일 개발 2013/04/23 00:19 posted by k16wire


애자일 프로젝트 관리 도구 및 교육을 진행하는 버전원(VersionOne)에서 2012년 애자일 현황에 대한 설문조사 결과를 2013년 2월 26일 발표했습니다. 설문조사 결과 전문은 아래 URL에서 다운로드 가능합니다.

http://www.versionone.com/state-of-agile-survey-results/


애자일 강의를 준비하다보면 '트렌드'에 대한 자료가 필요한데 전 이 설문조사를 자주 애용합니다. 특히 이번에는 인포그래픽으로 만들어져서 깔끔하니 좋네요. 몇가지 흥미로운것만 추렸습니다.

  • 애자일 도입에 실패한 이유는? 적절한 사람을 찾지 못해서, 팀 문화를 정착시키지 못해서
  • 애자일 도입에 성공한 이유는? 경영진의 스폰서쉽(23%), 교육/워크샵(18%), 공통의 도구 사용(13%)
  • 어떤 애자일 방법론을 사용하는가? 스크럼(54%), 스크럼과 XP(11%), 자체(9%)
  • 사용하는 애자일 기법은? 일일스크럼(85%), 단위 테스팅(74%), CI(56%), CD(23%)
  • 애자일 도입의 걸림돌은? 조직문화에 대한 변화(52%), 변화에 대한 저항(41%)

자료를 전부 살펴보기 싫으신 분들은 설문조사를 분석한 IDG의 "애자일 개발의 발목을 잡는 것은 문화와 사람"을 읽어보세요.


저작자 표시 비영리 변경 금지

DevOps 레퍼런스

Work & Study/애자일 개발 2013/04/04 09:19 posted by k16wire

DevOps에 대한 내용이 궁금해서 좀 찾아봤습니다. 


KTH 개발자 블로그 & H3 Conference

미물님 블로그
DevOps와 NoOps에 대하여 유용한 링크가 많이 들어있습니다.

공감 세미나 2회

한빛미디어:디봅스(DevOps, 개발운영) 이란?

아름프로 블로그: Continuous Delivery vs Continuous Depoyment 

DevOpsDay 
DevOps 관련 컨퍼런스인 DevOpsDay 사이트(http://devopsdays.org/)에도 좋은자료가 많군요. 컨퍼런스 발표영상을 공개해놓은것도 있는데 전부인지는 모르겠습니다.

컨설팅
Chef에 대한 호스팅과 컨설팅을 제공하는 회사: http://www.opscode.com/

외국 사례

한동안은 DevOps 구축에 매진할거 같습니다. 재밌을거 같네요.


저작자 표시 비영리 변경 금지

지난 일주일간 대구 계명대학교에서 FusionSoft 엔지니어분들을 대상으로 애자일 강의를 진행했습니다. FusionSoft는 대구에 있는 소프트웨어 개발을 전문으로 하는 기업인데 개발자가 약 150명정도 되는 꽤 큰 기업이라고 합니다. 이번에 전사적으로 애자일을 도입하고자 NIPA를 통해 강의를 요청하셔서 진행하게 되었습니다. 


강의 제목을 고민 하다가 딱 떠오르는 제목이 있더군요. "애자일 SW개발 101" 

첫날 수강생들의 애자일 경험과 지식을 확인해보니 대부분 초보자 분들이어서 일단 눈 높이는 잘 맞췄다는 생각이 들었습니다.


기간이 4일이나 되어 욕심을 좀 부렸는데 시간내에 모든 내용을 소화하기는 어려웠습니다. 역시 계획은 깨지라고 있나 봅니다. 그래도 강의를 듣는분들이 4일 내내 적극적으로 참여해주시고 긍정적인 피드백을 많이 주셔서 강의하는 저도 뿌듯했습니다. 교육에서 다루었던 내용은 아래와 같습니다.

  • 애자일 개발 전반에 대한 소개
  • 스크럼 소개
  • 애자일 게임: 칸반게임
  • 스토리 기반의 플래닝
  • 스펙 워크샵
  • XP 소개
  • 회고
  • 애자일 도입에 대한 OST

아래 사진은 강의중에 진행했던 워크샵과 토론을 찍은 사진들입니다.


단순 강의 형태가 아니라 같이 참여하는 워크샵과 실습을 병행했던게 수강생들의 만족도를 크게 높여준거라 생각됩니다. 이번 교육을 위해 준비했던 내용을 좀 더 보강하면 괜찮은 애자일 교육 프로그램이 하나 나올거 같다는 생각도 드네요.  (관련해서 교육이 필요하신 분 계시면 연락주세요.)


이번 교육을 통해 FusionSoft에 애자일 SW 개발이 정착되길 기원합니다. 다들 파이팅 하세요. ^^;



저작자 표시 비영리 변경 금지

사내 사외를 막론하고 요즘에는 강의를 잘 안합니다. 그동안 많이 진행해서 지친것도 있지만 회사 분위기가 좀 바뀌면서 사내강의가 많이 줄은것도 큰 이유입니다. 지난달 NTS에서 2013년 상반기 교육을 진행하는데 애자일 강의를 해달라는 요청을 받았습니다. 

"Agile Bootcamp & Scrum" 이라는 제목으로 애자일 소프트웨어 개발 전반에 대한 내용과 스크럼에 대한 경험을 설명하는 교육을 2번에 걸쳐 진행했습니다. 

평소 교육 기회가 많지 않았는지 많은 분들이 참여하셨고 NHN에서보다 더 열심히 참여하시는걸 느낄수 있었습니다. 아래 사진은 교육중에 칸반게임을 하는 모습들입니다. 



듣는 분들이 열심이어서 오랜만에 재밌게 강의를 진행했던거 같네요. 사실 사내교육은 강의시간도 3시간 미만이고 해서 관련 영상을 본다거나 질문이나 애자일 게임 같은것을 진행하지 못했거든요. 이번엔 강의시간을 넉넉히 잡은 덕분에 편하게 강의를 진행했던거 같습니다. NHN에서 제가 진행한 마지막 애자일 교육이 됐네요.


ps) 2월에는 시간적으로 여유가 좀 있네요. 혹시 애자일 관련 교육이나 강연이 필요하신 분 연락주시면 도움을 드리겠습니다.

저작자 표시 비영리 변경 금지

지난해 NIPA/소프트웨어 공학센터 후원으로 많은분들과 같이 작업했던 "애자일 SW 개발 101" 가이드 북에 대한 PDF 파일이 공개되었습니다.

이 가이드 북은 소프트웨어 공학센터 사이트 '지식마당 > 보고서/지침서' 메뉴에서 무료로 다운로드 받으실수 있으니 많이 받아 보시고 업무에 참고하시면 좋겠습니다. 


ps) 저작권 때문에 파일에 대한 직접적인 링크는 제공하지 않으니 많이 방문하셔서 앞으로도 이런 작업을 계속할수 있게 지원해주세요.




전자신문과 디지털타임즈에 홍보 기사가 떳네요.

http://www.etnews.com/news/computing/solution/2704622_1476.html

http://www.dt.co.kr/contents.html?article_no=2013011002019960600003



저작자 표시 비영리 변경 금지

일전에 공지했던 Play Framework 스터디에 대한 후속공지입니다.


스터디 교재

현재까지 5분이 신청을 하셨습니다. 이분들과 어떻게 스터디를 진행할까 고민해봤는데 역시 스터디는 교재가 있어야 스터디가 끝났을때 뭔가 이루었다는 느낌을 받을수 있을거 같습니다.

그래서 교재는 Manning사의 Play for Scala로 정했습니다. 현재 MEAP 버전으로 판매중이니 pdf로 구입하시면 될거 같네요. 

 Play for Java가 아니라 Play for Scala를 선택한 이유는 제가 Scala를 잘해서가 아닙니다. 제대로 Play를 이해하려면 Scala를 모르면 안되기 때문입니다. 저랑 이번기회에 Scala에 대한 맛도 같이 보시죠.


스터디 진행

온라인과 오프라인을 병행해서 진행하겠습니다. 한번 온라인이면 한번 오프라인. 처음에는 오프라인으로 할거고 같이 코딩을 해보려면 노트북이 있어야 좋을거 같네요.

 

첫 스터디는 1월15일로 생각중인데 확실한 날짜는 신청하신분들과 맞춰서 정하겠습니다. 스터디 신청하신분들 이 글에 비밀댓글로 연락처(이메일, 핸드폰 번호) 남겨주세요.


저작자 표시 비영리 변경 금지

보나님이 페북에 올린글 Stop Using Story Points 를 읽으면서 번역은 아니고 요약을 좀 해봤습니다.


스토리 포인트는 스프린트 처럼 애자일 하면 떠오르는 용어다. 2007년 의도적으로 스토리 포인트와 개발속도를 적용하지 않으면서 애자일적인 특징을 높히기 위한 실험을 했던 적이있다. 이 실험에서 고정 길이 스프린트(fixed-length-sprint)는 흐름 기반의 워크플로(flow-based workflow)로 바꾸고 일일 스크럼은 잦은 팀 미팅(frequent team huddles)으로 바꿔 진행했다. 프로세스에서 낭비되는 부분을 적극적으로 바꾸다보니 우리의 프로세스는 책에서 말하는 애자일과 사뭇 다르게 보이기도 한다. 그럼 왜 스토리 포인트 사용을 그만둔걸까?


스토리 포인트를 처음 접했을때

1999년 스타트업에서 일할때는 나도 팀의 개발속도를 나타내는 스토리 포인트에 매혹되어 있었다. 관리자들에게도 좋고 팀원들에게도 좋고, 중요도가 떨어지는 기능을 선별할때 특히 유용했다. 스프린트내에 주어진 작업이 끝나면 꼭 필요한 기능(must-have)와 있으면 편리한 기능(nice-have)를 고민하면 되었다. 


그 후 난 8년간 스토리 포인트를 써왔고 그러면서 많은 오해와 잘못된 사용경험을 알게되었다. 처음에는 이런 문제를 사람들에게 더 나은 교육을 진행해야 한다는 징후로 이해했다. 하지만 몇년이 지난뒤 스토리 포인트와 개발속도에 깊은 결함이 있음을 알게되었다.


 비 이성적인 스토리 포인트의 증가

큰 문제가 있음을 처음 알게된것은 2001년 대형 프로젝트에서다. 첫번째 팀은 완전한 애자일로의 전환을 목표로 하는 우리가 만나봤던 최고의 준비된 팀이었다. 이팀은 2년뒤 기한내 높은 성과를 낸 공로로 보너스와 시상을 받았다. 하지만 이 팀은 그 이후에 더 높은 생산성을 요구받게 된다. 이 팀의 평균 개발속도가 52였는데 80으로 높히라는 요구였다. 어떻게 했냐고 물으니 이런 대답을 들었다. "요즘 여기서는 재채기만 해도 스토리 포인트로 잡아요."

개발속도가 빨라진것처럼 보이기 위해서 스토리 포인트를 얼마든지 오용할수 있던것이다. 이 경험은 스토리 포인트에 대한 나의 믿음을 약화시켰다. 하지만 한편으로 이런 생각을 했다. 문제는 교육이 충분치 않았던게 아닐까? 2004년 스토리 포인트 사용을 그만두기까지 나와 내 동료들은 관리자와 스토리 포인트를 잘못 사용하는 사람들에게 두배의 노력으로 교육을 진행했다.

 

예측가능성을 위해 품질을 희생하다.

추정을 맞추기 위해서 하는 첫번째 작업이 TDD나 리팩토링을 생략하는 것이다. 품질을 희생하면서 납기일을 맞추려는 팀을 자주 봤다. 수년동안 수강생들이 품질높은 코드를 가진 기능을 배포하는게 어떻다는것을 경험하도록 도우면서 이 공통적인 문제를 역설했다. 

위대한 팀들이 일관된 개발속도를 유지하면서 동시에 기술적으로 뛰어난 팀이라는 사실을 설명했다. 이 내용은 사실이지만 그런팀은 드물었고 일관성은 팀 크기가 변하거나 외부의 압력때문에 변하곤했다.

더 많은 해가 지난뒤 일관된 개발속도를 유지하는게 예측이나 추정을 하는데도 도움이 되기 때문에 중요하다는 생각이 들었다. 그럼에도 많은 팀들이 품질을 희생하고 기술적인 빚을 지고 예쁜 소멸차트를 유지하려한다.


포인트로 팀 비교하기

몇년뒤 서로 다른회사에서 일하는 몇명의 관리자들이 이렇게 말하는것을 들었다. "왜 팀X는 스프린트마다 24 스토리 포인트를 처리하는데 팀Y는 12 스토리 포인트밖에 못 끝내지? 팀크기는 같은데 말야 왜 차이가 나는걸까?" 이 관리자들은 개발속도를 팀의 역량에 대한 지표로 보기보다는 성과측정의 지표로 간주하는 함정에 빠진 것이다. 교육할때 팀을 개발속도로 비교하지 말라고 하지만 많은 사람들이 그런 비교를 당연하다고 여기는게 실제로 문제가 된다.

2005년도에는 팀마다 스토리포인트를 좋아하는 과일로 부르도록 함으로서 이 문제를 처리해보려 했다. 한 팀은 개발속도를 오렌지로 다른 팀은 사과, 또 다른팀은 키위 이런식으로 부르게 했다.

그러고 나서 관리자가 팀간의 개발속도를 비교하려 할때 나는 이렇게 말했다. "사과와 오렌지는 비교할수 없어요"

과일을 이용한 접근이 팀간 개발속도 비교를 지적하는데 도움은 되었지만 스토리포인트를 잘못 사용하지 않도록 하는것보다는 더 단순하고 에러가 생기지 않는 방법을 쓰는게 더 낫지 않을까 하는 생각이 드는것은 어쩔수 없었다.


스토리 포인트 혼란: Are We NUTs?

많은 사람들이 스토리 포인트를 사용하는게 정당하다고 하는데 그렇게 말하는 이유가 사람들이 실제 시간을 이용해 추정하는데 익숙치 않기 때문이라고 말한다. 그렇게 말하는 이유로서 실제로 작업을 완료하는데 걸리는 시간을 추정하는것보다 작업의 크기를 추정하는게 더 낫기 때문이라고들 말한다.

사실 사람은 무슨 측정단위를 사용하느냐와 무관하게 보통 추정에 익숙치 않다.

나중에 보여주겠지만 자주 재추정을 할때가 더 나은 추정을 하게된다.

스토리포인트는 이슈를 더 혼란에 빠뜨릴 뿐이다.

시간을 이용해 추정할때 생기는 질문들은 스토리 포인트에서도 똑같이 생긴다.


이런 것들을 이용하기 위해서 우리가 배워하는 것은

  • 그것들이 무엇이고
  • 어떻게 사용하고
  • 그것들을 잘못 사용하지 않는 많은 방법이 있는지
스토리 포인트에 대한 대부분의 교육에서는 사람들간의 저항을 잘 다루는 방법을 가르친다.
신참들은 스토리 포인트를 가지고 추정하는것에 불편함을 느끼기 때문에 스토리 포인트를 실제 시간으로 자주 맵핑해준다.
의미를 잘 아는 애자일 전문가들은 초심자들을 교육시키는데 최선을 다한다. 어떻게 스토리 포인트가 티셔츠 크기나 피보나치 수열에 해당하는지를 설명한다.
2005년 우리 고객중 한명은 스토리 포인트가 혼란스럽다고 NUTs(Nebulous Unit of Time)라고 이름을 바꿔버렸다.
스토리포인트에 대한 잘못된 이해와 사용은 시간이 갈수록 커진다. 특히 하나의 프로세스 처럼 팀에서 부서로 다시 회사전체로 확산된다.
이런 잘못된 이해와 오용을 바로잡으려면 시간과 에너지가 들어간다. 스토리 포인트와 개발속도를 계산하는 일은 애자일을 처음 시작하는 팀에게 불필요한 혼란을 야기시키는 부자연스러운 기법이다.

요약으로 시작했느데 하다보니 번역이 되네요. 이놈의 직업병은 어쩔수 없는걸까요. 글이 길어서 나머지는 다음번 포스트에 계속하겠습니다.


저작자 표시 비영리 변경 금지

이번해 Agile Conference에는 헨리크리닉버그가 키노트 연사로 참여했습니다.

요즘 그의 관심사를 반영하듯 내용은 린(Lean) 이네요.


http://blog.crisp.se/2012/08/14/henrikkniberg/lean-from-the-trenches-agile2012


저작자 표시 비영리 변경 금지

'Work & Study > 애자일 개발' 카테고리의 다른 글

Play Framework 스터디 방향  (7) 2013/01/02
스토리 포인트는 이제 그만 1편  (0) 2012/10/26
Agile 2012 Keynote "Lean frm the Trenches"  (0) 2012/09/18
린에 대한 사례연구  (0) 2012/09/18
프로그래머로 산다는것  (4) 2012/09/15
Agile : An Introduction  (0) 2012/09/13

린에 대한 사례연구

Work & Study/애자일 개발 2012/09/18 12:47 posted by k16wire

애자일코리아에서 연사로 오셨던 황순삼님의 린(Lean)에 대한 글이 소프트웨어 공학 웹진에 실렸네요.



http://www.software.kr/mbs/swkr/jsp/board/view.jsp?spage=1&boardId=183&boardSeq=619327&mcategoryId=&id=swkr_040500000000


저작자 표시 비영리 변경 금지

지난 3월 책을 쓰기 시작했습니다라는 짧은 포스트를 올린적이 있습니다.

그 뒤로 6개월이나 흘렀네요. 드디어 끝났습니다. 짝짝짝  오는 9월26일 출간예정이라고 하네요. 


자세한 소개는 로드북 사이트에 가시면 보실수 있습니다.   



그나저나 오늘은 피곤한데 잠이 오지 않네요. :-)


ps) 예약 판매가 시작되었네요.

http://www.yes24.com/24/Goods/7573333?Acode=101


저작자 표시 비영리 변경 금지

Agile : An Introduction

Work & Study/애자일 개발 2012/09/13 14:16 posted by k16wire

애자일을 설명하는 동영상. 이런거 이제 참 많은데 이 영상도 괜찮네요.


http://youtu.be/OJflDE6OaSc


저작자 표시 비영리 변경 금지

이제 애자일 선언문을 한글로 볼수 있습니다. 아래 URL에서 확인하시면 됩니다.


http://agilemanifesto.org/iso/ko/


이미 많은 책이나 블로그에서 번역되어 돌아다니고 있지만 그래도 이렇게 원본 사이트를 통해 볼수 있으니 참 좋네요.

저작자 표시 비영리 변경 금지

두번째 컨퍼런스를 성황리에 마쳤습니다. 몇달동안 고생했던 기억이 생생할때 다음을 위해서 정리해보려 합니다.


지난해 첫번째 애자일 컨퍼런스를 열때는 어떻게든 열기만 하면 좋겠다는 생각뿐이었습니다. 행사를 열겠다고 말은 해놓고 돈도, 장소도, 사람도 준비된게 아무것도 없었거든요. 하지만 한번 하고 나니 사람인지라 욕심이 생기더군요. 그래서 이번해에는 오랜 시간 여러가지 준비를 차곡차곡 해나갔습니다.


처음 떠올린게 로고입니다. 뭔가 대표할만한 이미지나 로고가 있다면 컨퍼런스의 ID(Identity)를 확실히 할수 있고 준비도 수월해 보였습니다. 이번에 만든 애자일 코리아 컨퍼런스 로고입니다.



두번째는 영상입니다. 사람들에게 작년 행사가 어떠했다는것을 알리고 이번 행사에 오고싶게 만들려면 작년에 찍어놓은 영상을 활용해야 겠다고 생각했습니다. Agile Korea 2011 하일라이트 영상입니다.



세번째는 컨퍼런스 사이트입니다. 명색이 개발자인데 제대로된 사이트 하나 없으면 되겠냐는 생각에 시작했는데 만만한 작업은 아니더군요. 공지부터 참가자 접수, 발표자 접수까지 모든것을 사이트에서 하려 했는데 만만치 않았습니다. 기능구현도 구현이지만 더 큰 문제는 디자인이더군요. 2% 부족했다는 생각입니다.

http://agilekorea.org/event/2012


네번째는 연사입니다. 작년에도 연사진은 절대 뒤지지 않았다고 자부합니다만 이번에는 발표내용에 대한 스펙트럼을 확장할 필요가 있다는 생각을 했습니다. 그래서 기업사례, 퍼실리테이션, 린스타트업, TDD 등 여러 내용을 준비했고 기대하지도 않았던 외국연사까지 참여해줘서 더욱 풍성한 프로그램이 된거 같네요. 연사료 한푼 안드리면서 발표를 부탁드렸는데도 흔쾌히 수락해주신 연사분들께 감사드립니다. 더 좋은 컨퍼런스로 성장시켜서 발표하신분들의 이름을 널리 알려드리겠습니다. ^^;



준비를 많이 해놓은 덕분인지 참가자 접수도 작년과 달리 만 하루도 안되어 마감되는 인기를 끌었습니다. 120명이지만 유료에 변변한 홍보도 하지 않았는데 이정도면 대단한거라고 생각합니다. 장소 여건상 작년보다 인원이 좀 줄은것도 있지만 작년에 좋은 반응이 많아서라고 생각하렵니다. ㅎㅎ


로고가 이뻐서 인가요. 컨퍼런스 기념으로 만든 물건들도 예쁘게 잘 나왔네요.


행사준비에 많은 돈이 들어갔지만 다들 맘에 들어하며 탐내 하셔서 '돈 쓴' 보람이 느껴졌습니다. ^^; 

스폰서로 도움주신 한국 마이크로소프트, SK플래닛, 인사이트, 에이콘 분들께 감사드립니다.


마지막은 자원 활동가들입니다. 작년에 이어 이번 해에도 많은 분들이 기획단계부터 자발적으로 참여해 주셨고 행사 당일에는 30명 가까운 분들이 새벽부터 달려와서 행사장 꾸미기부터 자리배치까지 궃은일을 마다않고 준비해주셨습니다. 작년부터 계속 같이 준비하는 분도 계시고, 작년에는 참가자였다가 이번에는 같이 준비하고 싶다고 참여하신 분도 계십니다. 모두 모두 감사드리고 이 분들이 지치지 않고 내년, 내후년에도 같이 갈수 있으면 좋겠네요.


두번째 컨퍼런스를 준비하면서 가장 신경쓴 부분은 지속가능성입니다. 일회성으로 끝나지 않고 지속된다면 사람들이 여기에 참여하기 위해서라도 경험과 지식을 정리하지 않을까, 참석하는 사람들도 더 많이 늘어나지 않을까 생각합니다. 하지만 쉬운일이 아니네요. 관심있는 기업이나 개인들의 많은 후원 부탁드립니다.


참가신청이 120명이었는데 당일 오신분들이 103명 입니다. 취소자를 감안하면 90%에 가까운 참석률이었네요. 게다가 BOF가 끝나는 저녁6시까지도 많은 분들이 남아서 행사를 같이했다는 점도 애자일컨퍼런스 참석자들이 어떤 사람들이라는것을 보여준것 같습니다.


행사는 끝났지만 마무리 작업에 적지않은 노력과 시간이 들어갑니다. 게다가 이번에는 영상촬영까지 해서 편집된 결과를 공유도 해야하고 할일이 많네요. 그래도 작년처럼 한동안 휴식에 들어가려 합니다. 이젠 나이를 먹어서 기력이..^^;


준비에 도움주신 분들, 행사에 와주신 분들, 모두 모두 감사드리며 내년에 다시 만나요.




ps) 컨퍼런스 사진이 올라왔습니다. 아래 URL에서 확인가능합니다.


ps2) 컨퍼런스에 대한 어떤 피드백도 좋습니다. 아래 URL로 입력가능하니 피드백 많이 주세요.


[1] 행사사진: http://www.flickr.com/photos/masterguru/sets/72157631365098180/

[2] 행사사진: https://plus.google.com/photos/109212086172537138593/albums/5783792345003502161

[3] 행사 피드백 URL: http://goo.gl/RschE

[4] 후기모음

 http://ihoney.pe.kr/1097

 http://blog.outsider.ne.kr/tag/%EC%95%A0%EC%9E%90%EC%9D%BC%20%EC%BD%94%EB%A6%AC%EC%95%84

 http://readme.skplanet.co.kr/?p=2786

http://dukeom.wordpress.com/tag/agile-korea-conference-2012/

http://cutewebi.tistory.com/775



저작자 표시 비영리 변경 금지

작년에 이어 이번해에도 Agile Korea Conference를 개최합니다.

그동안 행사준비로 정신없이 지내느라 막상 제 블로그에는 올리지도 못했네요. 


행사 사이트는 http://agilekorea.org/event/2012 입니다. 방문하시면 컨퍼런스에 참여하는 연사들과 세션에 대한 정보를 확인하실수 있습니다.


참가자 접수가 금일(22일) 13시부터 온오프믹스를 통해 진행될 예정입니다. 지난해보다 규모가 작아서 조기 마감이 예상되니 관심있는 분들은 많은 참여 부탁드립니다.


온오프믹스 참가신청 바로가기: http://onoffmix.com/event/8778


저작자 표시 비영리 변경 금지

Play 2.1 마일스톤

Work & Study/애자일 개발 2012/05/11 11:08 posted by k16wire

Play 2.0은 첫번째 메이저 버전이어서 그런지 불안한 부분이 많이 보입니다. 2.1이 언제 나올지 궁금해서 찾아보니 Play 이슈를 관리하는 lighthousapp에 2.1 마일스톤에 대한 내용이 있네요. 아직도 티켓이 16개나 남았으니 나오려면 시간 좀 걸리겠네요.


https://play.lighthouseapp.com/projects/82401/milestones/137248-21


저작자 표시 비영리 변경 금지



애자일 개발을 다양한 분야에 도입하고 있다는것은 여러번 이야기했습니다. 그런데 오늘 F1 레이싱에 도입된 사례를 정리한 기사가 있어서 소개합니다.


더 빠른 F1 레이싱 위해 애자일 개발 방법 도입한 '로터스 자동차'


기사 마지막에 나오는 멘트가 와 닿네요. "만약 IT가 엔지니어들의 수작업을 줄여준다면, 엔지니어들은 F1 차량과 드라이버에만 집중할 수 있게 된다." 본연의 업무에 몰입할수 있게 해주는것이 바로 IT가 해야하는 역할이 아닐까요. 그 역할을 잘하게 해주는것이 애자일 개발입니다.



저작자 표시 비영리 변경 금지