si와 agile방법론의 잘못된 적용 양상에 대해 긁적여 보겠습니다.
si환경은 책과 블로그에서 언급되는 이상적인 소규모 환경과는 거리가 멉니다.
개인-개인의 케이스와 서로의 목적을 가진 조직-조직이란 점에서 가장 큰 차이가 있죠.
대규모에 다양한 이해가 얽혀있을 뿐만 아니라 변화와 위기가 반복되는 환경에 처해 있습니다.
특히 대부분의 SI프로젝트는 시작 이전에 불충분한 일정과 리소스란 위험을 떠안고 시작합니다.
물론 고객도 이런 내용들을 인지하고 성공에 대한 의심으로부터 고객과 수행팀의 관계는 시작됩니다.
고객이 원하는 것을 제공하면 우리모두 해피엔딩이라는 것은 SI환경에서 꽤 드문케이스중 하나입니다.
이와같이 대규모 SI프로젝트는 agile practice에서 언급하고 있는
많은 원리가 그대로 통용되기 어려운 환경이라는 것을 명확히 인지해야 합니다.
조직간 이해관계를 배제하고도 순수하게 SDLC관점만으로도 규모와 복잡도에 맞는 방법을 택해야 합니다.
[Don't manage by magazine]
막연하게 책과 대가, 유명인의 말을 인용하며
agile practice에 대한 신뢰를 획득하려는 경우가 많습니다.
그리고 실패요인은 '타성에 젖은 고객', '무지한 팀원', '척박한 현실'탓으로 고스란히 돌아갑니다.
그러한 문제요소를 알고있다면 실패할 확률이 높은 것은 처음부터 선택치 않는 것이 최선이 아닐까요?
오히려 수행방법에 대한 부정적인 분위기와 부정적인 결과를 야기시킬 뿐입니다.
이런 상황에 맞는 말이 있습니다. Don’t “manage by magazine.”
자신의 주관에 의한 확신으로 환경, 배경, 해결방법을 선택하는 것이
막연한 best practice 따라하기보다 훨씬 성공확률이 높다는 것을 꼬집는 말이죠.
[부족한 계획과 회고]
계획과 회고에 대해 부정적이거나 매우 부족합니다.
기존 방법론에서 계획수립, 반복평가, 다음계획수립은 가장 중요한 활동이였습니다.
현재 '회고'라 불리우는 공식적인 행위는 거의 무관심 대상 그 자체였습니다.
많은 경험이 있어도 전략과 실행, 결과, 현황에 대해 자주 통찰하지 않으면
계획과 성공을 위한 실행에 번번히 구멍이 생기게 되고 감당하기 힘든 실패비용이 됩니다.
회고란 si에서 더욱더 중요하겠죠. 항상 위기에 직면해 있고 이해관계와 환경이 자주 바뀌기 때문이죠.
이러한 분위기도 “manage by magazine” 으로 주목받지 못해서 소흘했던 것일 수도 있겠습니다.
계획, 측정, 모니터링, 회고는 수행영역 방향성과 효율성에 제약이 되지 않는 범위에서 가장 집중해야 하는 부분입니다.
[부족한 선행디자인과 디자인 전략]
agile에서 설계를 하지말라 얘기한적 없습니다.
오히려 적절한 선행디자인을 추천하고 있습니다.
amdd에서는 initial modeling을 별도용어와 단계로 구분합니다만 선행설계도 꺼려지는 분위기입니다.
리팩토링이나 tdd가 강조되면서 모델링의 훌륭함 마저 '쓸모없는 전통적 방법'으로 묻힌 느낌입니다.
선행디자인은 적은 리소스로
사전에 전략을 수립하고 확인하는 과정을 가지게 함으로써
큰 위험과 이슈를 사전에 발견하고 해결할 수 있도록 돕습니다.
이는 하부에서 단계적으로 breakthrough(한단계 나아가는 깨달음)를 통해
개선을 반복하는 비용보다 훨씬 저렴하고 합리적입니다.
때때로 프로젝트 상황상 또는 위험비용이 높다면 무겁게 갈 수도 있습니다.
이유없는 BUDF(Big Design Up Front)나 목적이 결여된 복잡한 Notation과
고정된 품질을 위한 형식과 수준준수를 위해 의해 수행되는 모델링만 아니면 됩니다.
[실패에 대한 위험과 의혹]
적은 비용으로 이른 실패를 통한
직접적이고 구체적인 개선안 도출은 바람직하지만,
한계비용을 넘어서는 실패에도 두려움없이 무덤덤해서는 안됩니다.
물론 의도적으로 단기에 실패하는 과정을 만들어 계획에 포함시키고
그것으로 부터 계획과 수행전략을 조정하고 개선하는 방식도 있고
대규모 SI에서 방법론 수행 시 저도 종종 사용하고 효과를 보는 방법입니다만
실패를 통한 개선을 노리는 것은 상당한 위험부담이 있습니다. 생각과 달리 그대로 무너질 수 있습니다.
허용한도 비용을 확대할 수 있는 여지가 있다거나 고정할 수 있는 장치를 고안한 이후에
실패로 부터 성공을 유도하는 방법은 차선으로 택하는 것이 바람직합니다.
또 의도한 실패인지 혹은 얘기치 않은 실패인지는 조직내에서 공유되어야 합니다.
'의도한 실패입니다.'와 같이 activity 문제 방어용으로 사용되다가는 신뢰를 잃기 마련입니다.
신뢰상실 => 비협조 => 끝난 프로젝트
p.s 제가 본 agile관련 책들 중 최고봉은 두말할 나위없이
'planning extreme programming'입니다. 근데 안팔리더군요. OTL
kent beck이나 martin fowler의 싸인으로 인정받고 불티나는 책과 달리 이 책은 직접 쓴 책인데..
planning xp는 2000년 초판부터 user story에 대해 언급하고 통찰을 제공했는데 왜 안팔렸을까요..
user story는 불티나게 팔리는 것 같던데 말이죠.
국내 agile practice 유행에 어떤 패턴이 있는게 그 이유가 싶습니다. '..by maggazine'처럼요.
(계속..)
si환경은 책과 블로그에서 언급되는 이상적인 소규모 환경과는 거리가 멉니다.
개인-개인의 케이스와 서로의 목적을 가진 조직-조직이란 점에서 가장 큰 차이가 있죠.
대규모에 다양한 이해가 얽혀있을 뿐만 아니라 변화와 위기가 반복되는 환경에 처해 있습니다.
특히 대부분의 SI프로젝트는 시작 이전에 불충분한 일정과 리소스란 위험을 떠안고 시작합니다.
물론 고객도 이런 내용들을 인지하고 성공에 대한 의심으로부터 고객과 수행팀의 관계는 시작됩니다.
고객이 원하는 것을 제공하면 우리모두 해피엔딩이라는 것은 SI환경에서 꽤 드문케이스중 하나입니다.
이와같이 대규모 SI프로젝트는 agile practice에서 언급하고 있는
많은 원리가 그대로 통용되기 어려운 환경이라는 것을 명확히 인지해야 합니다.
조직간 이해관계를 배제하고도 순수하게 SDLC관점만으로도 규모와 복잡도에 맞는 방법을 택해야 합니다.
규모와 복잡도에 맞는 방법론과 practice선택에 관련된 자료는 꽤 많습니다.
Alistrair Cockburn과 Scott Ambler 가 쓴 글들을 참조해보시기 바랍니다.
[Don't manage by magazine]
막연하게 책과 대가, 유명인의 말을 인용하며
agile practice에 대한 신뢰를 획득하려는 경우가 많습니다.
그리고 실패요인은 '타성에 젖은 고객', '무지한 팀원', '척박한 현실'탓으로 고스란히 돌아갑니다.
그러한 문제요소를 알고있다면 실패할 확률이 높은 것은 처음부터 선택치 않는 것이 최선이 아닐까요?
실패를 감안하고도 특정한 방법을 택한다는 것은막연히 신앙과도 같은 반복되는 읊조림과 인용은 신뢰를 주지 못합니다.
본인이 목표보다 방법을 우선한다는 것을 인지하지 못하는 것입니다.
오히려 수행방법에 대한 부정적인 분위기와 부정적인 결과를 야기시킬 뿐입니다.
이런 상황에 맞는 말이 있습니다. Don’t “manage by magazine.”
자신의 주관에 의한 확신으로 환경, 배경, 해결방법을 선택하는 것이
막연한 best practice 따라하기보다 훨씬 성공확률이 높다는 것을 꼬집는 말이죠.
[부족한 계획과 회고]
계획과 회고에 대해 부정적이거나 매우 부족합니다.
기존 방법론에서 계획수립, 반복평가, 다음계획수립은 가장 중요한 활동이였습니다.
회고와 형식은 다르지만 1~3일 동안 공식적으로 반복평가 행사를 하는 경우도 있습니다.하지만 agile retrospectives가 출판되기 전에 메일링 리스트나 블로그에서
현재 '회고'라 불리우는 공식적인 행위는 거의 무관심 대상 그 자체였습니다.
많은 경험이 있어도 전략과 실행, 결과, 현황에 대해 자주 통찰하지 않으면
계획과 성공을 위한 실행에 번번히 구멍이 생기게 되고 감당하기 힘든 실패비용이 됩니다.
회고란 si에서 더욱더 중요하겠죠. 항상 위기에 직면해 있고 이해관계와 환경이 자주 바뀌기 때문이죠.
이러한 분위기도 “manage by magazine” 으로 주목받지 못해서 소흘했던 것일 수도 있겠습니다.
계획, 측정, 모니터링, 회고는 수행영역 방향성과 효율성에 제약이 되지 않는 범위에서 가장 집중해야 하는 부분입니다.
[부족한 선행디자인과 디자인 전략]
agile에서 설계를 하지말라 얘기한적 없습니다.
오히려 적절한 선행디자인을 추천하고 있습니다.
amdd에서는 initial modeling을 별도용어와 단계로 구분합니다만 선행설계도 꺼려지는 분위기입니다.
리팩토링이나 tdd가 강조되면서 모델링의 훌륭함 마저 '쓸모없는 전통적 방법'으로 묻힌 느낌입니다.
선행디자인은 적은 리소스로
사전에 전략을 수립하고 확인하는 과정을 가지게 함으로써
큰 위험과 이슈를 사전에 발견하고 해결할 수 있도록 돕습니다.
이는 하부에서 단계적으로 breakthrough(한단계 나아가는 깨달음)를 통해
개선을 반복하는 비용보다 훨씬 저렴하고 합리적입니다.
가령.. 대규모 금융SI에서 선행설계없이 user story로 시작했다고 가정해보겠습니다.그리고 선행설계를 반드시 가볍게 하는 것만이 답은 아닙니다.
업무분류와 기능제공 책임에 대한 전략이 정제되려면 얼마나 많은 비용이 소요될까요?
서로에게 선물해 준 혼란속에서 breakthrough를 반복하며
적은 비용으로 올바른 방향으로 개선한다는 것은 절대로 쉽지 않습니다.
때때로 프로젝트 상황상 또는 위험비용이 높다면 무겁게 갈 수도 있습니다.
이유없는 BUDF(Big Design Up Front)나 목적이 결여된 복잡한 Notation과
고정된 품질을 위한 형식과 수준준수를 위해 의해 수행되는 모델링만 아니면 됩니다.
[실패에 대한 위험과 의혹]
적은 비용으로 이른 실패를 통한
직접적이고 구체적인 개선안 도출은 바람직하지만,
한계비용을 넘어서는 실패에도 두려움없이 무덤덤해서는 안됩니다.
특히나 SI 프로젝트에서 이를 감내하기란 어려운 일입니다.
up에 비즈니스케이스라는 것이 언급되어 있습니다. 비용에 대한 위험을 관찰해야 한다는 것이죠.
실패를 통한 자연스러운 진화.. 라는 것은
실패비용에 대한 투자가 선행될 수 있고 위험비용이 감수되는 조직의 경우입니다.
간단히 예를 들어볼까요. 200명이 3개월간 실수한 것은 40억정도의 손실입니다.
진화할 수 있고없고 여부를 떠나서 당장 하청업체가 계약손실을 감내할 수 있을까요?
물론 의도적으로 단기에 실패하는 과정을 만들어 계획에 포함시키고
그것으로 부터 계획과 수행전략을 조정하고 개선하는 방식도 있고
대규모 SI에서 방법론 수행 시 저도 종종 사용하고 효과를 보는 방법입니다만
실패를 통한 개선을 노리는 것은 상당한 위험부담이 있습니다. 생각과 달리 그대로 무너질 수 있습니다.
프로젝트가 실패하는 것이 목적인 부정적인 그룹도 프로젝트 내에 엄연히 존재합니다.따라서 철저히 안정성을 우선 고려하여
허용한도 비용을 확대할 수 있는 여지가 있다거나 고정할 수 있는 장치를 고안한 이후에
실패로 부터 성공을 유도하는 방법은 차선으로 택하는 것이 바람직합니다.
또 의도한 실패인지 혹은 얘기치 않은 실패인지는 조직내에서 공유되어야 합니다.
'의도한 실패입니다.'와 같이 activity 문제 방어용으로 사용되다가는 신뢰를 잃기 마련입니다.
신뢰상실 => 비협조 => 끝난 프로젝트
p.s 제가 본 agile관련 책들 중 최고봉은 두말할 나위없이
'planning extreme programming'입니다. 근데 안팔리더군요. OTL
kent beck이나 martin fowler의 싸인으로 인정받고 불티나는 책과 달리 이 책은 직접 쓴 책인데..
planning xp는 2000년 초판부터 user story에 대해 언급하고 통찰을 제공했는데 왜 안팔렸을까요..
user story는 불티나게 팔리는 것 같던데 말이죠.
국내 agile practice 유행에 어떤 패턴이 있는게 그 이유가 싶습니다. '..by maggazine'처럼요.
(계속..)
덧글