MoinMoin   스크럼 UserPreferences
 
Help Info Print View Search Diffs Edit
 인덱스   도움말   찾기   대문   바뀐글 
  1. 목적
  2. 스크럼
  3. 관련 서적
  4. 관련 사이트
Since 2010. 1. 12.

목적

스크럼

4월에 사내 스크럼 교육을 맡았다.
지금의 강의 자료에 내가 바스로부터 받은 내용을 추가해야겠다.
스크럼마스터 트레이너인 바스로부터 교육을 받고 스크럼 교육을 진행해야겠다.

Agile 방법론으로 XP와 스크럼이 있다.
스크럼은 XP에 비해 대기업에 적용하는 경우 발생하는 문제들을 해결하기 위해서 여러가지 역할을 뒀다는 생각이 든다.
대기업의 경우 '이건 누구 책임이고 저건 누가 할 일이야'라는 것으로 논쟁이 많다. 이를 명확히 하기 위해서 스크럼마스터를 두고 프로젝트 오너를 두는거 같다.
이에 비해 XP에서는 이런 역할을 명시적 누가 지속적으로 맡아야 한다는 것을 정하지 않았다. 자유도가 높다.

중도 자기 머리는 자기가 못 깍는다.
스크럼마스터가 팀의 문제를 끌어내어 해결할 수 있도록 돕는 것도 중요하지만 팀이 지속하면 도움되는 활동을 중단하지 않게 해주는 역할이 가장 중요하며 핵심적인 일이다.
스스로 정해진 시간마다 정해진 일을 하는 습관을 가지는 것은 쉽지 않다. 아침마다 10분씩 스탠드업 미팅을 하는 것도 그렇고 포스트잍을 붙이는 행동도 그렇고 조각조각으로 보면 쉽고 간단한 일이지만 규칙적으로 지켜나간다는 것은 쉬운 일이 아닌거 같다.
따라서 스크럼마스터에게도 스크럼마스터가 필요한 것이다.

좋은 스크럼마스터의 자격은 뭘까?
회사나 다른 회사들의 상황을 보면 역시 스크럼마스터는 아무나 되는 것이 아닌거 같다.
물론 스크럼의 Done에 대한 개념에 따라 달라질 수 있겠다. 내가 스스로 생각하는 스크럼이나 XP로 돌아가는 개발조직을 곰곰히 생각해 보면 스크럼마스터는 아주 뛰어난(?) 사람이여야 한다.
단순히 아침 스탠드업 미팅을 주관하거나 회의를 주관하는 역할만으로는 내가 생각하는 XP적인 조직과는 상당한 수준차이가 있다. 개발을 처음 시작할때는 아침에 스탠드업만 해도 훌륭한 조직이야'라는 생각을 했지만 지금은 아래와 같은 XP Practice들이 지켜져야만 스크럼이나 XP를 하는 조직이라는 느낌이 든다.
Pair Programming
Test-Driven Development
Automated Acceptance Testing
Continuous Integration
Simple Design
Refactoring
… and more

어제 [WWW]Ron Jeffries의 글을 읽고 '그래 이런 것들이 없이는 개발회사에서 개발자나 경영자에게 가치를 주는데 한계가 있겠다'는 생각이 들더라.

대부분 시작하는 팀에 스크럼마스터가 투입되는 경우 XP Practice들에 대해서도 경험이 있어야하고 사전 지식과 환경설정, 개발언어에 대한 지식등이 없이는 초기에 제안하거나 일을 매끄럽게 굴러가게 하는 것을 어려워하더라. 내 경험으로는 자기가 해당 분야에 대한 지식이 낮다고 생각하는 경우 가장 중요한 자신감이나 자존감이 떨어지게 되고 그러니 일 시작 자체가 어려워 하더라.

    ex) 며칠전 회사에서 staff부서에서 꽤 오래 일하시다가 이번에 스크럼마스터를 자처하고 일을 시작해 보려는 분을 만났다. '개발자들 찾아가서 스크럼하자고 했는데 시간 없다고 안하려고 하더라. 그래서 시작 자체도 못하고 있다. 아마 다음달에는 경영층에서 확산 명령이 직접적으로 내려오면 그때 시작해야겠다. 아침에 스탠드업 미팅하고 종이에 할일 붙이는 것만하면 되는데... 아주 간단한데 개발자들이 바쁘다고 거부하더라.'

스크럼마스터는 슈퍼맨이여야 한다는 결론을 내렸다. 새로운 것에 오프마인드여야하고 매일매일 공부하여 자신을 발전시켜야 하고 사람 사이의 관계도 원만해야하며, 등등등....
내일부터 바스 보드로부터 교육을 받는다.
기간 : 2010. 4. 13 ~ 14

팀이 해결해야 한다.
사람들 사이의 감정을 조절하는 것이 우선이다.

  1. 소개
    • 교육자
    • 바스 소개
  2. 스크럼 간략소개
  3. 오늘 교육에서 얻고자 하는 바
  4. 번역 이야기
  5. 폭포수 모델
  6. Agile 선언
  7. XP
  8. 실습 - 자가관리
  9. Scrum
[WWW]New New Product Development Game

아침에 일찍 출근해서 스크럼마스터의 최종 관문인 스크럼마스터 온라인 테스트를 진행했다.
용어에 대한 질문과 역할 및 practice들에 대해서 물어봤다.
10분 남짓 걸려서 문제를 다 풀고 스크럼마스터 인증서를 획득했다.

인증서란게 받기 전에는 아무것도 아닌거 같은데 그래도 있으니까 뭔가 한거 같은 느낌을 주긴한다.
http://www.scrumalliance.org/login

  1. 팀in or 팀out
      팀원에 깊숙하게 붙어서 일하는 경우 스크럼마스터로서 객관성이나 방향을 알리는 역할을 제대로 못할 수도 있더라. 특정 부분에서 technical coach로 역할을 선언하고 그 일을 해보는 방법도 있다.
  2. 칸반
      업무량 추정이 어렵다고 해서 칸반을 택했는데 이것이 오히려 전체 일의 양이 얼마나 남았는지 모르게 하더라. tip : 모를 때는 모든 일을 동일하게 놓고 상대적인 양으로 추정해 본다.
  3. 감정
      일이 잘 안풀린다고 생각할 때 정신적으로 압박을 받을 수 있음.
  4. 우린 애자일 방법을 배우는 중이다.
      기존 방법과 섞어서 하는 경우 이것도 아니고 저것도 아닐 수 있다. 최대한 한가지 방법으로 배우는 마음으로 진행해 보는 것이 좋겠다.
  5. PO의 Product Backlog
      PO가 Product Backlog를 잘 작성하고 정리하도록 해야한다. 최대한 Product Backlog는 동작 기능 위주로 확인이 가능한 명세로 한다. PO는 세부적인 기능에 대해서 숙지하고 있어야 한다. <- 이점이 가장 어려운 점이라고 함. 눈물 쏙 빼는 경험을 할지도 모름.
  6. 업무는 기능 단위로 명세한다.
      업무를 layer로 나누지 않는다. 업무는 기능 단위로 지정해야 완성된 모습을 매일매일 볼 수 있다.
  7. 익숙해지기 위한 시간은?
      약 6개월 정도의 기간 동안의 경험이 필요함. 첫번째 스프린트에서 만족으로 인해 많은 부분이 이미 자리 잡았다는 착각을 했다. 많은 사람들이 한 팀처럼 움직이기 위해서는 어느 정도의 시간이 걸릴꺼다.
  8. Product Backlog Item의 ownership
      PB Item이 잘 굴러가도록 Ownership을 가질 사람을 선정하는게 좋다. 그렇지 않으면 일이 완성되기가 어렵다. 지금와서 생각해 보면 지난 번에는 노s이 그 역할을 해주어서 잘 진행되었던거 같다. 이번 스프린트에서는 그 역할을 자발적으로 선택하는 사람이 없었다.
  9. 환경구축
      하나의 기능을 full로 확인하는 방식이 아니라 layer작업을 먼저하다보니 정작 해당 모델을 빌드하고 확인하는 환경구축 작업이 뒤로 밀리고 중반이 넘어서야 그 사실을 인지하였다. 시간이 촉박하여 해당 작업을 선택하는 사람이 즐겁워하지 않더라.
  10. 문제 혹은 어려움에 봉착해야 실제 팀이 가지고 있는 취약점이 나타난다.
      잘 돌아가는 경우에는 어떤 것이 부족한지 나타나지 않고 찾기도 힘들다. 위기 상황이 되면 당황하게 되고 일이 잘 풀리지 않는 악순환의 고리가 생기더라. 위기는 어떤 팀이든지 겪는다. 그때 회고에서 어떻게 했으면 더 좋았을지 의견을 나누고 재발하지 않게 하는 것이 더 중요하겠다.
  11. 스크럼마스터의 성장
      일은 결국 구성원들의 상호작용을 통해 완성된다. 구성원들의 상호작용 및 행동패턴을 잘 관찰한다. 스크럼마스터도 회고를 통해 성장한다. 동일한 상황에서 어떻게 대처했는지 그때 어떤 반응이었으며 어떻게 했으면 더 나았을까를 고민해야 한다.
  12. 번다운 차트
      칸반으로 간다고 번다운차트를 생략했다. 그래도 잘 굴러가리라 생각했다. 하지만 1번의 스프린트를 마친 팀이 몸이 익어서 하기에는 어려운 것이었다. 번다운 차트는 있는게 좋겠다. 항상 우리가 하는 일의 지도를 명시하지 않고 일했지만 지난 주랑 비교해서 앞이 안보이는 것과 같은 느낌을 받았다.
  13. 교육
      목표가 확실하지 않으면 필요한 교육을 스스로 알아내기가 어렵다. 팀원들에게 필요한 교육이 뭐가 있느냐 혹은 어떤 교육을 받고 싶냐라고 묻는 경우 답을 얻기가 힘들 수 있다고 생각된다. 이런 경우에는 스크럼마스터가 필요한 교육을 제안하는 것도 필요할 듯 하다. 개발이 개인적이고 독립적인 형태로 진행된다면 서로 자신의 실력이나 필요한 스킬을 알기가 어렵다. 필요한 교육을 알아내기 위해서라도 쌍으로 작업하여 문제를 해결하게 하며 상호간의 스킬을 향상시킬 수 있게 하는 것이 필요하겠다.
  14. 저는 이런 식의 일하는 방식이 불편해요.
      애자일 방식이 모든 사람에게 잘 맞지는 않다. 계획이 세워지지 않은 것처럼 일하는 방식으로 느껴지는 경우 일을 하면서도 갑갑할 수 있다. 독자적으로 분리된 일을 할당해 주는 것도 좋겠다. 계획이 불명확한 상태였을 수도 있다. 따라서 계획을 어떻게 하는지도 고민해 봐야겠다.
  15. 꼭 짝으로 일해야 애자일인가?
      두명이 하나의 일을 선택하여 진행하도록 하였다. 두명이 붙어서 하면 잘 협의해서 일을 하리라고 생각했다. 하지만 이것 역시 착각이다. 다시 그 일을 2개로 나눠서 독립적으로 처리한다면 두명이서 나눠서 하는 것이 도움이 안된다. 두명을 붙여주고 페어프로그래밍을 하라고 한다고 해서 페어프로그래밍이 안되는 것과 같다. 결국 시간을 갖고 꾸준히 익혀야 한다.

시간이 부족하고 일이 제대로 풀리지 않을 때 회피하고 싶어진다. 우리가 앞으로 일을 순조롭게 처리해 나가는데 필요한 것들에는 뭐가 있는지를 곰곰히 생각해 보자. 부충해야할 일들은 뭐가 있을까?

심리적 안정과 서로서로 격려해 주는 분위기 조성이 필요하다.

  • 다음주에는 원칙 지키기 :
    1. Product Backlog 작성(PO)
    2. 시간표시 plan하기
    3. unplaned work에 대해서 기입하기
        -> 실제 unplaned 작성

  • 순서 (Review)
    1. 데모 (우리가 하기로 한 일)
      1. PO가 원했던 일인가?
      2. 요구사항을 만족했는가?
    2. 일을 한 방식에 대한 회고
      1. 이번 스프린터 동안에 일했던 방식에서 개선할 점은
      2. Good/Bad
          -> 어떤 점이 개선되면 지금보다는 나아질까?
    3. Action Item 1개 선정

계획에 필요한 것들 :
  1. PB(PO가 우선순위를 미리 정해 놓을 것)
  2. 팀원의 이번 스프린트시 가용 시간
  3. PB에 대해 소요시간 예측
  4. 이번 스프린트에서 달성할 PB 선택 및 성실히 이행하겠다는 약속

대부분 팀구성원은 이렇게 되더라.
  • 기술적으로 뛰어난 사람 : 10 ~ 20%
  • 보통 ; 70%
  • 이하(개발에 별관심 없음) : 10 ~ 20%
왜 이런 모양을 가질까? 여러가지로 생각해 본 결과..

이런 모양의 구성이 전체적인 팀의 평균역량을 떨어뜨리는 것은 아닐지..

관리자가 관리하는 여러 팀중에서 한 팀이 일을 더디게 하는 경우 다른 팀의 에이스를 투입시키고 그 에이스는 보통 그 팀에 눌러 앉게 되는 경우가 많다.
이렇게 해서 기술적으로 뛰어난 사람이 한 팀에 여러 명 있는 경우가 드문거 같다.

'제가 감당하기가 어렵네요.'
이렇게 말하는게 좋을 때가 많다.

사람을 공격하는 아래와 같은 말을 하지말자.
'저 사람은 꽉막힌 사람이군요. 저런 사람은 스크럼에 맞지 않습니다.'

특히 처음 스크럼마스터를 하는 경우 새로운 팀에 들어가게 되면 '좋은 사람'처럼 보이기를 원한다.
최대한 사람들과 갈들을 피하려고 한다. 물론 아주 의욕적인 스크럼마스터라면 반대일 수도 있겠지만...

중요한 것은 좋은 사람이 아니라 바르게 인도하는 사람이 되는 것이 중요하다.
똑같이 우선순위를 정해서 해당 팀이 감당할 수 있는 것들을 하나씩 적용해 나가는 것이 좋다.

처음 스크럼을 설명했던 팀원들에게 한자리로 모여서 일하는 것을 권유했다.
'자리도 그리 멀지 않은데.. 그냥 그대로 하죠'
좀 강하게 나갔다.
'자리 배치 안바꾸면 스크럼마스터 하고 싶지 않습니다. 함께 공유하고 일하는 것이 기본 가치인데 기본적인 환경이 갖춰지지 않은 상태에서는 효과를 보기도 어렵습니다.'
'스크럼 앞으로 계속 할지 안할지도 모르는데... 몇 번 해보고 잘 되면 그때 자리 옮기도록 하면 안될까요?'
'같은 일을 하는 사람들이 최대한 함께 앉아서 일하는 것이 시너지가 난다는 것은 모두 아실껍니다. 스크럼을 하던 안하던 같이 앉아서 일하는 것은 당연합니다. 그리고 자리하나 바꿀 마인드가 아직 되어있지 않은데 어떻게 새로운 방법으로 개발을 진행할 수 있을까요? 자리 바꾼기로 결정되면 그때 연락주세요.'

오후에 개발팀에서 자리를 바꿔서 진행해 보겠다는 연락이 왔고 다음주부터 바로 planning을 진행했다.

만약
'네 그러시군요. 그러면 일단 따로 앉아서 진행해보시죠'

개발팀원들과 부드러운 관계를 맺는데 가장 좋은 도구는 세미나라고 생각한다.
최근에 나온 기술이나 리팩터링, TDD, 안드로이드를 개발하고 있다면 특정 주제에 대한 세미나를 하는 것이다.
즉 개발팀원들이 필요로 하는 정보들을 제공해주라.

스크럼마스터 교육을 받으면서 내가 Bas에게 했던 질문이 있다.
'스크럼 마스터의 기술 정도는?'
Bas는 스크럼 마스터는 tech guru일 필요는 없다고 답해줬다.

최근에 느낌은 스크럼 마스터는 tech guru일수록 좋다는 결론을 내렸다.
개발팀원들의 속성상 기술적인 이야기를 하지 않고는 교감하기가 쉽지 않다.
팀원들이 겪고 있는 기술적인 어려움에 대해서 해결해 줄 수 있다면 좋다.

기술을 가지고 있지 않다면 최소한 기술분야 학습을 무지 좋아하거나 사람에 대한 관심이 갖고 있는 사람이여야 한다.
물론 tech guru더라도 사람에 대한 관심이 없다면 스크럼마스터로서는 불합격이다.

'바보도 프로그램을 짤 수 있는 것처럼 바보도 스크럼마스터를 할 수 있다. 하지만 제대로 할 수는 없다!'

난 ENTP

스크럼계획은 꽤 시간이 많이 든다. 처음 스크럼을 할 때는 더 많은 시간이 들고 이게 뭐하는 짓인가 하는 생각이 들 수 있다. (하루 종일 할 수도 있으니까..)

처음 계획을 위한 회의를 하면 이런 느낌을 갖게 된다.

  1. 회의 진행자가 없으면 회의시간은 끝이 없고 정리도 안된다.
  2. 전체 할 일을 뽑아보는 경험이 부족하다.
  3. 실제로 구현해야 할 것보다 예외처리에 몰두하게 된다.
  4. 해야할 일들이 드러나면서 몰랐던 부분이 한꺼번에 드러나면서 '이 일을 정말 할 수 있을까? 어렵겠는데...' 이런 말이 많이 나온다.

스크럼마스터는 위의 상황에 대한 대응법을 가지고 있어야 원활하게 진행된다.

어제는 PO의 PB를 개발팀원들에게 소개하고 정리하는데 1시간 정도의 소요됐고, PB에 대해서 SB로 만드는데 1시간 정도 걸렸다.

솔직히 말하는게 좋을 때가 많다.
개발팀원과 계획하기를 하는데 열이 받기 시작했다.

스크럼을 진행하면서 나에게 음의 에너지를 뿜는 친구기도 하다. 내가 개발자의 말을 몇 번 끊었다. 그 개발자도 화나 났다.
'왜 다른 사람과 저를 대하는게 다른가요? 왜 제 말을 끊는건가요? 편견을 갖고 있는건 아닌가요?'
변경을 하기가 싫더라.
'정확히 봤어요. 생각해 보니 편견을 갖고 있네요. 그리고 말을 끊은 것도 맞아요. 내가 아직까지 모든 사람에게 똑같이 대하는게 잘 되지 않네요. 성숙한 인간이 아직 안됐나봐요. 그래서 항상 미안해요. 하지만 항상 아무개씨를 신경쓰고 있어요. 더 잘 해볼려고 하는데 오늘도 선을 넘었네요. 내가 사랑이 부족했네요.'

놀라운 변화가 일어났다 대화를 나누던 상대가
'아니예요. 제가 좀 모가 난 구석이 있어요. 그리고 이렇게 일하는게 싫지는 않아요.'
라고 말하면서 눈시울이 붉어지더라.

솔직함, 사과 그것이 답일 때가 많다.

처음 스크럼팀을 맡을 때, 나는 해당 팀의 PL에게 이 활동에 비판적인 성향은 빼고 진행했으면 좋겠다고 했다.

보통 PL과 팀원은 모두 내 말에 반대한다.
'우리는 하나다. 모두가 함께 가야한다. 일이 진행 안될 정도는 아니다. 이거 왕따시키는거 아닌가?'
이런 이유에서다.

하지만 팀으로 강하게 뭉쳐서 자주 대화하고 진행하는 현실이 되면 내가 했던 말과 같은 말을 하게 된다. 더 많은 말을 주고 받으면서 서로 상처를 주고 받게 되니까.
스크럼을 진행하기 이전까지는 이렇게 붙어서 같은 일을 해 본 적이 없기 때문에 둔감했던 부분이다.

초기 팀으로 일하기의 피로도가 상당하다. 피로도가 높은 상태에서 일의 진행마저 제대로 되지 않으면 다시는 스크럼을 보고 싶지 않을 수 있다.

팀에 스크럼마스터와 유사한 역할을 하는 사람이 있어야 잘 된다.
적극적이면서 가끔 내가 하는 말에 동의를 해주는 그럼 사람...

팀의 에너지가 떨어지는 것을 막아주는 역할을 한다. 없다면 한사람을 찍어서 나중에 빠지더라도 같은 역할을 수행할 수 있게 육성하는 것이 중요하다.

3개월이 지났다.
별다른 변화가 안보인다면 다른 팀을 찾아보라.

팀원들의 개발역량처럼 스크럼마스터도 역량치가 있다. 계속 이런 상태로 팀을 끌고 갈 것인가? 스크럼마스터도 나름 실패를 인정하기 싫어하는 속성이 있다.

내가 뭔가 놓치고 있는 것이 있거나 내가 감당할 수 없는 팀이라고 생각하라.
회고를 통해서 팀원들과 자신을 항상 돌아보자.

'처음에 스크럼마스터는 엄청 편한 일이라고 생각어요.'
어제 개발팀원과 대화를 하면서 이런 말을 하더라. 이전에 진행했던 활동에서는 거의 역할이 없어서 그냥 잠시 있다가 가는 그런 역할로 인식했단다.

'지금보니까 결국 개발도 사람들 사이의 일인데 그걸 조율하는게 엄청 스트레스 받는 일이라는 것을 알았어요. 그리고 요령이 중요하다는 것두요.'

'개발자와 함께 이야기하려면 기술적인 배경지식이 없으면 일단 끼기가 힘들죠. 특히 개발자간에 조율하기가 힘들고 어떤 내용이 중요한 것인지 방향을 잡는 역할도 자주 필요한거 같아요. 순간순간 대응도 잘 해야하고...'

개인적으로 XP적인 개발경험이 스크럼을 진행하는데 도움이 많이 된다.
개발자든 스크럼마스터든 XP환경에서 개발하는 경험을 가지는 것을 추천한다.

개발팀원과 코드리뷰를 진행했다.
Happy Path, Information Abstraction에 대한 이야기를 하였다.

개발자가 함께 코드리뷰를 하고 나서 아래와 같은 메일을 보내왔다.
Xxxx (Happy Path) 정리한 것 전달합니다.^^
어제 오늘 좋은 스킬 알려 준 것 뿐만 아니라 내 사고의 틀을 깨줘서 더 고마운 것 같아여.
앞으로 많이 연습해야 겠네요 . ㅋㅋ

agile방법론을 적용하면 왠지 일이 지지부진하게 진행이 안되는 것처럼 느껴진다.
처음 하는 방법이라서 적응하는게 시간이 걸려서 그럴까?

솔직이 해야할 일이나 하는 일이나 별 차이가 없다. 오히려 집중을 잘 할 수 있게 하기에 일에 진도는 잘나간다.
다만 communication에 따른 비용을 잘 조절해 준다면 충분히 이전 방법보다 많은 일을 해냈다고 팀원들이 생각할 수 있다.

일이 잘 진행되지 않았다고 느끼는 점 중에는 이 이유가 크다는 것을 알아냈다.
이전의 일하는 형태는 한 사람에게 큰 단위의 일을 준다. 그 큰 단위 중에서 자신이 자신 있는 부분부터 먼저 처리한다. UI 컨트롤을 먼저 그린다던가 자신이 자주 했던 일을 하며 하기 싫거나 잘 모르는 분야의 일을 나중으로 미루는 경향이 있다. 따라서 위험을 계속 떠안고 간다고 할 수 있다. 그래서 개발팀에 일의 진척률을 물으면 70%나 80%에서 잘 나아가지 않고 정말 큰 문제들은 출시에 가까워서 발생하게 된다.
agile방법은 고객이나 PO의 요청을 우선으로 하여 일을 시작하며 해당 기능을 데모를 통해서 확인하므로 일의 위험성을 최대한 앞으로 노출시킨다. 따라서 일정을 초기에 아예 늘려서 잡거나 예측가능하도록 만드는 효과가 있다고 볼 수 있다.

비싼 몸값의 선수들을 다른 구단에 넘긴 상태에서 어떻게 팀이 승리를 거둘수 있게 할 것인가?

특히 SW개발팀에서 에이스 개발자의 역할이 아주 중요하다. 따라서 에이스가 없는 개발팀이 어떻게 하면 개발을 완료할 수 있을까?

영화에서는 선수들의 기록을 바탕으로 수학적으로 확률을 계산했다. 하지만 개발에서는 출루율이나 타율등에 해당하는 요소가 마땅히 생각나지 않는다. 또 그런 기록이 존재하지도 않는 듯...

브래드 피트가 단장으로 나오는데 감독과 이사회 멤버들은 그의 의견을 들으려하지 않는다. 통계보다는 그들의 직감이 더 정확하고 옳다고 생각했다.
따라서 한마음으로 움직이기가 불가능한 상황이다. 회사에서 애자일을 전파하는 것도 비슷하다. 어느 한쪽이 좋다는 의견을 낸다고 해도 관련된 다른 조직들이 움직여주지 않는다면 성공하기가 어려울 것이다. 하나의 덩어리로 함께 움직여야 한다.

단장의 노력과 실천이 가장 중요하다. 옳다고 생각하는 것을 제대로 적용해서 실천하는 것이 무엇보다 중요하다. 그리고 옆에 피터와 같이 똑똑한 사람이 있으면 좋다. 단장을 옳바르게 또 믿음을 갖고 행동할 수 있었던 원천도 피터가 아니였을까?

현재 개발을 할때 UI담당자가 PO역할을 하고 있다. planning을 할 때 UI담당자가 PB를 시나리오를 보면서 작성하는데...
오늘은 옆에서 관찰을 했다. 이런 점이 발견되었다.
  1. 많은 이야기가 나왔는데 실제로 작성되는 것은 시나리오 관련된 내용들이다. (개발관련 이슈도 몇가지 기록은 되었으나 UI담당자 입장에서 중요도가 떨어지는 것들은 정리되지 않음)
  2. UI담당자 관점의 문서로 작성됨. 그래도 많이 상세해졌지만 너무 많은 내용이 하나로 뭉쳐져 있다. 분리가 필요할 듯.
  3. 이슈나 처리할 일에 대해서 UI담당자와 개발팀이 주고 받을 문서나 정리 자료가 필요한 경우 그 자리에서 언제 누가 보내고 언제 다시 정리될꺼라는 약속을 하는게 중요하다.

어제 개발팀에서 팀원들이 알아서 planning을 하더라. 어떤 식으로 진행되었는지를 살펴봤다.
이전에 팀이 하던 방식으로 돌아갔더라.
업무를 layer로 나누고 각 layer별로 담당자를 정하고 진행해나가기로...
나는 그 개발팀을 리드하고 있는 개발자와 이야기했다.
"어떤 식으로 일을 나눴나요?"
"이래저래 방식으로 일을 나눠서 진행할려구요"
"이렇게 나눈 이유가 있나요?"
"이렇게 나누는게 가장 일이 빨리 끝날꺼 같아서요"
"음...이전에 우리가 했던 방식이랑 차이점이 있는거 같은데요."
"잘 나눠진거 같은데요... 어떤 차이가 있나요?"
"이러쿵 저러쿵... "

"이번 일은 이렇게 나누는게 가장 빨리 끝날꺼 같은데요. 이번주 금요일까지 끝내야 해서 시간도 부족하구요."
"시간의 압박이 있나요?"
"네. 위에서 이번주까지는 끝냈으면 한다고 말을 들어서요."

일정에 쫓기거나 쉬워보이는 일은 이전에 자신이 했던 방법으로 일을 처리하고 싶은 마음이 든다. 스크럼마스터라고 해서 무조건 반대할 수는 없다. 새로운 방법을 적용해서 일이 늦게 끝날지도 모른다는 걱정이 들기 때문이다.

"이렇게 일이 나눠지면 팀원들끼리 대화할 필요가 없어질꺼 같구요. 팀원들이 알고 있는 최고의 방법을 적용할 기회도 없어지는 단점이 있을꺼 같아요. 대신 마음의 안정을 얻을 수 있으리라고 생각됩니다. 그리고 현재 구현하는 부분은 디자인패턴에서 가장 많이 다뤄지는 주제라서 그 부분을 반나절이라도 스터디를 하고 소스코드를 본다면 많은 개선이 될 듯 합니다. 기계적으로 코드를 머지(merge)하는 방향으로 일하면 보람이나 성취감이 확 떨어질꺼 같은데요."
"그래도 일정이 중요해서.."
"1-2 시간더 걸리면 프로젝트에 영향이 큰가요?"
"그건 아니지만.."
"그러면 조금더 리서치를 해보는 것이 좋을꺼 같은데요. 그럼 관련된 디자인패턴 부분을 찾아줄테니까 그 부분을 팀내에서 공유해 주세요"

대화를 마치고 쉽게 쓰여진 디자인패턴 책의 해당 패턴을 개발자에게 전해줬다.

오늘 오후에 개발팀원들이 모여서 어떤 식으로 디자인을 할까 고민하고 있더라. 나는 지쳐보면서 중간에 몇마디 말만 거들었다.
20-30분의 회의가 마칠 때 쯤에 그들은 방향을 잡았다.
"이런 식으로 하면 소스 수정도 크게 하지 않고 바로 머지한 코드가 동작하는지 확인할 수 있겠는데요."

Tip :
오전에는 개발팀 PL과 이야기를 나눴다.
"하루이틀 정도 시간이 더 걸리면 프로젝트에 영향이 큰가요?"
"일정이 조금 빠듯하긴 합니다."
"어제 팀원들을 보니까 일정이 촉박하다고 느끼면서 이전에 자신이 해왔던 가장 익숙한 방식으로 돌아갔더군요."
"아 그래요?"
"일정의 압박은 자신이 예측가능한 방법으로 일을 처리하는 동기가 되는거 같습니다. 저는 팀내에서 학습이 일어나고 좋은 코드나 설계를 익히는 과정이 되었으면 하는 바램이 있었습니다. 개발자 개개인의 역량향상도 중요한 요소라 생각합니다."
"하루이틀 지연되더라도 그런 활동이 일어나는게 바람직한데..."
"지연이 될수도 있고 안될수도 있지만 그런 상황에 대해서 스스로 risk를 팀원이 감당해서 일을 진행할 수 있느냐 마느냐는 아주 중요한 요소라 생각합니다."
"네"
일정이 지연을 좋아하는 PL은 없다 하지만 어떤 가치가 있느냐를 PL에게 확실이 이야기할 수 있다면 대부분의 경우 그들도 동의한다.

오늘 드디어 디자인 패턴에 관련된 내용을 한 사람이 공유하고 발표를 했다.
형식을 최소한으로 하라고 했는데 너무 대충 준비한건 아쉬웠다.
하지만 발표하면서 팀원들이 알고 있는 것을 말하고 또 모르고 있는 것들이 무엇인지가 드러나더라.
지금까지 이런식으로 공부(?)나 기술에 대한 토론이 너무 없었구나하는 생각이 들었다.
이런 자리를 자주 마련해야겠다.

관련 서적

관련 사이트

PythonPowered EditText of this page (last modified 2011-12-08 23:38:38)
FindPage by browsing, searching, or an index
Or try one of these actions: DeletePage, DeleteUploadedFile, LikePages, SpellCheck, UploadFile