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

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


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

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

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

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


< 우선순위 上 >

- 프로젝트 라이프사이클

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

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

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

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


- 반복주기와 피드백

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

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

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

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

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


- 프로젝트 구성원

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

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

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

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

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

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


- 프로젝트 의사결정권

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

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

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

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

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

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


< 우선순위 中 >

- 백로그 관리

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

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

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

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

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

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

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


- 간소한 설계

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

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

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

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

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


- 트레이드오프의 이해

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

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

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

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

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

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

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


- 독해우선의 코딩

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

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

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

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

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

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


- 코드통합

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

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

작업할 내용이 많다면,

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


- 단위테스트

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

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

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

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

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


- 이슈추적

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

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

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

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

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

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

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


< 우선순위 下 >

- 멘토되기

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

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

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

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

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

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

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


- 짝 프로그래밍

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

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

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

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

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

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


- '왜'인지 질문하기

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

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

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

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

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

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


- 신기술에 대한 태도

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

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

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

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

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


- 간이세미나

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

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

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

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

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


- 실수의 인정

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

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

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

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

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

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

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

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


- 버그유발자 색출금지

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

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

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

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

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


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

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

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


그럼 좋은 하루 보내세요~

끝_


대규모 소프트웨어를 개발을 위해,

노련한 개발자들이 치밀한 계획을 수립한다고 해도,

계획을 구성하는 각각의 요소들이 조금씩 틀어지기 마련입니다.

스펙, 일정, 역할, 인원, 우선순위, 작업방식, 리더, 구성원...

바뀌지 않는 것은 '계획이 틀림없이 바뀔 것이다'라는 구성원들의 믿음 정도일 겁니다.


계획을 수립하는 순간,

매일매일 계획이 틀어지는 것을 지켜보는 것은 상당한 스트레스입니다.

그래서 아예 계획보다 변화에 대응하라고 조언하는 애자일 선언문이 더욱 그럴듯해 보입니다.


http://agilemanifesto.org/


위의 선언문은 2001년 미국 유타주에서 개발자 몇 명이 만든 애자일 소프트웨어 개발 선언입니다.

미국에서는 14년 전에 나왔고,

한국에서는 2000년대 중반에 소개되었습니다.


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


위의 사이트에서 한국어버전도 찾아볼 수 있습니다.

영어, 한국어 말고도 온갖 언어로 번역되어 있습니다.

그만큼 여러 나라에서 인기를 끌고 있다는 것이겠지요.


애자일이 강조하는 요소는,

- 개인과 상호작용

- 소프트웨어 자체

- 고객과 협력

- 변화에 대응

위의 구문들만 보면 문제될 것은 없습니다.


하지만, 위의 요소를 기존에 중요하다고 여긴 가치와 비교하여 좀 더 파괴력을 가졌지요.

- 공정과 도구

- 문서

- 계약협상

- 계획

위의 단어들은 프로젝트를 진행할때 너무나 중요한 단어들입니다.

저 단어들과 상반되는 룰을 프로젝트에 적용하는 것은,

프로젝트를 위험에 빠뜨리는 무모한 요인처럼 느껴질 수도 있습니다.


물론, 고작 열 손가락 안에 드는 인원으로 개발하는 프로젝트에는,

아무 어려움 없이 무모하게 스크럼을 짜서 스프린트할 수 있습니다.

(스크럼이나 스프린트는 http://storycompiler.tistory.com/137 참고)

실제로 스크럼을 짜서 업무성과가 수직상승한 예는 주변에 널려 있습니다.


하지만, 대규모 프로젝트에서도 가능할까요?

막강한 의사결정권자와 촘촘한 중간관리자가 포진해있는 관료조직은,

정형화된 조직구조와 고착화된 시스템운용방식이 있을텐데요,

애자일 개발방법으로 전환하면 여러가지 파격적인 시도들이 이뤄질 겁니다.


우선 거대 프로젝트를 많아야 열명 남짓한 작은 프로젝트 수십개 혹은 수백개로 쪼개는게 좋겠네요.

그리고 각 프로젝트 별로 참여자를 뽑아야겠죠.

(뽑는 방식을 고민하는 것도 즐거운 일이겠네요)

그 중에는 디자이너와 개발자와 평가자가 한팀이 되어 활동하는 프로젝트도 있을테고,

고객이나 경영자가 한 팀으로 참여한 프로젝트도 있겠죠.

이런 방식으로 문제에 기민하게 대응하게 되어,

좀 더 좋은 소프트웨어를 개발할 확률이 높아집니다.

물론, 팀은 해체되고 조직의 구성원이 뒤죽박죽이 되니,

인사권이나 평가권에 큰 변화가 있겠네요.


각각의 프로젝트에는 독립적인 위상이 부여되고,

일방적인 명령하달에 의한 개발우선순위 변경은 없어져야 할 겁니다.

프로젝트의 운명을 결정하는 것은,

프로젝트에 참여하는 사람들에게 주어질 것입니다.

프로젝트에 대해 가장 잘 아는 사람에게 결정권을 주면,

좀 더 좋은 소프트웨어를 개발할 확률이 높아진다고 믿습니다.


연중 계획은 의미가 없어지고, 매달 계획이나 그보다 작은 단위의 계획과 실천이 중요하겠죠.

개략적인 방향으로서 연중 계획은 필요하겠지요.

수많은 프로젝트가 함께 유기적으로 행동해야하는 경우라면,

일정과 내용에 대해서는 모두의 합의가 있어야하니까요.

하지만, 세부적인 계획과 실천은 짧은 사이클을 타며 기민하게 동작하는게 좋겠죠.

그 편이 좀 더 유연한 소프트웨어를 개발할 확률이 높아질테니까요.


중간관리자의 역할은 여러가지 측면에서 바뀔지도 모르겠네요.

프로젝트에 직접 참여하는 중간관리자는,

노련한 개발자로서 활동하게 되겠지요.

아키텍쳐를 그리고 코딩을 하면서 프로젝트에 직접적으로 기여할겁니다.

프로젝트를 관리하는 중간관리자는,

다수의 프로젝트의 애로사항을 체크하여 개발에 장애가 되는 요소를 없애줘야겠지요.

그렇게 해야 소프트웨어 개발에 박차를 가할 수 있겠지요.


평가는 프로젝트에 참여한 사람들이 다면적으로 진행할 수 있겠네요.

프로젝트의 성공을 위해 다음에도 함께하고 싶은 사람이 있을테고,

반대로 함께하면 안되는 사람도 여실히 드러날 수 있습니다.

언제나 평가와 관련된 부분은 조심할 수 밖에 없기 때문에,

여기서 함부로 논의할만한 주제는 아닌 것 같네요.

하지만, 어쨌든 프로젝트가 끝나고 다음 프로젝트가 계속될 때도 함께한다면,

그 구성원은 서로를 신뢰하고 믿는다는 증거이겠죠.


대규모 프로젝트에 언제나 완벽한 판단을 하는 천재가 있다면,

그 사람의 견해를 언제나 따르면 됩니다.

하지만, 그런 사람이 없다면,

수평적인 의견을 종합하여 의사결정을 하는 방법도 고민해봐야합니다.

대규모 프로젝트에 있는 수많은 소규모 프로젝트의 구성원 모두가 의사결정에 보탬이 되면 좋겠죠.

투명한 정보공개에 자유로운 의사표현이 더해져,

좀 더 나온 결과를 선택하여 더 나은 소프트웨어를 개발할 확률이 높아지겠죠.


어쨌든 대규모 프로젝트에 애자일을 적용하는 것은 쉬워보이지 않습니다.

특히 관료화된 집단에는 집단의 이익과 대치되는 변화가 필연적으로 따라오기 때문에,

자기파괴를 통한 재탄생이 쉽지만은 않겠죠.


성공적으로 거대집단에 애자일 프로세스를 적용한 사례를 찾아봐야겠네요.

각각 집단의 관습에 따라 수많은 수정버전이 있겠군요.


이 모든게 더 나은 소프트웨어를 만들기 위한 고민이라고 생각합니다.

고민의 결과를 조금씩 실생활에 적용해보고 시행착오를 겪으면,

경험적으로 더 나은 방법을 찾을 수 있으리라 생각합니다.


끝_


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

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

개발 프로세스에 따라,

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

- 완성품의 질적수준

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

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


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

공산품 제조 프로세스를 거의 그대로 따온 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

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

지난 4월 30일 목요일,

5월 1일 메이데이 연휴 전날.


아침 9시까지 흐드러지게 늦잠을 자고-

어젯밤에 골라 놓은 'UX 디자이너 코스프레' 옷을 입고 나왔습니다.


집 앞에서 버스를 탔습니다.

햇살은 기가 막혔고,

아침에 부는 바람도 시원했습니다.


정말 UX 세미나를 듣기에,

적합한 날씨였습니다-



안녕하세요, 디자이너를 흠모하는 개발자 윤진입니다.


세미나는 흥미를 충분히 유발하는 제목을 달고 있네요.

"2015 UX 이노베이션 세미나"

부제도 그에 못지 않습니다.

"2015년 눈 여겨  봐야 할 최신 UX 트렌드와 새로운 기회"

UX 디자이너라면 왠지 듣지 않으면 안될 것 같은 제목과 부제입니다. :)


그래서,

성공적인 디지털디자이너를 꿈꾸는 예비 디자이너 및 "대학생"의 자격으로 참여했습니다-

...

는 아니고

...

UX에 매우 관심이 많은 "개발자"의 입장으로 참여했습니다.

따라서 본 포스팅은 개발자가 바라본 UX 세미나의 후기 정도로 보면 됩니다. :)



오전 패널토의 사회는 (전) 야후코리아 대표이사이신 김진수 회장님께서 맡아주셨습니다.

패널 세 분의 의견을 적절히 정리해주시고,

토의의 흐름을 잘 이끌어주셨습니다. :)


패널토의는 "IoT와 UX 변화와 트렌드"를 주제로 토의를 진행하였습니다.

패널 세 분 모두 입담이 좋으셨는데,

고민할 만한 소재를 많이 던져주셔서 전반적으로 만족합니다.


패널 #1 차두원 실장님은,

"IoT와 자동차, 그리고 UX의 진화"를 주제로 발표를 하셨습니다.

자동차연구소에서 근무하신 경력을 토대로,

Uber의 공유플랫폼이나,

대중교통+물류시스템+특화수송체계에 적용될 자율주행플랫폼에 대한 흥미로운 얘기를 들려주셨습니다.


패널#2 박민우 교수님은,

"Wearable UX와 O2O 커머스"에 대한 주제로 발표를 하셨습니다.

'아이디어만 있으면 성공한다?'

'디지털은 아날로그를 대체한다?'

'기존 제품과 시너지가 중요하다?'

위의 문장을 화두로 던지시며,

애플와치의 용두가 선사하는 아날로그 감성에 칭찬을 아끼지 않으셨습니다.


패널#3 김석기 대표님은,

"IoT와 애플워치 그리고 스마트폰의 UX"란 주제로 발표를 진행하셨습니다.

김석기 대표님이 운영하는 블로그 nweb의 기사에서 보던 의견을 육성으로 들을 수 있는 좋은 기회였습니다.

김석기 대표님은 올해 애플워치의 판매량을 2,000만대로 예상하셨는데,

LG 디스플레이의 액정 생산량을 토대로 번스타인보다 정교해 보이는 예상치를 말씀하셨어요 :)

토의 주제로는 나오지 않았지만,

김석기 대표님의 블로그 기사 중,

"모바일 이후의 세상은 어떻게 변화할까"  장애인에 대한 언급을 한 부분은 눈여겨볼만 합니다.


패널 토의 중에 이뤄진 몇 가지 주제가 기억에 남아 아래와 같이 정리합니다.



IoT 기기가 수집한 빅데이터를 이용하여,

자동의사결정시스템이 유효한 판단을 스스로 내려 완결된 동작을 하는 시대가 올 것입니다.


IoT 기기 중 광범위한 지역에서 다양한 층위의 사람들이 사용하는 모바일기기는,

지금 이순간에도 사용자 정보를 수집하고 있는데,

iOS나 안드로이드 플랫폼이 이미 그 부분에서는 '압도적으로' 앞서 나가고 있습니다.

빅데이타를 모아 의미있는 정보를 수집하려는 시도는 다수의 플랫폼에서 진행되겠지만,

진입장벽이 이미 높이 쌓아져 있기 때문에 벽을 넘기란 쉬워보이지 않습니다.


한국에서도 운영체제 플랫폼을 만들기 위한 시도가 계속되고 있긴 하지만,

의미있는 결과물이 도출된 적은 없습니다.


Display는 UX의 가장 중요한 요소 중의 하나죠.

모바일이 First device가 될 수 있었던 이유도,

- 한 손에 들어 이동하기 편하면서

- 완결된 정보를 표현하기에 적합한 사이즈의 접점을 잘 찾아냈기 때문입니다.


Wearable device(특히, 시계)는 화면 사이즈가 작아지긴 했지만,

Second device로서 의미있는 행보를 하고 있습니다.

입출력의 제한을 극복할 수 있다면,

언젠가는 First device로의 지위를 차지할 지도 모르죠.


다양한 방법으로 제한적인 입출력을 극복하려 하고 있지만,

아직까지 소비자의 구미를 100% 채워줄 만한 기술이 개발되진 않았습니다.

정교한 상황인지에 기반한 음성인식이 보다 발전하거나,

파격적인 뇌파인식처럼 완전히 새로운 기술이 개발되기 전까지는 갈 길이 멀어요.


IoT 기기 중 Display가 없는 것도 많습니다.

하지만, 그럼에도 불구하고 Display 없는 기기에,

UX 디자이너가 기여해야하는 바는 적지 않습니다.

기기마다 특성이 있고,

Physical 한 성질이 있기 때문에,

디바이스의 특성과 성질을 UX 디자인으로 버무려야 하는 책임이 있습니다.

물론, 이 디바이스에서 UIFW 개발자가 할 일은 없겠지만...




"배달의 민족"을 예시로 든 플랫폼에 대한 설명도 있었습니다.

'수수료' 장사를 위해,

다수의 공급자와 다수의 소비자를 연결하는 꼭지점에 위치한 플랫폼.


iOS나 안드로이드와 같은 운영체제 플랫폼 뿐만 아니라,

공유경제의 첨병으로 맹활약하고 그에 못지 않은 비난의 화살을 맞고 있는 Uber,

자동운전시스템으로 차세대 교통혁명을 준비하는 구글플랫폼 등

대규모 플랫폼에 대한 흥미로운 설명도 있었습니다.


이러한 플랫폼에 대한 토의가 이뤄지면,

왠지 부끄러워지기도 하고,

사명감에 휩싸이기도 하고,

복잡한 감정이 불쑥불쑥 튀어오르네요.

늘...


한명수 실장님은,

"UX디자이너의 역할과 조직에서의 생존전략"이라는 주제로 발표를 하셨습니다.

회사가 어려워지면 정리해고 1순위로 UX 디자이너가 지목된다는 사실로 담담하게 발표를 시작하셨습니다.

UX 디자이너가 스스로의 역할을 한정 짓는 행위를 경계해야 한다고 일관되게 말씀하셨습니다.

개발에서도 역할분담은 중요하지만,

세분화된 역할을 고수하는 행위가 자신의 입지를 좁히는 결과를 초래하는 것은 마찬가지입니다.


김수 "캡틴 디자이너"께서는,

"린 UX 프로세스에서의 프로토타이핑"을 주제로 발표하셨습니다.


출처 : Wikipedia

우선, 한국기업체에서 흔히 사용하는 Waterfall 개발방식을 간단하게 짚어주셨습니다.

그동안 회사 내에서도 Waterfall 방식에 대한 회의적인 시각이 많아서,

새로운 애자일 방식으로 팀을 변모시키려는 논의가 있었습니다.


하지만, 조직이 크면 클수록 프로세스 변화에 기민하게 움직일 수가 없습니다.

그래서 아직까지 제조업에서나 통용될만한 Waterfall 방식으로 움직이고 있고,

당분간 시스템이 바뀔 것 같아 보이지도 않습니다.


UX 디자이너와 개발자와 사용자의 소통을 막고,

중간 관리자를 양산하는 폭포수 시스템으로는,

기민하게 움직이는 소프트웨어를 찍어내기가 힘들죠.


그리고 폭포수 기법과는 대비되는,

'구글에서 사용하는' Lean 개발방식을 언급하셨습니다.


기획(Think)하고 개발(Make)하고 소비자에 평가(Check) 받는 간단한 단계로 한 사이클을 탑니다.

그리고 연이어 다시 기획, 개발, 평가를 반복합니다.

이러한 단기 사이클을 반복하여 상대적으로 짧은 시간에,

완성도 높은 소프트웨어를 개발할 수 있습니다.


설명을 듣고 있자니,

앱 기획단계에서부터 Lean 개발방식으로 개발하고픈 소망이 생겼습니다.

기획자 1명 + 디자이너 1명 + 개발자 3명 정도의 소파티로,

3개월 정도의 프로젝트 기간으로 '한 입으로 베어물 수 있는 사이즈'의 프로젝트에 참여하고 싶습니다.

되...될까요?


발표 막판에 제법 흥미로운 프로토타이핑 툴을 소개시켜주셨습니다.

김수 대표께서 운영하시는 Studio XID에서,

5월 중순에 close beta 서비스를 할 예정인 툴입니다.

직관적으로 쉽게 사용할 수 있는 툴로 보입니다.

일단 베타테스트 신청 완료-




조성봉 컨설턴트께서는,

"스마트 시대의 UX"라는 제목으로 강의를 진행하셨습니다.

개발자로서 가장 흥미로운 시간이었습니다.

IoT와 관련된 제품들을 하나씩 리뷰도 하시고,

그에 대한 평가도 아끼지 않으셨습니다.

신기능에만 몰입하여 제품을 생산하는 것보다는,

사용자 시나리오를 발굴하는 것이 중요하다는 의견이 인상적이었습니다.

홈페이지도 세련되어 아래에 붙여놓습니다. :)



인상 깊었던 IoT 제품,

구글링이 가능하기에 따로 설명하진 않겠습니다.

- Beon Burglar Deterrent Bulb

- August Smart Lock

- Fizzly Bluetooth Le Motion

- Scubus S

- Sesame


염일수 소장님은,

"제품에서의 UX활용사례와 전망"이란 주제로 강의해주셨습니다.

요즘 잘나간다는 코웨이 디자인처럼,

강의자료도 다른 강의와는 차별되어 보였습니다. :)


수상경력도 화려하시고,

코웨이 스톡옵션도 29,000주나 받으시고,

무엇보다,

제품 디자인만 봐도,

정말 대단하신 분이란게 충분히 전달되었습니다. :)




끝으로...

이번 생에는 개발자로 태어났지만,

그렇다고 다음 생에 디자이너로 태어나고 싶진 않습니다.

그저 재미난 디자인의 제품을 맘놓고 사재기할 수 있는

아랍부호로 태어나고 싶습니다.


끝_

+ Recent posts