바로 이전 포스팅에서 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분 정도 간단하게 진행하고,

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

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


- 실수의 인정

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

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

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

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

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

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

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

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


- 버그유발자 색출금지

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

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

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

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

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


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

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

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


그럼 좋은 하루 보내세요~

끝_


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

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

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

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

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


계획을 수립하는 순간,

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

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


http://agilemanifesto.org/


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

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

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


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


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

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

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


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

- 개인과 상호작용

- 소프트웨어 자체

- 고객과 협력

- 변화에 대응

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


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

- 공정과 도구

- 문서

- 계약협상

- 계획

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

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

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


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

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

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

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


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

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

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

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


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

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

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

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

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

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

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

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

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


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

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

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

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

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

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


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

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

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

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

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

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


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

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

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

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

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

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

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


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

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

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

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

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

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

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


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

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

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

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

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

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

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


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

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

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


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

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


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

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

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


끝_

+ Recent posts