바로 이전 포스팅에서 Man-Month를 설명하다가 히어로 개발자를 언급했는데요,

(관련 포스팅, http://storycompiler.tistory.com/142)

이번 포스팅에서는 히어로 개발자라면 응당 받아야할 대접에 대해 써볼까 합니다.


물론, 히어로 개발자의 출몰을 경계하는 의견도 있습니다.

히어로 개발자도 엄연히 사람인지라 후진적인 정치활동으로 조직을 퇴화시킬 수 있습니다.

그렇기 때문에 오히려 히어로 개발자의 등장을 막아야 한다는 의견도 있습니다.


- 독단적인 결정에 따른 그릇된 방향설정

- 의사결정권자 부재에 따른 위험부담 증가

- 의사결정 소요시간의 증가


언뜻 생각해봐도 줄줄이 떠오르는 위와 같은 폐단을 막기 위해,

제 2의 잡스가 출현하는 것을 철저히 막고 있는 것인지도 모릅니다.


하지만, 위의 부정적인 요소는 '히어로' 개발자로 인해 발생하는 것은 아닙니다.

조직에 부여된 권한이 개별 구성원에게 알맞게 부여되지 않았기 때문입니다.


히어로 개발자가 한 명만 살아남은 조직은 결코 건강한 조직처럼 보이지 않습니다.

히어로 개발자 다수가 각각의 하부조직을 견실하게 떠받들고 있어야

조직 전체가 기민하게 움직이며 큰 그림을 함께 그릴 수 있습니다.

그렇게 하기 위해서는 다수의 히어로 개발자가 자랄 수 있는 자양분이 필요합니다.


이 글은 히어로 개발자가 무럭무럭 성장할 수 있는 환경에 대해

아주 편협한 일개 개발자의 시각으로 언급하고 있습니다.

무식하면 깡패라고 편협한 시각에서 오는 무지가 글 곳곳에 듬뿍 담겨 있습니다.

그 점 미리 양해 부탁드립니다.


조직 곳곳에서 자생하고 있는 히어로 개발자 분들은 어떤 대접을 받고 있을까요?

연봉이나 승진에 대한 보장은 이 글의 관심사가 아닙니다.

대신 히어로 개발자에게 주어지는 권한과 의무에 초점을 맞출 생각입니다.


결론부터 말하자면,

히어로 개발자에 대한 처우는 아티스트에 대한 대접과 비슷해야합니다.

다각적인 면에서 오랜 고찰을 통해 히어로 개발자의 생태를 연구한 끝에 내린 결론입니다.


아티스트가 예술작품으로 천문학적인 부가가치를 창출해내듯,

히어로 개발자도 소프트웨어를 예술작품으로 승화시켜 부가가치를 창출합니다.

수많은 국경없는 사용자들이 소프트웨어에 빠져들게 만들지요.


아티스트에 따라 피조물이 완전히 다르듯,

히어로 개발자에 따라 최종결과물도 천차만별입니다.

잘 키운 히어로 개발자는 먼훗날 박물관에 전시해도 손색이 없는 대중문화재를 만들겠죠.


그렇게 하기 위해서는,

히어로 개발자가 작품에 몰입할 수 있는 환경을 제공해주어야 합니다.



프로젝트 선택권

개발자들에게 특히 히어로 개발자에게 자신이 참여할 프로젝트를 선택하게 해야 합니다.

사실, 얼마전에 스타트업 회사에 방문한 기억이 있습니다.

그 회사는 사내게시판에서 신규 프로젝트에 참여할 사람을 공개적으로 모집하고 있었습니다.

프로젝트가 충분히 '될 성 부른 나무'라면 파티인원을 금새 모을 수 있습니다.

하지만, 장애가 많은 프로젝트라면 파티원을 구성하는데도 어려움이 생기겠죠.

다수가 프로젝트에 대해 고민할 수 있는 환경 자체가 시너지가 될 겁니다.

특정 사람들의 이권에 따라 현실성없거나 부질없이 생성되는 프로젝트는 사라질 겁니다.


단기실적이 아닌 장기적인 시각으로 접근하는 프로젝트에는,

파티원이 섣불리 참여하기가 힘들 수도 있습니다.

프로젝트간 적절한 보상장치는 따로 고민해봐야하겠지만,

이 경우 프로젝트 리더의 역량이 파티원에게는 중요한 판단근거가 될 수 있습니다.

훌륭한 리더 밑에는 우수한 파티원이 모일겁니다.

그렇지 않은 보스는 파티원을 모으기조차 힘들어지겠죠.



백로그 결정권

백로그는 우선순위가 명시된 작업열람표입니다.

애자일 개발방법론에서는 백로그 리스트로 작업사이클마다 다뤄야할 일을 확정합니다.

프로젝트를 위해 반드시 해야할 일은 백로그에 추가합니다.

그리고 할 필요가 없는 일은 백로그에서 제외합니다.


해야할 일과 그렇지 않은 일을 나누는 것에 대한 결정을 누가 해야할까요?

그리고 해야할 일에 우선순위를 부여하는 것은 누구일까요?


기획, 디사인, 개발, 검증, 영업?

프로젝트에 관여하는 모두가 프로젝트에 대해 자유롭게 의견을 낼 수 있습니다.

다양한 시각에서 다양한 이유를 들어 다양한 항목을 백로그에 추가하려 시도할 수 있습니다.

하지만, 최종결정은 프로젝트에 참여하고 있는 개발자의 손에서 이뤄져야 합니다.

Product owner, Team leader, Project leader...

어떤 이름이건 실제 개발에 참여하고 있는 개발자가 해야합니다.

개발자 중 가장 탁월한 히어로 개발자가 '합리적으로' 최종의사결정을 내리게 되겠지요.



아키텍쳐 결정권

프로젝트를 위해 해야할 일이 결정되면,

요구사항에 따라 아키텍쳐를 설계해야합니다.

새로운 요구사항이 기존 아키텍쳐에서 수용하기 힘든 경우가 있습니다.

그럴 경우에는 아키텍쳐를 완전히 뜯어고치더라도 요구사항을 개발해야 합니다.


어떤 경우든 아키텍쳐는 프로젝트를 담당하고 있는 히어로 개발자가 선택할 수 있어야 합니다.

더 나은 길이 존재하는 경우라면 그 길을 선택하면 됩니다.

하지만, 가치나 정책의 충돌에서는 프로젝트의 철학을 꿰뚫고 있는 개발자가 나서야 합니다.

그리고 그게 대부분은 히어로 개발자가 되겠군요.



정예개발자 육성

히어로 개발자도 처음에는 루키였습니다.

처음부터 히어로인 개발자는 거의 없을 겁니다.

따라서 개발자를 히어로 개발자로 성장시키기 위한 고민을 언제나 해야합니다.

어제는 형편없다고 생각했던 개발자가 내일은 우수한 개발자로 성장할 수 있습니다.


히어로 개발자가 오만에 빠지지 않도록 유의하며,

자신과 함께 일하는 개발자들의 성장에도 관심을 기울여야 합니다.

그리고 개발자 교육을 위해 필요한 수단을 결정할 수 있는 권한이 있어야 합니다.

필요하다면 몇 주간 교육을 보낼 수도 있고,

책 몇 권을 사다주며 세미나를 부탁할 수도 있겠죠.



자유 도서구입권 & 컨퍼런스 자유이용권

히어로 개발자도 끊임없이 공부해야합니다.

개발자 세계에서 영원한 진리는 없습니다.

그렇기 때문에 개발자 자신은,

매일의 트렌드를 익히고,

새로운 기술을 익히고,

참신한 이론을 엿보고,

신선한 발상에 끊임없이 노출되어야 합니다.


그렇게 하기 위해서는 개발자 성장에 적극 투자해야합니다.

읽고 싶은 책은 마음껏 구매하게 합니다.

참석하고 싶은 컨퍼런스에는 마음껏 참석하게 합니다.

개발자 성장을 위한 비료가 투자아닌 비용으로만 여겨진다면,

개발자 문화나 조직문화에 문제가 있는게 아닐까요?



개발을 위한 개인공간

히어로 개발자는 예술가에 가까운 존재라고 언급했습니다.

매일같이 고도의 집중력을 요하는 작업을 수행하고 있습니다.

그러나 열린 공간을 지향하다 보니,

집중할 수 있는 시간 5분을 마련하기 힘듭니다.


다른 부서의 히어로 개발자들 의견을 들어보면,

새벽이나 밤이 되서야 비로소 자기 일을 할 수 있다고 합니다.

낮시간에는 주로 다른 개발자나 다른 부서의 의문이나 요청을 처리한다고 합니다.

이런 식으로 개발이 진행되면,

히어로 개발자의 업무효율을 바닥을 치게 됩니다.

일과시간에도 집중하여 자신의 업무를 처리할 수 있는 시간이 필요합니다.


하루 종일 폐쇄된 공간에서 활동할 필요는 없습니다.

그렇지만, 개인업무에 필요한 시간 만큼은,

개인공간을 보장해주어야 합니다.



최상의 도구 제공

히어로 개발자 뿐만 아니라 모든 개발자는 최고의 도구를 갖고 있어야 합니다.

목수는 연장 탓을 하지 않지만,

개발자는 철저히 연장 탓을 해야 합니다.

컴퓨터 성능에 따라 개발자의 업무 효율을 극단적으로 바뀝니다.

빌드가 10초내로 되느냐에 따라 개발자의 집중도에 차이가 납니다.


모니터의 크기나 개수에 따라 개발효율이 달라집니다.

한 눈에 필요한 정보를 얻을 수 있게 뒷받침해줘야 합니다.


키보드, 마우스, 의자는 개발자의 건강생활과도 직결되어 있습니다.

건강한 개발자가 건강한 코드를 작성하는 법입니다.



이 글은 제 주위에 있는 히어로 개발자들을 보며 쓰게 되었습니다.

임원급, 간부급, 사원급 모두에 히어로 개발자가 있더군요.

히어로 개발자에게는 더 좋은 소프트웨어를 만드려는 순수한 열정이 넘칩니다.

그런 사람들과 함께 일하는 것만으로도 충분히 동기부여가 됩니다. :)


더 많은 히어로 개발자가 한국에 출몰하여,

한국의 소프트웨어 경쟁력을 몇단계 올릴 날을 기대해봅니다.


끝_


  1. 코코콩 2015.10.13 13:41 신고

    와 글 잘보았습니다.
    윤진님 밑에서 개발을 배우면 엄청난 정석개발자가 될 것 같네요 ㅋㅋㅋ
    윤진님께서는 스타트업하실생각없으신가요?
    지금 계신곳 밑으로 따라가긴 제가 너무 부족하고 ㅎㅎㅎ 스타트업하신다면 헐값에라도 일하고싶은생각이 드네요
    좋은하루되세요( _ _ )

    • 코코콩님, 이 댓글에는 함부로 답을 달면 안될 것 같아서 망설이고 있었습니다. 히힛;
      히어로 개발자도 아니거니와 저도 열심히 공부해야할 때라서요. :)
      하지만, 코코콩님과 함께 일해보고는 싶습니다.
      이 세계는 의외로 좁은 세계이니 열심히 하다보면 만날 날이 오지 않을까요? :)

    • amaze_ 2015.10.15 00:26

      엇. 저도 비슷한 생각을..
      이런사람 밑에서 일해보고싶다구요ㅎㅎ
      많이 성장할수 있을것 같습니다

    • amaze_님,
      뭐 드시고 싶으세요? :)


우선 본 포스팅을 게시함에 앞서,

본 포스팅은 지극히 개인적인 의견임을 알려드립니다.


프로젝트에 애자일을 도입할 때,

애자일의 지엽적인 부분만 도입해놓고 제대로 적용했다고 주장하는,

우스꽝스러운 상황을 보고 싶지 않기에,

지극히 주관적인 관점에서 우선순위를 지정해보았습니다.


< 우선순위 上 >

- 프로젝트 라이프사이클

프로젝트의 라이프사이클 내내 요구수집, 제품디자인, 기술훈련, 개발활동 그리고 검증절차 모두가 지속되어야 합니다.

요구수집을 초반에 진행하고,

검증절차는 과제 막바지에 진행하는 단계별 절차관리는 애자일이 아닙니다.

요구사항은 언제든지 바뀔 수 있기에 아키텍쳐는 언제든지 재설계되어야 합니다.


- 반복주기와 피드백

프로젝트 라이프사이클 중에는 일정 기간이 되풀이되는 반복주기가 있습니다.

하나의 반복주기에는 제품개발을 위한 모든 활동을 포괄합니다.

제품 디자인부터 구현과 검증까지 하나의 반복주기에 수행됩니다.

각 반복주기의 끝은 과제 관련인들이 모여 피드백을 합니다.

피드백은 다음 반복주기에 다뤄질 수 있겠죠.


- 프로젝트 구성원

프로젝트를 진행할 때 필요한 모든 사람이 프로젝트 구성원이 될 수 있습니다.

개발자들로만 이뤄진 프로젝트일 필요는 없습니다.

디자이너와 테스터 혹은 상품기획자나 검증자도 함께할 수 있습니다.

소프트웨어 업계에서 분업이 각자 따로 일한다는 것을 의미하지 않습니다.

어느 정도 서로의 역할분담은 정해져 있지만,

역할경계를 초월하여 문제를 바라봐야 좋은 아이디어가 나올 수 있습니다.


- 프로젝트 의사결정권

프로젝트에서 다뤄지는 수많은 요구사항들에 대한 우선순위를 정하는 주체는,

프로젝트에 직접적으로 참여하는 디자이너 + 개발자가 되어야합니다.

디자인은 디자이너에게 위임하고,

개발은 개발자에게 위임해야 합니다.

프로젝트에 직접 참여하지 않은 사람이 프로젝트의 세부사항에 대해 의사결정을 하는 것은,

때로는 굉장히 위험해보이기까지 합니다.


< 우선순위 中 >

- 백로그 관리

자신이 수행해야하는 작업은 백로그로 관리해야 합니다.

백로그에는 우선순위, 작업예측시간, 실제소요시간 등이 기입되겠지요.

백로그에 기입된 작업들은 철저히 우선순위에 따라 진행되기 때문에,

무분별한 컨텍스트 스위칭으로 인한 업무방해를 근본적으로 배제할 수 있습니다.

작업시간 예측은 지속적인 예측행위를 통해 점차 정밀한 시간예측 축으로 수렴할 겁니다.

사전예측을 통해 업무분담이나 일정을 잡아야 하기 때문에,

예측을 하는 훈련을 계속할 필요가 있습니다.


- 간소한 설계

소프트웨어 업계에서 완벽한 설계가 있는지 모르겠습니다.

요구사항이 빈번하게 바뀌기에 매번 완벽한 설계를 유지하는 것도 상당한 시간이 소요됩니다.

설계는 바로 코드로 치환이 가능할 정도로 자세할 필요가 없습니다.

세부사항은 코드를 짜며 확정해도 무방합니다.

설계는 프로그램의 방향을 결정짓고 정책을 확정하는 정도로 진행하여 시간소모를 줄여야 합니다.


- 트레이드오프의 이해

모든 조건을 만족하는 완벽한 해결책은 보기 힘듭니다.

대부분의 경우 하나를 얻으면 다른걸 놓치게 됩니다.

모두를 취하는 묘수는 인생의 은사를 만나는 것만큼 힘듭니다. :)

성능, 비용, 소요시간, 일정, 개발편의 등 수많은 요소가 상충하기 때문에,

한계효용이 가장 높은 요소를 택하여 기회비용을 가급적 낮춰야합니다.

별로 중요하지 않은 요소를 지키고자 무리하게 다른 요소를 희생하는 경우가 있는데요,

그런 부류의 사람들과 함께 개발하는 것은 참 곤욕입니다.


- 독해우선의 코딩

코딩을 하면 코드 최적화를 위해 수많은 테크닉을 사용하는 경우가 있습니다.

하지만, 코드 최적화보다는 코드를 쉽게 독해할 수 있게 짜야합니다.

자기 혼자만의 코드라 할지라도,

코드독해에 노력과 시간이 소요된다면 코드 재활용성 측면에서 좋지 않습니다.

과거 몇 년전만 하더라도 최적화 테크닉을 신봉하던 때가 있었는데요,

이제는 기계를 위한 코드보다 인간을 위한 코드로 무게중심이 바뀌었습니다.


- 코드통합

코딩은 지속적으로 메인 스트림에 통합되어야합니다.

통합주기가 길어지면 통합을 위한 비용도 증가하게 됩니다.

작업할 내용이 많다면,

작업을 몇가지 단계로 쪼개어 단위작업별로 통합할 수 있게 관리해야합니다.


- 단위테스트

프레임워크 개발자들은 코드를 수정하면 반드시 단위테스트를 해야합니다.

단위테스트 없이 수정사항을 통합하면,

문제가 발생하여 다른 개발자의 시간을 소모할 수 있습니다.

매번 단위테스트를 하느라 수 분을 버리는게 아깝다면,

자신의 실수로 인해 다른 수많은 개발자의 몇 시간을 소모한다고 생각해주세요.


- 이슈추적

발생한 이슈는 반드시 관리되어야 합니다.

이슈라는게 유사한 형태로 끊임없이 되풀이되는 특징이 있습니다.

문제발생일, 문제에 대한 묘사, 해결책에 대한 상세한 설명, 관련 코드나 문서를 정리해놓으면,

반드시 재사용하여 빛을 볼 날이 올 겁니다.

소극적으로 경험을 쌓는 것 뿐만 아니라,

적극적으로 경험을 되새길 수 있도록 약간의 노력을 가미하면,

좀 더 기민하게 문제에 대응할 수 있게 됩니다.


< 우선순위 下 >

- 멘토되기

훌륭한 멘토는 좋은 질문을 멘티에게 던져,

멘티가 스스로 답을 찾을 수 있게 도와준다고 하는데요.

이것도 상황을 봐가면서 해야합니다.

프로젝트에는 일정이 있고 개발자의 수준은 천차만별이기 때문에

직접 답을 보여주고 왜 그게 답인지 직설적으로 설명해야하는 경우도 있습니다.

이슈가 터져서 수 분 혹은 수 시간 내에 해결을 해야 하는데,

구글링의 키워드를 알려주는 것은 때로는 너무 잔혹한 행동입니다.


- 짝 프로그래밍

두 사람이 함께 코딩을 하는 것은 굉장한 즐거움입니다.

키보드를 잡고 있는 사람이 놓친 부분은 관전하는 사람에게 발견됩니다.

짝 프로그래밍을 하면 별도의 코드리뷰가 필요없어집니다.

코딩을 하는 순간 리뷰가 되니까요.

짝 프로그래밍은 혼자 코딩하는 것보다 효율이 좋고,

모듈의 전문가를 다수 양성할 수 있다는 측면에서 널리 유포하고 싶습니다.


- '왜'인지 질문하기

'무엇'에 대한 질문도 필요하지만,

'왜'에 대한 질문도 꼭 필요합니다.

코드로 확정된 사실을 살펴볼 수는 있지만,

행간에 놓인 존재이유는 코드만 가지고 파악하기가 쉽지 않습니다.

끊임없는 질문으로 스스로 납득하고,

더 나아가 다른 개발자도 납득시킬 수 있는 코드를 만들어야 합니다.


- 신기술에 대한 태도

프로젝트에 새로운 기술을 적용해야하는 시점이 있습니다.

이때는 직접 프로토타이핑을 진행하여 신기술의 구현정도와 구현상태를 확인해야합니다.

제대로 프로토타이핑을 진행하지 않은 상태에서,

무턱대로 신기술을 탑재한다면,

해당 기술을 적용할 개발자들의 시간만 낭비하는 셈이 되겠지요.


- 간이세미나

개발자간의 끊임없는 교육활동의 일환으로,

한주에 한두번 간단한 세미나를 통해 정보를 공유해야 합니다.

발표는 10~15분 정도 간단하게 진행하고,

프로제트와 세미나 주제간의 연결고리를 찾아 토의를 진행하면 좋겠지요.

발표를 준비하는 사람이나 발표를 듣는 사람이나 모두가 발전할 수 있는 기회가 될 겁니다.


- 실수의 인정

숙련된 프로개발자도 연중 행사로 간혹 실수를 하곤 합니다.

일반개발자들이야 그보다 더 자주 더 많은 실수를 쏟아내곤 하지요.

하지만, 개발자 스스로가 자신이 실수를 인정하고,

자신의 실수로 파생된 문제에 대해 다른 개발자에게 사과하는 것은 거의 본 적이 없습니다.

자신으로 다른 사람이 피해를 봤는데 사과를 하지 않더라고요.

자신의 실수에 대해 용기있게 사과하는 것은 당연한 행동입니다.

결국 감정에 영향을 받는 인간사회이기 때문에,

서로간에 불필요한 감정소모는 최대한 줄여야 합니다.


- 버그유발자 색출금지

사람은 누구나 실수를 합니다.

실수를 한 사람을 찾아 책임을 묻고 비난을 하는 것은 별로 좋은 방법이 아닙니다.

문제를 찾으면 문제를 해결하기 위해 에너지를 쏟아야하지,

그 외의 불필요한 감정소모는 최대한 억제해야 합니다.

경험상 비난은 접고 문제만 올곧이 바라봐야 팀원간의 결속도 단단해집니다.


지극히 개인적인 생각의 나열이라,

애자일의 다른 중요한 요소가 빠졌을 수도 있습니다.

빠진 부분은 틈나는대로 보강하려 합니다.


그럼 좋은 하루 보내세요~

끝_


최근 재미난 형태의 프로젝트에 참여하고 난 후,

세상에 존재하는 다양한 형태의 개발 프로세스를 접하고 싶다는 생각이 들었습니다.

개발 프로세스에 따라,

- 제품이 완성되는데 소요되는 기간

- 완성품의 질적수준

- 프로젝트 참여자의 만족감

등이 확연하게 달라지는 것을 체감하였기 때문입니다.


학부 때부터 줄곧 보아왔던 개발 프로세스는,

공산품 제조 프로세스를 거의 그대로 따온 Waterfall 프로세스였습니다.

제조 기반의 소프트웨어업체는 아직도 상당수 이 프로세스를 사용하겠지요.



Waterfall 개발방식은 누가봐도 명확한 절차를 따릅니다.

- 개발에 앞서 고객으로부터 요구사항을 받고,

- UX 디자이너는 요구사항을 면밀히 분석하여 User eXperience 문서를 작성하고,

- 아키텍트는 UX를 이리저리 보고 UX Designer와도 협의를 하여 아키텍쳐를 설계하고,

- 프로그래머 혹은 코더는 온갖 삽질을 병행한 개발을 시작합니다.

- 까탈스러운 검증자는 결과물을 보고 딴지를 걸기 시작하지요.


아키텍트나 프로그래머에 의해 개발단계에서 UX 디자인이 변경되기도 합니다.

주로 개발제한요건이나 일정상의 이유로 UX 디자이너와 논의하여 디자인을 변경하지요.

이런 수정은 개발단계 이전이나 진행 중에 주로 발생합니다.

개발자가 요청하여 UX에 반영한 사항이기 때문에 개발자는 기분좋은 마음으로 수정에 임하지요.


하지만, 구현이 완료된 다음 검증자에 의해 UX 디자인이 바뀌는 경우도 있습니다.

요구사항 혹은 UX 디자인 단계에서도 검증자의 눈에 들지않을 만한 것을 끊임없이 수정하였겠지만,

검증자가 완성품을 보고 문제를 제기할 수 있습니다.

검증자는 단순 테스터일 수도 있고 경영진 중 한 분 일 수도 있겠지요.


바로 이 시점에 UX 디자이너는 자신의 디자인에 대한 자부심을 지킬 것인지

아니면 자신의 밥그릇을 지킬 것인지 고민합니다.

물론, 검증자가 제기한 문제가 프로젝트에 치명적인 결함을 막을 혜안의 결과일수도 있습니다.

어찌되었건 UX가 바뀌면 디자이너는 하루나 이틀 작업으로 새로운 가이드를 만듭니다.

그리고 개발자는 새로운 가이드를 보고 며칠씩 밤을 새며 작업을 이어가겠지요.

이미 프로젝트를 완성해야하는 시간이 임박해왔을테니,

아키텍쳐 따위는 잠시 접어두고 스트레스가 행간에 가득한 땜빵(?) 코드가 들어갑니다.


제가 경험한 대부분의 프로젝트는,

프로젝트 시작단계에서부터 마지막에 이르기까지 Requirement가 계속 바뀌었습니다.

첫 단계가 바뀌기 때문에 이후에 진행되는 모든 단계마다 리스크 관리를 해야했습니다.

소프트웨어 개발은 Requirement가 너무나 쉽게 변경되곤 합니다.

그리고 이런 식으로 Requirement가 바뀐다면 개발 프로세스도 그에 적합하게 바꾸는 것이 좋겠지요.


사실, 개발 프로세스를 바꾸려면 변경된 프로세스에 최적화된 조직을 구성해야합니다.

개발조직이 변경되면 변경된 조직에 대한 관리체계도 다시 세워야하고요.

관리체계를 뿌리부터 흔들면 관리자들은 여러가지로 고민하겠지요.

그래서 개발 프로세스를 변경하는 것이 매번 좌절되는 것인지도 모르지요.



하지만, 스크럼은 기존 조직을 유지하면서 개발 프로세스에만 변화를 줄 수 있습니다.

그것이 수많은 조직에서 스크럼을 선택한 이유이겠지요.


제조업 중심의 조직에 스크럼을 적용하기 위해서는,

각 조직별로 To do list부터 정리하는 것에서부터 시작해야합니다.

To do list에는 말 그대로 수행해야할 태스크들의 목록입니다.

하나도 빠짐없이 적겠다는 필념으로 나열할 필요는 없습니다.

현 시점에서 파악된 디테일에 대한 태스크 정도만 명시해두면 됩니다.

스크럼에서는 이 To do list를 백로그(backlog)라고 부르고,

제품을 완성하기 위해 수행하는 백로그는 제품백로그라 부릅니다.


그리고 백로그에 아주 중요한 항목을 하나 추가합니다.

바로 '우선순위'입니다.

각 태스크별로 우선순위를 명시해줍니다.

우선순위는 우선순위가 높은 것을 개발하기 위해 우선순위가 낮은 것을 포기할 수 있다는 의미입니다.

모든 태스크가 전부 최우선순위일리는 없습니다.

최우선순위부터 최하위순위까지 순차적으로 순위를 정해봅니다.

'나쁜' 아이디어는 없지만 우선순위에서 밀려서 구현에서 제외되는 아이디어가 생기겠지요.


그리고 백로그에 명시된 태스크를 하나씩 살펴보며 각각 소요시간을 산정해봅니다.

각각의 태스크는 4시간 ~ 16시간 정도 사이즈로 관리되는게 좋겠지요.

최소 반나절에서 최대 이틀정도의 시간에 처리가 가능한 태스크인게 좋겠지요.

추정치는 말 그대로 '추정'이기 때문에 반드시 일치할 필요는 없습니다.


백로그를 작성하였다면 이제 실천할 차례입니다.

우선순위가 높은 항목을 위주로 '스프린트' 기간동안 개발가능한 피쳐들을 고릅니다.

'스프린트'는 스크럼에서 반복적으로 백로그 중 일부를 수행하는 기간을 의미합니다.

'스프린트'는 통상 한달 정도의 시간으로 운영되지만 팀사정에 따라 변경할 수 있기에,

팀원들은 기간에 알맞게 피쳐들을 골라야 합니다.


스프린트에 수행할 백로그'만' 스프린트 기간내에 처리하면 됩니다.

정해진 태스크 외에는 설사 ASAP 꼬리표가 달린 태스크라 할지라도 다음 스크럼 기간으로 미룹니다.

'연기의 미학'을 유감없이 발휘해야합니다.

어디서부터 요구사항이 비롯되었건 다음 스크럼 기간으로 과감하게 연기합니다.

그래서 개발자는 현재 스크럼 기간에 할당된 일에만 집중할 수 있게 됩니다.

불필요한 컨텍스트 스위칭을 제거하여 개발효율이 높아질 수밖에 없습니다.

이 점에서 두뇌노동자인 개발자들의 환호를 받습니다.

온전히 하나에 집중할 시간을 보장받게 되는 짜릿한 순간입니다.


이렇게 한 달 동안 스프린트 백로그에 명시된 태스크만 수행해나갑니다.

아키텍쳐나 프로토콜 설계를 첫 스프린트에 완성할 필요는 전혀 없습니다.

그저 주어진 백로그에 맞는 아키텍쳐만 그리면 충분합니다.

나머지는 다음 스프린트 또 그 다음 스프린트에서 처리하면 됩니다.


계획은 추정일 뿐이기 때문에,

태스크를 수행하다보면 시간이 모자라거나 남을 수도 있습니다.

그때는 '상식적으로' 행동하면 됩니다.

스프린트에 수행할 태스크를 좀 빼거나 더하여 현실적으로 달성가능한 목표를 재설정합니다.


한달이 지나면 '데모 가능한 수준'의 릴리스가 나와야합니다.

릴리스 회의에는 프로젝트 참여자 뿐만 아니라 관리자나 경영자 혹은 고객까지 참여할 수 있습니다.

데모를 통해 개발의 현단계를 가늠할 수 있고,

다음 스크럼 기간동안 해야할 일들의 우선순위를 조정합니다.

실제로 소프트웨어가 돌아가는 모습을 보면 번뜩이는 아이디어도 쏟아져 나오기 마련입니다.

제품 백로그에 새로운 의견을 잔뜩 추가하고,

다음 스프린트에 수행할 태스크를 우선순위를 기준으로 고릅니다.


'스프린트'는 백로그의 태스크로 움직입니다.

그렇다면 매일매일의 일과에서는 스크럼은 어떤 영향을 줄까요?


스크럼은 매일 아침 '일일 스크럼'이라 불리는 15분 정도의 회의를 진행합니다.

회의에는 오직 세가지 물음에 대한 답변만 존재합니다.

- 어제 한 일은 무엇인가?

- 오늘 할 일은 무엇인가?

- 일을 수행함에 있어 장애는 무엇인가?

이 회의는 누구나 참석할 수 있지만,

간결한 회의 진행을 위해 오직 팀원만 발언할 수 있습니다.

매일매일의 회의를 통해 개발자의 귀중한 시간을 빼앗지 않으려고 하는 것이지요.


일일 스크럼이 끝나면 일일 스크럼 시간에 나온 다양한 이슈들로 토론이 벌어집니다.

모든 팀원이 참여할 필요는 없습니다.

관심있는 개발자만 참석하여 고민거리를 함께 해결해나가는 것이지요.


그리고 스크럼을 운영하는 스크럼 마스터는 개발에 장애가 되는 부분을 잘 갈무리해두었다가,

개발자들이 원활히 개발할 수 있게 모든 장애를 제거해주어야 합니다.

스크럼 마스터는 처음부터 끝까지 '어떻게 하면 개발자가 개발본연에 집중할 수 있을까?'에 대해 집중적으로 고민합니다.


스크럼 마스터를 제외하고는 전부 코딩을 해야합니다.

아키텍트나 프로토콜 설계자라고 코딩을 하지 않을 이유는 없습니다.

팀이 스프린트 백로그 개발을 모두 달성하려면,

중간관리자라이든 신규개발자이든 한마음으로 vi를 열고 코딩을 해야겠지요.

한국의 개발환경에서는 백발개발자를 찾기 힘든데요,

백발개발자의 찬란한 노하우가 후배개발자에게 원활히 전수되는 그 날이 어서 와야합니다. :)


스프린트 초반에 흔히 볼 수 있는 모델링에 대해 스크럼은 아래처럼 이야기 합니다.

"모델링을 할지 여부를 선택에 맡겼을 때 팀의 생산성이 올라가는가?"

모델링이나 문서는 코드가 진화함에 따라 퇴화하는 경우가 많습니다.

개발자가 생각을 정리하는 용도로만 모델링을 사용하는 것은 좋은 선택이겠지요.

오로지 개발에 유익한 활동만을 추려내고 그 외의 루틴은 다 거둬들여야 합니다.


스크럼을 적극적으로 도입했을때 얼마나 효과를 볼까요?

스크럼 본문에 있는 내용을 그대로 옮겨봤습니다.

이렇게 스크럼을 적용하면 생산성은 5~25% 정도만 (향상되는게) 아닙니다. 스크럼에서 생산성이 높다고 말할 때에는 종종 서너 자리, 즉 수백 퍼센트 더 높다는 것을 의미합니다.[각주:1]


오늘은 여기까지 하겠습니다.

그럼 좋은 하루 보내세요~

끝_


  1. 켄 슈와버 · 마이클 비들, "스크럼", 인사이트, 2008, xxiv [본문으로]
  1. 탑메이지 2015.10.13 17:18

    좋은글 감사합니다. 페북으로 링크합니다.

+ Recent posts