에자일 회고: 최고의 팀을 만드는 애자일 기법

최근에 바쁜 일도 끝나고 해서 (아직 논문 실험 데이터 뽑는 일이 남긴 했습니다만 ㅋㅋ) 이 책을 다시 잡았습니다. 제 블로그에 자주 오시는 분은 (계실지 모르겠습니다만) 아시겠습니다만, 잠시 놓고 있었던 "생각하는 프로그래밍"도 다시 읽고 있습니다. 

애자일 회고를 읽으며 한 가지 감탄했던 것은, 회고라는 행위 자체도 Agility의 영역에서 자유롭지 않다는 점이었습니다. 나부군님의 이야기를 한번 읽어보죠. 

[전략] 다만 회고를 진행하는 목적을 잊지 말아야 한다. 팀이 프로세스를 개선하고 같은 문제점을 반복하지 않기 위해서 회고를 진행하는 것임을 잊지 말아야 한다. 회고 자체가 목적이 되어서는 안된다.막연한 기대를 품고 사람들이 모두 지겨워하고 괴로워하는 회고를 억지로 이끌어나가는 팀에게 개선은 매우 힘든 일이 될 것이다. 회고 자체도 개선해야 한다. 뭔가 문제가 있다면, 진행 과정을 더욱 간단하고 쉽게 만들자. 사람들이 최대한 부담을 느끼지 않는 선에서 시작해서 발전해 나가는 방식도 좋다. 처음 회고를 진행하다보면 많은 난관에 부딪힐 수 있다. 이때 회고 자체를 개선할 수 있다는 마음가짐으로 회고에 대한 회고를 반복하다보면 결국 팀이 개선하는 데도 큰 도움이 될 것이다. [후략] (191페이지)

회고를 회고하고 개선한다... 결국 모든 것은 개선의 대상이라는 뜻 되겠습니다. 애자일 지침들에서 가장 마음에 드는 것 중 하나는, "어떤 것도 처음 그 상태로 내버려두지 않는다"는 것입니다. 결국 프로젝트의 목적이란 불확실성을 프로젝트에서 조금씩 덜어나가는 것일 터. 불확실성을 제거하는 것은 좋은 제품을 만드는 데도 도움이 되고, 더 나은 팀을 만드는 데도 도움이 되며, 더 나은 일상생활을 영위하는 데도 도움이 됩니다. (웃음) 어쩌면 프로그래머가 추구해야 할 궁극적인 지점은 바로 그 부분이 아닐까요? 더 나은 삶을 만드는 것.

더 나은 삶을 만들기 위해서는, 단순히 프로그래밍 기술을 뛰어 넘는 어떤 것이 필요합니다.

아마도 여러분은 현재 각자 일하고 있는 분야에서 전문가일 것이다. 하지만 회고를 매끄럽게 진행하는 업무를 하기 위해서는 소프트웨어 분야와는 다른 기술과 시각이 요구된다. 새로운 기술을 연마하는 데는 많은 시간과 연습이 필요하다. 마음의 여유를 가지고, 원하는 바가 무엇인지 잘 정리하고, 스승을 찾아라. 여러분은 자신을 발전시키는 일에도 '조사하고 적용하게 하기'를 사용할 수 있을 것이다. (82페이지)

분명 애자일 프로세스도 기술입니다. 하지만 여태껏 알아왔던 어떤 프로세스도, 프로세스에 참여하는 사람의 삶의 질을 어떻게 향상시킬 것인지에 대해서는 언급하지 않았던 것 같아요. 주로 예측 가능성의 문제에만 집중해 왔죠. 반면 애자일 프로세스는 프로젝트에 참여하는 사람들이 어떻게 협동하면 보다 나은 무엇이 만들어질 수 있는지 자주 이야기합니다. 회고도 그 중 하나예요. 

애자일 프로세스 전반에 큰 관심이 없더라도, 이 책은 한 번 읽어볼 만 하리라고 생각합니다. 회고라는 것은 결국 '과거에 했던 어떤 것'을 돌아보는 행위일텐데, 세상에 과거 따위는 없다고 말하는 프로세스는 없거든요.


출처 : http://www.buggymind.com/124

정부지원 사업 계획서(제안서) 작성 및 발표의 원칙과 전략

정부지원 사업(과제)을 신청할 때는 몇 가지 원칙에 따라 사업계획서와 제안서를 써야 한다. 또한 발표(Presentation)에 있어서도 몇 가지 반드시 염두에 두어야 할 포인트가 있다. 최근 가장 많은 사업이 발주, 공고 되고 있는 R&D 사업과 지역균형발전 관련 사업을 염두에 두고 다음과 같이 계획서(제안서) 작성 및 발표의 원칙과 전략을 제시해 본다.

1. 사업계획서(제안서) 작성의 원칙과 전략

제안내용이 논리적이어야 한다. • 전체 맥락과 흐름이 최대한 논리적이어야 하며 ‘논리의 비약'이 있어서도 안된다. • 시종일관 논리의 일관성이 있어야 한다.(Stick to the Subject) • 사업의 구성요소들 간에도 상호 논리적 연관관계가 짜임새 있게 제시되어야 한다. (예, 장비구축, R&D, 인력양성 등) 차별성을 강조한다. • 제안 요청서에 충실하되, 기존에 진행 중인 사업 및 타 경쟁 제안서와는 내용과 접근 전략에 있어 최대한 차별성이 부각될 수 있도록 한다. • 이는 곧 ‘왜 이 사업(과제)이 반드시 선정되어야 하는가'의 문제로서 이에 대한 명확한 답을 제시할 수 있어야 한다. 가점 구조를 정확히 파악하라. • 지역소재 가점, 민간의 매칭 투자 가점 등 가점의 요소와 가점으로 반영되는 점수는 사업별로 다른 만큼, 최대한 눈여겨 살펴보고 최대한의 득점 포인트를 확보해야 한다. 추진 배경과 목표를 명확히 제시해라. • 무엇을 위한 제안이며 무엇을 하기 위한 것인지를 명확히 제시해야 한다.(먼저 6하 원칙에 따라 간명하게 종합 틀을 제시해라) • 목표가 막연하거나 사업내용에 비해 너무나 ‘원대한 목표'가 제시되어서는 안 된다.(예: 나노기술 개발 사업인데 사업 목표로는 ‘한국의 경제발전과 산업경쟁력 향상'등 제시하는 경우) • 가급적 큰 목표와 당해 사업의 당면 목표를 구분해서 제시하는 것이 좋다. (예를 들어 “어떠어떠한 것을 목표로 하는 사업으로서 궁극으로는 어떠어떠한 국가적 목표에도 기여할 것으로 기대”) 정부의 정책 방향성과의 부합도를 최대한 높여라. • 차세대성장동력, 균형발전, 혁신역량 등 해당 사업과 직간접적으로 관련되는 정부 정책 의 방향성을 정확히 이해하고 이와 합치되는 방향으로 제안서가 작성되어야 한다. • 특히 해당부처 또는 발주기관의 정책적 지향점과 사업의 정책 방향성을 정확히 인식해야 한다. 평가위원이라면 어떤 사업을 선택할 것인지를 명확히 인지하라. • 국가적으로 가장 우수한 곳을 선정하는 것인지 아니면 특정지역 커뮤니티 또는 중소기업 등을 위한 사업을 뽑는 것인지 정확한 포인트를 인식하고 사업내용을 여기에 맞춰야 한다. • 최근 정부 지원 사업은 기술적으로 Best인 과제를 선정하는 것이 아니라 특정 취지와 목적에 가장 잘 부합되는 과제를 뽑는 경우가 점점 많아지고 있다.(수월성만을 강조한 제안서가 늘 모범답안이 되는 것은 아니다.) 기업 및 산업의 현실적 수요를 정확히 반영해라. • 가급적 기업과 산업의 니즈를 설문 또는 방문 조사 등의 방법으로 충분히 파악하고 이를 제안서 내용에 반영한다. • 제안서에 담겨진 사업 내용은 기업 및 산업의 수요와 직접 연계되도록 작성한다. 기술 부분은 영역과 기술내용을 구체적으로 제시하라. • 막연하거나 구체성이 없는 두리 뭉실한 내용을 제시해서는 안 된다. • 구체성을 띠되 너무 기술적이어서 들어도 모를 기술 용어만을 열거해서는 안 된다. 평가위원중의 절반은 해당분야의 전문가가 아닐 수도 있다는 점을 명심해야 한다. 제안 기관의 성격에 맞는 사업 내용을 담고 있어야 한다. • 기업, 대학, 연구기관 등 각 기관별 임무와 성격에 맞는 제안이 이루어져야 한다. • 대학이 제안하면서 기업에서도 할 수 있는 일과 역할을 하겠다고 강조한다면 탈락을 자초하게 된다. 수행기관의 역량을 체계적이고 설득력 있게 제시하라 • 유사 과제를 수행한 적이 있거나 수행 중에 있다는 것은 중복성으로 보면 ‘독'이요, 수행경험으로 보면 ‘득'이 될 수도 있다. 독이 아니라 득이 된다는 포인트를 논리적으로 잘 기술해야 한다. • 수행 인력의 투입비는 적정 수준이 확보되어야 한다. 프로젝트 책임자의 경우 10~20% 내외의 투입만을 한다는 제안서는 스스로 탈락을 자초하게 된다. • 수행기관의 역량을 객관적으로 제시하되 부족한 점이 있어 보이면 강한 의지와 자신감으로 만회해라. 주변 혁신기반들과의 네트워크형 구도를 잘 짜야 한다. • 단순히 어떤 기관과 연계하겠다는 것으로 그쳐서는 안 된다. 어떤 기관들과 어떻게 협력하고 이들 기관들이 가진 리소스를 어떻게 공유할 것인지를 정확히 기술해야 한다. 사업의 기대성과 및 효과는 정성적, 정량적으로 구체화시켜 제시해라. • 막연히 또는 부풀려서 적당히 제시해서는 안 된다. • 가급적 성과지표를 명확히 제시하는 것이 좋다. 자체적인 성과관리 및 변화관리 계획을 제시하라. • 자체 성과관리 및 변화관리의 구체적 지표와 프로세스를 제시하는 것이 좋다. <제안 발표의 요령> 발표 자료는 30~50매가 적합하다. • 가장 이상적인 것은 본문 30매 첨부물 20매가 좋다. • 통상 발표시간은 20분 내외이므로 발표 자료의 본문이 30매를 넘어서면 발표자가 20분 범위 내에서 소화해 내기 어렵다. • 발표 자료에는 반드시 페이지 번호가 매겨져 있어야 한다. 발표자는 내용을 완전히 숙지해야 한다. • 30~50커트의 파워포인트는 완전한 ‘내 것'이 되어야 한다. • 파워포인트의 경우 발표자가 각 커트마다 설명해 나갈 ‘동선'을 사전에 정해보아야 한다. 발표 자료의 목차와 내용을 잡을 때부터 발표자가 직접 참여하는 것이 좋다. • 다른 사람이 정해놓은 목차와 내용은 발표자가 숙지하기가 어렵다. 발표자가 자신의 취향에 맞도록 자료 작성에서부터 참여해야 한다. 발표자 혼자서 진도를 나가서는 안 된다. • 설명하는 페이지가 넘어갈 때는 평가자들이 잘 따라오고 있는지 반드시 살펴라 • 가급적 ‘다음입니다.“ 또는 '7쪽입니다.” 등과 같이 발표자가 어느 페이지를 설명하고 있는지를 반드시 밝혀주어야 한다. 평가자의 마음과 생각, 그리고 의도를 꿰뚫어야 한다. • 발표는 평가자를 위한 것이다. 따라서 발표자의 관점이 아니라 평가자의 관점에서 발표가 이루어져야 한다. • 평가자는 무슨 얘기를 듣고 싶고 무엇을 주로 평가할 것인지 주안점을 가릴 줄 알아야 한다. 발표시간을 균형 있게 배분해야 한다. • 배경과 목표 등 20%, 사업의 구체적 내용 60%, 예산, 인력 및 기타 사항에 20% 정도의 시간을 배분하는 것이 좋다.(배경과 목표 설명에 절반의 시간을 다 써버리는 우를 범하지 말아야 한다.) 평가자와의 질의응답은 최대한 공손한 분위기에서 진행되어야 한다. • 평가자가 부정적이고 비판적 논조의 문제를 제기하더라도 표정과 답변의 어조는 항상 공손하고 편안해야 한다. 마무리 맺음말은 간결하면서도 감동적이어야 한다. • 간단한 몇 마디로 사업내용을 다시 정리하고 사업에 대한 애착과 의지를 보이면서 평가자의 감정에 호소할 수 있는 마무리 언급이 반드시 있어야 한다.

애자일 개발자를 위한 근무 환경

애자일 개발자들이 어떤 형태의 자리에 앉아서 일을 하도록 해야 하느냐, 하는 데 있어서는 별로 이견이 없는 편입니다. Extreme Programming의 사례를 보아도 그렇습니다만, '적극적인 협업이 가능한 형태면 좋다'의 정도인 것 같습니다. 애자일 원칙들이 대개 그렇습니다만, 정형화된 '규칙(regulation)'이 있는 건 아닙니다.

보통 프로그래머들은 협업의 문제를 컴포넌트 인터페이스 레벨에서 사고하는 경향이 있습니다. 너는 네 일을 하고, 나는 내 일을 하는데, 그 두 일이 인터페이스 레벨에서 잘 연동이 되면 만사 OK다 라는 것이죠. 물론 그렇게만 되면 프로젝트 관점에서야 만사 OK일 수도 있겠습니다만(아닐 수도 있습니다) 문제는 그런 식의 관점이 생산성 측면에서 어떠한 이득도 가져다 주지 못한다는 데 있습니다. 생산성을 극대화시키는 것이 목적이라면, 내 일/네 일 관계를 넘어서는 좀 더 기민한 형태의 의사소통이 필요합니다. 

개인적인 경험에 따르면, 이러한 의사소통이 극도로 잘 이루어지는 경우에는 (설사 그 의사소통 형태가 그다지 애자일 적이 아니라고 하더라도) 프로그래머들을 개발 완료 시한 한달을 남겨놓고 소집해서 개발을 시작하더라도 완결된 프로그램을 내 놓을 수가 있었습니다. 물론, 그 중 한 사람은 '프로젝트의 성격과 범위, 그리고 관련 기술에 극도로 능통한 사람이어야 합니다. 모든 의사 소통은 그 '달인'을 통해서 이루어져야 하고, 모든 프로그래머들은 그 한 사람과 자신의 일에 대해서 의논을 해야 합니다.

신적인 의사 소통 모델

이런 식의 의사소통 모델에서는 자리 배치는 그다지 중요하지 않습니다. 모든 사람이 (극단적으로 보자면) 딱 한 사람과 자신의 업무에 대해서 이야기를 하면 되니까요. 다른 사람들과 의사소통을 해야 하는 문제는 '달인' 혼자서 다 처리했습니다. 인터페이스 중재부터 시작해서, 개발 범위의 조정 등등... 각각의 개발자들은 중간의 '달인'이 내린 지침에 따라 개발하되, 자신이 담당한 모듈에 대한 클라이언트 인터페이스는 자신이 개발해서 다른 사람들에게 배포하기만 하면 되었습니다.

하지만 이런 '신적인 의사소통 모델'(중간에 마치 신과도 같은 개발자 한 사람이 떡 버티고 있는 모델)은 쉽게 찾아볼 수 있는 형태는 아닙니다. 이런 신적인 의사소통 모델이 널리 통용될 수 없는 이유는 몇 가지 있습니다. 

(1) 달인이 드물다 
(2) 아무도 달인의 자리에 오려고 하지 않는다.

물론 가장 큰 문제는, 저런 역할을 담당해 줄 달인이 실질적으로는 거의 없다는 점입니다. 그 정도의 권위와 카리스마를 갖춘 사람과 같이 일을 할 수 있다면 정말로 영광이겠습니다만, 그런 드문 기회는 그야말로 드물기 때문에 문제가 됩니다. 설사 그런 사람을 찾을 수 있다고 하더라도, 나중에 프로젝트가 실패하게 되면 그 사람 혼자서 '독박'을 써야 하는데, 아무리 달인이라고 하더라도 그렇게 하려고 할까요?

그렇다면 실제상황에서 써먹을 만한 기민한 형태의 의사소통은 어떻게 해야 가능해지는 걸까요? 어떻게 근무환경을 조성해야 그런 형태의 의사소통이 가능해지는 것일까요?

위의 동영상은 Daum의 제주 GMC 센터의 동영상입니다. 스마트플레이스에 올라왔길래, 참고삼아 링크를 걸어보았습니다. 다른 부분은 논외로 하고, 자리 배치만 한번 눈여겨 보시죠. 팀 내에 있는 모든 사람들이 원형으로 배치되어 등을 지고 일을 하고 있습니다. 뭔가 의논해야 할 일이 생긴다면, 바로 의자를 돌려 관련된 사람들끼리 이야기를 할 수 있는, 그런 구조입니다. 중단기적인 프로젝트를 밀어부치기에는 좋은 구조입니다.

하지만 이런 구조는 "모든 프로그래머는 자신만의 공간을 원하게 마련이다"라는 통상적인 믿음과는 좀 거리가 있습니다. 옆 사람 타이핑 소리까지 다 들릴 정도로 가까운데다, 머리를 조금만 돌리면 옆 사람 모니터까지 다 보이거든요. 물론 Pair Programming을 진행하기에는 아주 이상적인 조건이긴 합니다. 하지만 이런 구조에서 일하는 사람들은 '자신만의 무언가'를 원하게 되는 순간 근무 환경을 떠나야 해요. 근무 환경을 나서면 그 밖에는 근무와는 별 상관이 없는 이질적인 공간이 기다리고 있는데, 사람에 따라서는 그런 이질적인 환경이 사색에 오히려 방해가 될 수도 있습니다. 

그러니 저는 자신만의 공간과 협업을 위한 공간 사이에 어느정도의 논리적/물리적인 구분이 존재하는 것이 바람직하지 않겠는가, 하는 생각이 들어요. 자신의 자리에서 일하다가, 협업이 필요할 때 협업을 위한 공간으로 들어가는. 뭐 그런 구조 말이죠. 다만 그 두 공간을 왔다갔다 하는게 그다지 어렵지는 않아야 합니다.

그런 구조에 대해서는 http://www.talk-with-hani.com/archives/660를 참고해 보시는 것이 좋겠습니다. 다만 관리자 입장에서 보면 모든 개발자들에게 이런 공간을 마련해 줄 만큼 돈이 없다는 게 문제가 될 수도 있겠죠. 또 다른 구체적인 사례도 있는데, http://blog.naver.com/yuzico/130007299724 를 참고하세요. 스토리 카드 보드 등등을 망라하는 재미있는 사례들을 많이 보실 수 있습니다. 자리 배치에 대해서는 그다지 상세히 언급하고 있지는 않습니다.

출처 : http://www.buggymind.com/69