티스토리 툴바


Daily Stand-up Meeting

IT 이야기 2011/08/09 12:07 Posted by 아름프로
모프로젝트에서 아침마다 진행되는 Daily Stand-up Meeting을 참관할수 있어 지켜보았다.
의지가 강력한 PM(스크럼마스터)과 열정으로 진행하는 멘토에게서 긍정의 힘을 얻을 수 있었으나,
참여하고 있는 참여자의 모습에서는 ... 참 다양한 모습을 볼 수 있었다.
그리고, 시간이 좀 흘러 회고가 진행되었는데 그 내용 중에는 이 미팅에 대한 참 다양한 의견들이 쏳아져 나오는 것을 볼 수 있었다. 내용은 정리하면 간단하다. "좋다", "나쁘다" 쏼라쏼라 ... 한마디로 "혼란/혼돈" 이였다.

다른 Agile의 Practices들을 설명하는데 있어서는 참 많은 시간을 할애들 하지만,
이 Daily Stand-up Meeting에 대해서는 설명이 많이 부족하다는 것을 현장에서 느끼곤한다.
이는 나 역시도 설명하는데 있어 Daily Stand-up Meeting을 너무도 쉬운양 가볍게 설명하고 넘어가곤 했던거 같다. 왜 하는지에 대한 팀원들의 공감대가 형성되지 않은 상태에서의 맹목적인 진행은 위와 같은 결과만을 낳게 될 수도 있는 만큼, 시간을 좀 더 할애해서라도 이에 대한 공감대와 지식은 보다 많이 공유하는 노력들이 필요할 것 같다.

중요한 것은 Daily Stand-up Meeting이 어떤 것이고, 어떻게 하는가도 중요하지만,
이를 왜 하는지(목적, 목표)와 이를 실천함으로써 팀과 개인에게는 어떤 장점들이 있을 수 있다는 것을 스스로가 느낄 수 있게 해주는 것이 더 중요한 사항이 아닐까 한다. 특히, 작은 단위의 팀일 경우엔 단 한명의 부정적인 사람이 존재하는 한 Daily Stand-up Meeting은 산으로도 갈 수도 있다는 것을 명심할 필요가 있다.
(이러한 경우, 이 한명에 대해서는 어떻게 해야할까? ^^ )

Daily Stand-up Meeting을 진행하려는 곳에서는 다음의 내용을 숙지하면 보다 도움이 될 것 같다.


'IT 이야기' 카테고리의 다른 글

Agile Korea 2011 Conference 발표 신청 모집중 ...  (6) 2011/10/06
Daily Stand-up Meeting  (3) 2011/08/09
JSON 관련 정보  (1) 2011/04/06
개발팀 힘을 내주세요. ~  (4) 2010/03/29

댓글을 달아 주세요

  1. tiffany jewelry Outlet 2012/01/13 14:47  댓글주소  수정/삭제  댓글쓰기

    I must say that overall I'm incredibly taken with this website. It is apparent that you know you subject matter and you are passionate about it. I wish I had got your ability to write. I have bookmarked your internet site and look forward to more updates. http://www.discounttiffanyshop.com/
    http://www.discounttiffanyshop.com/tiffany-necklaces/
    http://www.discounttiffanyshop.com/tiffany-rings/
    http://www.discounttiffanyshop.com/tiffany-bracelets/

  2. replica watches 2012/01/13 14:48  댓글주소  수정/삭제  댓글쓰기

    Oh ,my friends!Now you can buy different Replica Watches for each day of the week. Don't worry about the building of the replica watches sale. In order to get the discount wathces you could buy watches on line.The price might be lower.Our web site will give you quality service and lower price than others! You can visit to http://www.cheapwatchmarket.com
    http://www.cheapwatchmarket.com/mens-replica-watches-2.html
    http://www.cheapwatchmarket.com/swiss-collection-watches.html http://www.cheapwatchmarket.com/ladies-watches.html

  3. Lachelle 2012/02/10 20:23  댓글주소  수정/삭제  댓글쓰기

    내가 사랑하는 내가 사랑 이 스타일 글을 . 가 간주 . 공개

Kanban vs Scrum

IT 이야기 2009/06/02 00:35 Posted by 아름프로
사용자 삽입 이미지
이 책의 저자인 헨릭 크리니버그의 블로그에 가보니 요즘 고민하고 있는 좋은 내용이 있어서 퍼봅니다. scrum-ban 이라고도 불리는 Kanban과 Scrum과의 비교를 잘 정리해 놓은 자료입니다. (첨부파일 참고)

바로가기 : http://blog.crisp.se/henrikkniberg

내용에 대한 것을 다음에 정리할께요. ^^

'IT 이야기' 카테고리의 다른 글

Rational 제품에서 Android SDK 사용하기  (4) 2009/06/05
Kanban vs Scrum  (5) 2009/06/02
컨설턴트? 전문가? ... 맞나요?  (0) 2009/04/25
안녕, 썬(SUN) ...  (0) 2009/04/21

댓글을 달아 주세요

  1. 몽둥발이 2009/06/02 17:26  댓글주소  수정/삭제  댓글쓰기

    제가 email 주소를 몰라 여기에 적었습니다.

    출처 : http://www.regonline.com/builder/site/Default.aspx?eventid=710865

    Agenda

    * Overview of Scrum
    o Why Scrum works and what it is
    * Sprints
    o Potentially shippable
    o Architecture on a Scrum project
    o Correct use of Release sprints
    * The ScrumMaster
    o Responsibilities and mindset
    o ScrumMaster as team member
    * The product owner
    o Description and responsibilities
    * Product backlog
    o User stories on the product backlog
    o Backlog-writing workshops
    o INVEST in your backlog
    * Sprint planning
    o Prioritization and the sprint goal
    o Sprint planning meeting
    * Release planning
    o Estimating the product backlog
    o Release planning meeting
    * Project planning with a publisher
    o Preproduction vs. production
    o Scrum and milestones
    o Choosing the right product owner
    o Working early with marketing groups
    * Meetings
    o The daily scrum
    o Sprint review and retrospective
    * Tracking progress
    o Burndown charts and task boards
    * The team
    o Composition and cross-functionality
    o Organizing
    * Scalability
    o The scrum of scrums
    o Focus of initial sprints
    o Shared vs. specific product backlogs
    o Scaling the product owner
    * Introducing Scrum to your organization

  2. 권남 2009/06/02 21:10  댓글주소  수정/삭제  댓글쓰기

    옹?? 어느새 블로깅을?? IBM에서 저한테 세미나 같은거 하면 연락좀 주세요.
    가까워서 세미나도 볼겸, 과장님도 뵈러 가보고 싶은데, 바삐 지내다 보면 어느새 모르고 지나쳐 있고 그러네요.. ^^

  3. comment perdre sans regime 2012/01/20 09:55  댓글주소  수정/삭제  댓글쓰기

    웹사이트 .처럼 우리는 이것이 정말 내 중 하나입니다 사실은 재미 에 읽기 !

Agile 더 이상에 비주류가 아닌 주류

IT 이야기 2009/04/06 19:28 Posted by 아름프로
Agile을 언급하는데 있어서 많은 조직에서 아직 비주류의 무엇인 것 처럼,
취급 및 인식을 많이 합니다.

저부터도 회사 내에서 애자일 이야기를 꺼내기 참으로 힘들었습니다.
하지만, 이젠 좀 더 당당(!)할 수 있을 것 같습니다.

IBM 내부적으로 최종 정리에서도 보시다시피, 소프트웨어 개발의 단계의 최상위 단에서
특정 방법론과도 연계되지 않는 개발의 최선의 Practice들을 Agile Business 라는 것으로 표현하고 있습니다.

이는 IBM의 내부의 10여년의 개발 경험과 최근의 80여개의 개발 프로젝트에서의 최선의 결과를 도출하여
Practice로 도출한 내용이기도 합니다. (아래 내용을 일부 간단히 정리한 내용)
또한, 이 검토한 대부분의 프로젝트이 Agile 프로젝트였던 만큼, 소프트웨어 개발 측면에서는 Agile을 더이상에 비주류라
칭할 수는 없을 것입니다.

어쨌든, 개발을 제대로 하기 위한 각각의 실천 내용을 Practice로 정리했고,
그것을 기반으로 IBM도 변화하고 진행하고 있답니다.
사용자 삽입 이미지

댓글을 달아 주세요

결론부터 말씀드리면, Iteration에 대한 이야기 입니다.

요즘 그 어느때보다 많은 사람들을 만나며 방법론에 대한 이야기를 나누고 있습니다.
무엇보다 새로이 담당하고 있는 Rational Team Concert(RTC)가 방법론(프로세스) 템플릿을 내장하고
이를 기반으로 프로젝트가 시작되기에 빼놓고 이야기할 수 있는 상황이 아니기도 하고요.

RTC는 기본으로 Scrum, OpenUP, eclipse Way, Agile(Simple)와 같은 Agile 방법론들을 기본으로 제공하고 있기에 해당 방법론을 선택해서 프로젝트를 생성하게 되면, 각각의 방법론에 맞는 Iteration 기반으로 템플릿이 생성됩니다. (Sprint, milestone, 등등과 같은 ... 자세한 것은 생략)

그런데, 이러한 내용을 본 사람들의 반응은 참으로 다양합니다.
대표적인 두가지 사례를 들자면 아래와 같습니다.

첫번째 유형, 'Iteration = 애자일' 과 같이 해석하는 분들.
반복적 개발을 한다는 것이 애자일 개발을 대표하고 대변하는 것처럼 인식하고 있는 분들이 생각보다 많습니다.
그냥, 이러한 내용만보고 '애자일은 우리에게 .. 글쎄요? ...' 라는 식으로 바로 해석해 버립니다.
추후에 다시 언급하겠지만, Iteration은 애자일방법론에서만 등장한 것이 아님에도...

두번째 유형, '반복적 개발'을 실무에 적용하기에는 리스크가 크지 않을까요? 라고 정의하시는 분들.
나름 애자일쪽에 대해서 공부를 좀 하셨거나 관심이 있으신 분들 중에서 오히려 이러한 말씀들을 많이 하십니다.
이유를 들어보면, 그 내용에는 반복주기 동안 새로운 요구사항을 받아들일 수 있는 것 아니냐?! 요구사항에 대해서 개발 중간에 계속해서 리뷰하는 것이 꼭 좋은 것만은 아니다.. 라는 의견을 내비치곤 합니다.

특징적인 것은, 이러한 이야기를 하신 분들을 상대로 이러저런 애자일의 정점과 내용을 가지고 설명을 해봐도 잘 받아들이지 않는 다는 공통점도 발견할 수가 있습니다.

재밌는 사실 중에 한가지는 이러한 분들에게 현재는 어떤 방법론을 사용하고 계신지 여쭤보면 다수 분들의 답변은 CBD나 자신들의 자체 방법론을 쓴다라고 답변을 합니다. 궁금증에, 자체 방법론에 대해서 좀 더 깊이 이야기 나누고 질문을 하면 먼저 묻기도 전에 "폭포수는 아니고요..." 를 강조하기도 하고요.

그런데, 이미 글에서 눈치채신 분들은 아시다시피 CBD의 대표적인 방법론인 RUP이나 마르미3(2.0)과 같은 경우 Iteration을 강조하는 방법론이라면 방법론으로 진화가(!) 된 상태(!)입니다. 물론, 주기와 실천적인 측면에서 애자일쪽과는 다소 차이가 있더라도 그 근간은 비슷하다고 봐도 무방할 겁니다.
폭포수가 아닌 방법론... 이 역시도 폭포수와 아닌 방법론을 구분 짓는 대표적인 기준 중에 하나가 Iteration임은 잘들 아실 겁니다. (방법론적인 설명은 모두 생략 ... )

... 막연한 애자일에 대한 거부감 ...
... 폭포수가 아님을 자신하면서도 ...
... 결국엔, 자신들의 방법론의 실체나 내용조차 제대로 모르는 분들이 너무도 많은 ...
것이 현 많은 분들이 사용하는 개발 방법론의 실체가 아닐까 하는 생각마져 듭니다.

어쨌든,
이러한 질문과 이러한 생각을 가지고 계신 분들이 그렇지 않은 분들보다 훨~씬 많다는 것이 제가 요즘에 많은 분들 만나본 후의 결과라는 점입니다.

IT의 진화와 기술들의 발전을 자부하고 있는 대~한민국이지만, 그 내면을 들여다보면 방법론적인 진화는 생각보다 크지 않음을 많이 접하게 됩니다.

잘 들여다보면 전혀 다른 방법론인 것 처럼 알고 있는 것들도 그 내면은 어느덧 닮아 있고, 서로간의 장점을 가지고 진화되어 현재에 이르고 있음에도 그러한 내용은 제대로 이해하지 못한 채, 과거의 익숙하고 산출물에 종속된 방법들에 종속되어 그냥그냥 그렇게 계속해서 흘러만 하고 있는 듯 싶습니다.

.... 끝으로, 스스로에 질문을 한번 해보았으면 합니다.

1. 지금 사용하는 방법론이 무엇인가요??
2. 폭포수 방법론? 이에 대해서 거부감을 가지고 계시다면 왜 그러신가요?
3. Iteration(반복개발 / 반복계획)은 하고 계신가요?

2번, 3번 질문에서 무한루프를 돌고 계신 분이시라면 변화에 귀를 좀 더 귀울여 보시는 것도 좋을 것 같습니다.

댓글을 달아 주세요




The Enterprise and Scrum by Ken Scwhaber. There is a sufficient presentation of Scrum along with how it can be used in larger organizations.

The Enterprise and Scrum at Amazon.com



Agile Estimating and Planning by Mike Cohn. An indispensable guide to better planning. Even if you are not specifically trying to be Agile, there are good ideas in here for just being more sensible.

Agile Estimating and Planning at Amazon.com


Implementing Lean Software Development: From Concept to Cash by Mary and Tom Poppendieck. Huge impact from a small book. Dense with ideas and understanding about why Agile works and makes sense. One of my faves. I own the other one too, but if you only read one, this is it.

Implementing Lean Software Development at Amazon.com



Scaling Software Agility: Best Practices for Large Enterprises by Dean Leffingwell. Very good presentation of Agile and how to bring it to large organizations.

Scaling Software Agility at Amazon.com



xUnit Test Patterns: Refactoring Test Code by Gerard Meszaros. What?! A test book? Agile isn't going to work if you don't have your test act together, period. Martin Fowler changed the terminology in some of the articles on his web site to adapt Gerard's. Need I say more? This book is big and there is a lot in there and it will take your testing understanding to the next level.

xUnit Test Patterns at Amazon.com

TAG Agile, 서적

댓글을 달아 주세요

  1. art essays 2012/01/16 16:56  댓글주소  수정/삭제  댓글쓰기

    그것은 당신이 거의 관심이없는 무언가를 배울 재미되지 않습니다. 내 스승에게서 뭔가를 배우고 싶어 내 마음에 그것을 가지고있어 그래서 내 경우에는, 나는 IBM에서 작동합니다.

애자일 이야기 ...

IT 이야기 2008/06/20 13:33 Posted by 아름프로
최근에 여러 블로그나 토론 게시판에 애자일에 대한 이야기로 후끈하네요.
뭐 발단이야 SI에 적용가능한가라는 조금은 타겟이 있는 내용이기는 하지만,
어쨌든.. 그로 불어진 이야기의 내용에서는 애자일이 현실에 어떻게 인식되고 있고 어떻게들
생각하는지를 조금을 알 수 있는 내용들이 아닌가 싶습니다.

저도 90년대말 켄트백 가라사대~ 를 시작으로 xp부터 발담그기 시작했던 기억을 더듬으면
어느덧 시간이 참 많이 흘렀음을 새삼 느끼게 됩니다.

IT에서 7~8년이란 시간은 짧지 않음에도 국내의 애자일에 대한 인식과 전용은 북미와 유럽에서의 선전에도
불구하고 한참을 더디게 진행되는 것 같습니다.

저도 한때 조직에 적용시켜보고자 했다가, 새로운 것 좋아하는 놈(!), 생각이 특이한 놈(!)이란
취급까지 받았던 기억을 더듬어보면 .. 사람들이 이를 적용시켜보고자 시도하는 것 자체에 어떠한
어려움들과 고민들이 있는 충분히 공감은 하는 부분입니다.

하지만, 제가 조직과 사람들에 적용해보려 했던 시기와 방법과는 달리 지금에는 많은 것이 바뀌어 있습니다.
물론, 저의 접근 방식과 지식, 생각 모든 것이 부족했던 것도 사실이지만요.

어쨌든, 오늘은 현 시점에서의 변화된 내용 몇가지를 적어보며 ..
이런저런 이야기를 해볼까 합니다.

  1. 최소한 ... 애자일? 그게 뭔데? 라는 시대/시기는 아닙니다.

    실천적 측면에서의 가능성에 대한 의문과 고민이 있을 따름이지 예전처럼 무지에 따른 왕따(!)를 받을 상황은 아니라는 것입니다.
    쉽게 생각하면 가능성과 지표만 마련된다면 변화에 대해 좀 더 쉽게 접근도 가능하지 않을까 싶습니다.
    단, 그 변화의 주체가되고 책임을 져야할지 모른다는 두려움은 있을 겁니다.

  2. 많은 자료와 지식들

    마음만 먹고 공부하려 한다면 할 것들이 너무도 많이 있습니다. 인터넷의 떠도는 지식은 물론이거니와 수 많은 책들.
    한글화 된 책도 많으며, 영문책은 1년 계획해야 다 볼 수 있을 정도입니다.
    중요한 것은 ... 이 많은 책들과 지식이 있음에도 일부 사람들은 보기 쉬운 자료들만을 가지고 애자일에 대해 정의하고
    단정을 지으려 하고 있습니다. 애자일을 공부하려는 사람이라면 그 내용보다는 우선은 자신을 변화하려는 마음부터가
    필요함을 아직들 잘 모르는 것이 아닌가 싶습니다. 나의 마음을 열고 다른 사람과의 교류와 협력에 더 힘을 써야하는 것이
    가장 중요한 내용임에도 모아니면 도식으로 옮고 그름을 결론부터 지우려 하는 것을 보면 안따깝기도 합니다.
    어쨌든, 계속 수양할 수 있는 무엇인가가 많다는 것은 좋은 상황입니다.

  3. XP와 Scrum이 다가 아니다.

    애자일 선언문(Agile Manifesto)의 발표의 촉발에는 XP와 Scrum이 있었습니다. (그외에 몇가지가 더 있지만..)
    그렇게 시작된 변화의 물결과 흐름속에 애자일 자체도 많은 변화와 개혁을 해가고 있습니다.
    하지만, 우리나라의 애자일을 언급하는 사람들을 보면, 아직 이 틀에서 벗어나지 않은채 여기에서 진리만을 찾으려하는
    것 같습니다.

    변화를 중시여기고 그 변화를 빠르게 대처하자는 Agility를 강조하면서도 몇년여가 흐른 지금에도 선언문의 내용을 1:1
    매칭하며 저울질 하는 노력들을 하는 것을 볼 때면 여러가지 생각들이 교차되곤 합니다.

    애자일을 자로 잰듯 그리고 그 진리가 다 있는 것처럼 생각과 오해를 하지 않았으면 합니다.

    현실에서는 RUP에 기반(변형)된 실제 프로젝트들이 많이 진행되고 있는 반면...
    제대로 된 개발을 하기 위해서는 애자일 방법론을 적용하는 것이 좋다고 이야기하는...
    혼돈의 시대이면서 새롭게 정리해가고 있는 시점이 지금이 아닐까 싶습니다.

    Agilest 분들 중에는 애자일의 큰 특징으로 반복 개발을 이야기하지만, 사실 이는 RUP의 핵심 플랙티스임에도
    RUP과 비교를 통해 우월성을 이야기하는 모습에서는 안타까운 생각이 들기도 합니다.

    XP, Scrum, RUP 이것이 다일까?? 둘의 장점을 만들려는 노력은 없었을까?
    물론, 있었음에도 국내에서는 아직 이에 대한 관심들은 별로 없는 것 같습니다.



    이러한 것을 보면, 
    RUP을 무시하는 애자일을 이야기하는 사람들조차도 편향적이면서 자기들의 틀속에 갖혀 있는건 아닌가
    하는 생각을 해보게 됩니다.

    아래 참고할 만한 몇개 사이트 링크를 남겨봅니다.


    좀 더 넓은 시각과 마음에서 내용을 들여다보는 노력도 게을리하면 안될 것 같습니다.

  4. 레퍼런스

    좋다고 이야기하고 많이 적용했다고는 하지만, 그 내용을 찾아보기 참 힘든 것 같습니다.
    하지만, 등잔 밑이 어둡다고... 가까운 곳에 좋은 레퍼런스가 있음을 잊고 지내는 것 같습니다.

    • Eclipse

      Eclipse는 The Eclipse Way 라는 애자일 방법론을 적용하여 한단계 업그레이드(!)시킨 방법론을
      기반으로 만들어지고 있습니다. 이는 위에서 잠시 말씀드렸던 애자일에는 XP, Scrum만이 있는 것이
      아닌 예이기도 하면서 애자일을 현장에 어떻게 적용하고 있는지에 대한 대표적인 예가 아닐까 합니다.

      무엇보다 애자일하면 작은 규모만을 이야기하지만, Eclipse 은 그 규모와 피드백의 양으로 7주 Interation 주기를
      돌아야할 만큼에 규모가 큰 프로젝트입니다.
      Eclipse를 사용하는데만 관심을 가졌지만, 어떻게 만들어지는지에도 관심을 가지면 더 많은 것을 배울 수 있음을
      우리는 모르고 있었던 내용입니다.

      참고1 , 참고2

    • Jazz/RTC

      애자일 개발 환경에서 어떻게 팀이 구성되고, 커뮤니케이션을 어떻게하며 interation Plan은 어떻게 짜여지며,
      Work item들은 실제 어떻게 사용되고 있는지 등의 실제 프로젝트의 내용을 보고 싶으시다면,
      jazz.net 의 development 메뉴 (로그인 필요)를 살펴보시기 바랍니다.
      애자일은 현실과 거리가 멀다??? 고 외치시는 분들은 이곳에서의 진행들이 한낮 이론과 추상화 된 내용만으로
      되어 진 것이 아님을 보실 수 있을 겁니다.
      공부하시는 분들은 실제 어떻게 팀을 꾸려나가고 계획을 가져가야할지에 대한 많은 도움이 될 것 같습니다.

  5. 열정적인 이들

    마음만 먹고 스터디를 진행하려 한다면, 함께 해줄 많은 이들이 현재는 아주 많다는 점입니다.
    외롭고 쓸쓸하니 나만의 생각과 공간에서 진행하지 않을 수 있다는 것.
    이것이 얼마나 큰 행복인지 알았으면 합니다.

애자일을 적용하는 것.

"이미 내가 하고 있는 것이 애자일이였네" 라고 많이들 이야기하듯이. 이미 하고 있을 수도 있습니다.
많은 분들이 애자일 선언 / 애자인 소프트웨어 개발(애자일 개발) / 애자일 방법론 을 헛갈려하면서 진실을 찾으려 하는 것 같습니다.

저 역시도 이속에서 아직 헤매고 있는 중이지만,
애자일이라는 것은 선언/실천적 개발/방법론 을 통칭하여 좀 더 좋은 것을 빠르게 만들어나가려는 실천적 의미에서
그 답을 찾으려 하고 있습니다.

어쨌든, ...
그러한 측면에서 Jazz/RTC의 만남은 저에게는 큰 의미가 되고 있습니다.
한때 아픈 기억속에서 현실화 시키기 힘들었던 내용들을 해결할 수 있는 실마리와 방법들을 제시해주고 있기 때문입니다.

이는 ...
고민하는 것들이 실제 어떻게 적용될 수 있는지에 대한 내용을 담고 있다는 점에서 큰 의미도 있지만,
IT를 리딩하는 IBM가 개발 Lifecycle의 핵심의 Rational의 플랫폼에 Agile을 핵심으로 구성하고 있다는 점은
, MS도 VSTS에 더 많은 부분 투자를 하는 상황이고, 나혼자의 취향과 관심사가 아닌 IT 흐름과도 같이 할 수 있다는
자심감 마져도 부여해주기 때문입니다.

한때 남들이 그렇게 이야기하기에 ...
내 자신이 정말 튀는 것은 아닌가하는 고민도 했었지만,
이제는 당당히 말할 수 있을 것 같습니다.

"프로젝트에 애자일 방법론을 한번 도입해 보시죠" .... 라고 ...
"Jazz/RTC .. 같이 공부해보시지 않을래요?" ... 라고 ...

댓글을 달아 주세요