2015.05.13

'실패다!' 애자일 프로젝트의 위험 신호 40가지

David Taber | CIO

애자일 프로젝트에는 생산성과 효율성이 뛰어난 정예요원들이 대거 참여하기 마련이다. 하지만 프로젝트에 실패하지 않으려면 그런 사람들을 신중하게 뽑아야 할 것이다.


이미지 출처 : Thinkstock

애자일 프로젝트에는 긴밀한 협업과 매우 빠른 피드백이 필요하다. 이 프로젝트가 잘 진행될 때에는 사용자의 기대치 프로젝트 결과물과 근접하게 부합되고, 비즈니스에 전혀 영향을 미치지 않아 완벽할 뿐 아니라 시간도 낭비하지 않게 된다. 애자일 프로젝트가 제대로 완성되면, 경제적인 이익까지도 얻을 수 있다.

하지만 애자일 프로젝트의 생산성은 보통 팀 구성원의 능력에 달려 있다. 여기에는 높은 IQ, 높은 EQ, 그리고 고도의 집중력이 필요하다. 전문성, 추진력, 의사결정 권한이 불충분한 누군가가 팀에 있으면 나머지 사람이 그의 뒤치다꺼리를 하게 된다. 게다가 애자일 프로젝트는 인력과 업무 사이의 정확한 매칭이 중요하다. 만약 팀 구성원이 신경 쓰지 않거나 다른 팀 구성원과 한 방에서 같이 일하지 못한다면 한 마디로 긴밀한 협업은 불가능하다.

애자일이 유연성과 빠른 반복 수행에 달려있는 만큼, 문제 있는 사람을 찾고 고치기 위해 최대한 일찍 그리고 자주 애자일 팀원들과 접촉해야 한다. 팀 할당에서 문제가 있으면 일찍 터뜨리는 게 최선의 방법이다.

젠(Zen) 마스터의 “하나를 하는 것을 보면 나머지를 어떻게 하는지 알 수 있다”는 말처럼, 첫 작업이 완료되기 앞서서 팀 멤버십을 파악해내야 한다. 이상적인 것은 첫 작업이 완료되기 이전에 할 수 있으면 더 좋긴 한다. 하지만 현실적으로는 어렵다.

사용자ㆍ개발자ㆍ컨설턴트ㆍ관리자의 문제
성격에 결함을 가진 사람에게 장점이 있다면 이들은 스스로 자신의 결함에 대해 잘 모른다는 것이다. 그리고 그런 점을 그대로 드러내곤 한다. 애자일 팀은 단지 어느 부분을 살펴봐야 하는 지만 파악하면 된다. 대부분의 애자일 팀에서 확인이 필요한 4가지 부분이 있는데 바로 사용자, 개발자, 컨설턴트, 관리자다. 다음은 애자일 팀의 입장에서 비상 상황이라고 할 수 있는 40가지 문제를 사용자, 개발자, 컨설턴트, 관리자를 기준으로 정리해놓은 것이다. (순서와 중요도는 무관하다)

사용자가…
• 참여도, 관심도, 동기 수준이 낮고, 깊이 관여해야 하는 일상적인 업무로 너무 바쁘다.

• 문제, 조치 항목, 데드라인을 맡기 꺼리고, 어느 무엇에도 (특히 요건, 확인, 테스트 스크립트) 자신들의 이름을 올리고 싶어하지 않는다.

• 위험, 변화, 학습을 요소가 아닌 문제로 인식한다.

• 조치 항목과 데드라인을 두기 싫어하고, 마무리도 질색한다.

• 남을 비난하고 책임을 전가하는 모습을 보인다.

• 자신들이 원하는 것은 노골적으로 이야기하지만 클라우드 컴퓨팅 현실에는 무지하고, 부가적인 요청을 가볍게 생각한다.

• 대부분의 결정에 지연과 애매모호함을 더하는 듯 보이고, 바로 본론으로 들어가기 싫어하며, 단순한 해답을 꺼린다.

• 결론이 없는 대화로 회의를 채우고, 명확히 제기된 문제를 부풀려 터무니 없이 큰 문제로 확대시켜 버린다.

• 완벽하지 않은 정보로 행동을 취하기 싫어하고, 언제나 위험을 회피한다.

• 주의력이 없거나 중요한 그 어떤 것도 읽고 쓰는 능력이 없다.




2015.05.13

'실패다!' 애자일 프로젝트의 위험 신호 40가지

David Taber | CIO

애자일 프로젝트에는 생산성과 효율성이 뛰어난 정예요원들이 대거 참여하기 마련이다. 하지만 프로젝트에 실패하지 않으려면 그런 사람들을 신중하게 뽑아야 할 것이다.


이미지 출처 : Thinkstock

애자일 프로젝트에는 긴밀한 협업과 매우 빠른 피드백이 필요하다. 이 프로젝트가 잘 진행될 때에는 사용자의 기대치 프로젝트 결과물과 근접하게 부합되고, 비즈니스에 전혀 영향을 미치지 않아 완벽할 뿐 아니라 시간도 낭비하지 않게 된다. 애자일 프로젝트가 제대로 완성되면, 경제적인 이익까지도 얻을 수 있다.

하지만 애자일 프로젝트의 생산성은 보통 팀 구성원의 능력에 달려 있다. 여기에는 높은 IQ, 높은 EQ, 그리고 고도의 집중력이 필요하다. 전문성, 추진력, 의사결정 권한이 불충분한 누군가가 팀에 있으면 나머지 사람이 그의 뒤치다꺼리를 하게 된다. 게다가 애자일 프로젝트는 인력과 업무 사이의 정확한 매칭이 중요하다. 만약 팀 구성원이 신경 쓰지 않거나 다른 팀 구성원과 한 방에서 같이 일하지 못한다면 한 마디로 긴밀한 협업은 불가능하다.

애자일이 유연성과 빠른 반복 수행에 달려있는 만큼, 문제 있는 사람을 찾고 고치기 위해 최대한 일찍 그리고 자주 애자일 팀원들과 접촉해야 한다. 팀 할당에서 문제가 있으면 일찍 터뜨리는 게 최선의 방법이다.

젠(Zen) 마스터의 “하나를 하는 것을 보면 나머지를 어떻게 하는지 알 수 있다”는 말처럼, 첫 작업이 완료되기 앞서서 팀 멤버십을 파악해내야 한다. 이상적인 것은 첫 작업이 완료되기 이전에 할 수 있으면 더 좋긴 한다. 하지만 현실적으로는 어렵다.

사용자ㆍ개발자ㆍ컨설턴트ㆍ관리자의 문제
성격에 결함을 가진 사람에게 장점이 있다면 이들은 스스로 자신의 결함에 대해 잘 모른다는 것이다. 그리고 그런 점을 그대로 드러내곤 한다. 애자일 팀은 단지 어느 부분을 살펴봐야 하는 지만 파악하면 된다. 대부분의 애자일 팀에서 확인이 필요한 4가지 부분이 있는데 바로 사용자, 개발자, 컨설턴트, 관리자다. 다음은 애자일 팀의 입장에서 비상 상황이라고 할 수 있는 40가지 문제를 사용자, 개발자, 컨설턴트, 관리자를 기준으로 정리해놓은 것이다. (순서와 중요도는 무관하다)

사용자가…
• 참여도, 관심도, 동기 수준이 낮고, 깊이 관여해야 하는 일상적인 업무로 너무 바쁘다.

• 문제, 조치 항목, 데드라인을 맡기 꺼리고, 어느 무엇에도 (특히 요건, 확인, 테스트 스크립트) 자신들의 이름을 올리고 싶어하지 않는다.

• 위험, 변화, 학습을 요소가 아닌 문제로 인식한다.

• 조치 항목과 데드라인을 두기 싫어하고, 마무리도 질색한다.

• 남을 비난하고 책임을 전가하는 모습을 보인다.

• 자신들이 원하는 것은 노골적으로 이야기하지만 클라우드 컴퓨팅 현실에는 무지하고, 부가적인 요청을 가볍게 생각한다.

• 대부분의 결정에 지연과 애매모호함을 더하는 듯 보이고, 바로 본론으로 들어가기 싫어하며, 단순한 해답을 꺼린다.

• 결론이 없는 대화로 회의를 채우고, 명확히 제기된 문제를 부풀려 터무니 없이 큰 문제로 확대시켜 버린다.

• 완벽하지 않은 정보로 행동을 취하기 싫어하고, 언제나 위험을 회피한다.

• 주의력이 없거나 중요한 그 어떤 것도 읽고 쓰는 능력이 없다.


X