폭포수모델(워터폴)에서 시작하여 애자일이 시작되기 전까지 IT와 관련한 개발방법론및 필요한것들을 정리를 하였으며 이미 성공한팀은 더 휼륭한 방법론과 철학이 존재하겠지만 처음시작하는 개발팀에서 지속가능한 성장하는팀이 되기 위해 무엇을 채택하고 고민할지? 우리만의 방식을 찾는데 도움이 되고자 연관된 아티컬을 정리하였습니다. |
폭포수모델은 형식을갖춘방법이다.
소프트웨어를 개발하는질서 정연하고 체계적인방법이다.
폭포수는 나일강을 따라내려가는 여왕의유람처럼복잡하고장엄한 프로세스이며
수직적인 절차의 제일 하부목표는 성공이며, 규칙이 없는 팀이 처음 적용하기에 도움이될수 있다.
그래서 대개 큰조직에서 소프트웨어를 생산하는데 사용한다.
(또는 비즈니스 모델을 잘 이해하는 쪽이 제일 상부에 있다면, 폭포수모델을 따르는것이 비즈니스성공가능성이 높다.)
한마디로 폭포수모델은 프로젝트의 복잡성과 규모를관리하는하나의방법이다.
- 고약한문제 합당한 해결 책중에....
소프트웨어 개발 중에 고약한 성질을 품은 문제를 만났을 때 그를 합당하게 해결하는 방법을 찾아나가고 있다.
주로 사용되는 폭포수 모델의 개괄적 원리를 설명하면서, 고약한 문제를 해결하는 데 부족함을 보여준다.
폭포수 모델의 변종인 소용돌이 모델 등에 대해서도 살펴보고 있다 나아가 폭포수 모델을 극복하기 위한 프로토타이핑 등 대안적 모델을 정의하고 찾아간다.
애자일 인식의 뿌리가 되는 고서이며 폭포수모델의 문제를 해결하기위해, 폭포수 모델을 이해 해야하는것은 당연하다.
고약한 문제는 해결책이 문제의 공간 안에 있는 문제를 일컫는다. 즉 문제가 완전히 풀려야 비로소 그 문제가
무엇인지 완전히 이해되는 그런 문제다. 반면 그 반대편에는 합당한 문제가 있다. 합당한 문제는 정의할 수 있
고, 이들에 대한 데이터를 수집해서 분석할 수 있으며, 해결책을 낼 수 있는 문제다. 마치 폭포수 모델의 시원한
절차처럼 말이다.
소프트웨어 개발 프로젝트에서 어떤 결과를 내는 데 필요한 정보를 제공하거나 체계화하는 것은 컴퓨터가 중심
인 것처럼 보이지만 사실 사람이 중심에 서 있다. 그리고 태생적으로 야기되는 불확실성의 문제는 그 정형성을
이루는 데 반드시 있어야 하는 객관적이고 명료한 기준을 세우기 어렵게한다.
기술중심/이익중심도 중요하지만, 결국 소프트웨어의 문제를 푸는것은 사람이며 사람을 중심에 놓고
문제를 해결하려는 이야기는 "Wicked Problems Righteous Solution" 30년도 더된 IT고서에서 이야기를 하고있으며
애자일이 생기기전 인식의 뿌리가 되는 내용입니다.
링크 :
소프트웨어 개발에는 반드시 필요한 하위 목표가 있다. 하나의 단계를 성공시키면 배열된 다음 목표를 성공시켜나간다. 이렇게 배열된 맨 마지막 순서가 바로 성공이다.
또한 수행하는 업무를 전문적으로 만들며, 전문적인 롤이 폭포수모델의 단계와 일치한다. 경험정도도 반영되는데 일반적으로 초기에 경험 많은 시니어(착수,요구사항분석)가
참여하고 다음이 중간레벨(분석,설계) 그다음 직원이 코딩,유지보수등의 업무를 수행한다.
폭포수모델역시 초기모델의 단점을 극복하고자 변형되어 소용돌이 모델/점진적 모델/나선형/린(프로토타입)등 다양한 개발모델들이 등장하게 됩니다.
다음은 1950년 애드워즈 데밍이 한 이야기이다.
‘품질향상은 실질비용을 낮춘다’고 말했다. 또한 그는 “생산라인에서 가장 중요한 요소는 소비자다.
소비자를 만족시켜 주는 일이 회사의 모든 사람들이 해결해야 할 최우선 과제이다.
모든 직원들이 자기가 만든 제품의 품질에 대해서 스스로 책임을 지는 품질 책임체제를 구축해야 한다. 기
업의 수익은 제품과 서비스에 만족하고 이를 지속적으로 구매하는 단골고객으로부터 나온다.”라고 말했다.
품질과 관련해서 현재는 당연한 이야기인것처럼 보이지만, 1950대에 위 이야기는 미국에서 무시가되었으며 오히려 일본기업인 도요타,소니,혼다등이 데밍의 이야기를 따르며 제조업에서 미국을 앞지르기 시작했으며 부흥기를 맞게되었다.
일본에서 데밍상이 생겨났으며, 추월당한 미국이 일본을 다시 연구하기 시작한다.
토요타의 간반(看板)방식이나 지도카(自動化), JIT(Just-In-Time), 업무 표준화는 데밍의 품질 이론 속에서 태어난 것이다.
더자세한 이야기 : https://steemit.com/kr/@loum/w
데밍의 품질은 제조업뿐만 아니라 소프트웨어에도 중요하게 적용될수 있는 것으로
제조업에서 큰 변화의 터닝지점이 데밍의 품질이론이였다라고 하면 소프트웨어는 애자일이라고 볼수 있습니다.
그러한 애자일도 데밍의 품질이론에 영향을 받았습니다.
데밍의 14가지 지침 ( 50년전 제조업을 위한 이론으로 애자일 선언의 코어영역에 영향을 주었습니다. 린/칸반등은 애자일보다먼저 데밍품질이론에의해 탄생되었으며 애자일로 부분포함되기도 합니다. )
우리의 시장은 과거와는 달리 변덕스럽고,불확실하며,복잡하고 모호하다
폭포수 모델이 규모를 다루는 방법에 가까웠다고 하면 애자일은 변화를 만들고 변화에 대응하는 능력이며, 불확실하고 급변하는 환경에서 궁극적으로 성공을 거두기 위해 그 환경을 다루는 방법이다.
2001년, 소프트웨어 업계를 주도하는 17인의 리더들이 모여 다음을 선언하였다.
이 말은, 왼쪽에 있는 것들도 가치가 있지만, 우리는 오른쪽에 있는 것들에 더 높은 가치를 둔다는 것이다.
애자일이, 긴민함/민첩함 이란 형용사적 단어적 의미도 있지만, 애자일 선언문의 가치와 원칙을 실천하는 마음가짐이나 방법을 말한다.
애자일의 가장 큰 오해는 스피드로 보여질수 있다란것이다. 스피드보다는 올바른 방향을 찾기위해, 지속적으로 방향성 조정이 가능하다란것이다.
워터폴은 한번 정해지고 개발착수가되면, 그것이 완료될때까지 방향조정이 불가능한것과 비교해야하며 워터폴이 시원한 절차에의해
개발이 완료 되었다라고하면 오히려 워터폴이 스피드할수 있다.
소프트웨어의 복잡성과 변화가 아닌 규모를 관리하는 측면에서는 워터폴이 효율적일수 있습니다.
문제를 팀이 정의를 하고 해결해나가는 힘을 키우는것은 , 개인의 성장과 함께 팀의 수준또한 중요함을 의미합니다.
메타인지와 연관이 있을수 있으며, 탑다운의 정형화된 폭포수모델에서는 대부분의 중요문제는 상위에서만 정의를 하였으며
반대로 이야기하면, 정보가 거의 없을 초기시점 그러니까 우리가 정보를 가장 모르는 초기시기 숙련된 경험자만이
설계단계에서 문제정의를 하였다. 애자일에서는 가장 모르는지점 감으로 문제정의를 모두내리는것에 대한 리스크를 이야기하며
애자일을 하기위해서는 팀구성원 모두가메타인지 능력을 사용해서 지속적인 문제정의와 해결방법을 찾아가야 하며
팀의 공유된 메타인지(shared meta-cognition)라고 부르기도합니다.
소프트웨어가 일반적으로 복잡해지는 이유는, 우리가 사용하는 기술자체의 복잡성 때문이 아니라
우리가 가진 도메인 자체의 복잡성에 기인하며, 도메인을 중심에 놓고 도메인 전문가 까지
모델을 만드는 단계에 참석을 시키는, 개발문화의 변화와 성숙에 대한 도전 과제로이야기가 이어집니다.
DDD가 단순하게 개발팀만 해서 되는것은 아니고, 비즈니스를 잘아는 정확하게는 도메인전문가
사업/영업/사용자 모두를 개발 초기 단계에 참여를 시키는것을 권장합니다.
DDD를 하기위해서는 애자일이 필요하다. 애자일이 좋은 소프트웨어를 만들기위한 가치와 마음가짐을 이야기한다고 하면
DDD는 그것을 실천하기위한 구체적인 전략/전술을 이야기하며 애자일의 코어영역과 상당수 일치한다.
수평적 개발문화를 이해하기위해 애자일의 선언을 다시 살펴보자
애자일 마인드셋과 환경제공을 하는것은 'Being Agile'은 탑다운에서 그것을 실천하는 'Doing Agile' 은 바텀업을통해 균형을 이루어질때 작동됩니다.
수직과 수평개발문화 많은 논란이 있고 아직고 정의되고 있지만, 애자일과 상관없이 그 둘의 균형을 위해 노력하는것 자체를 수평이라고 정의를 내리고 싶습니다.
Beging Agile 은 회사 또는 기존 관리자급에서 고찰을 해야하는 내용입니다.
애자일의 시작은 사실, 실무자뿐만 아니라 권한과 책임을 나눌수 있는 분위기및 함께 학습하는 분위형성이 중요합니다.
전통적인 워터폴에서 사용되었던 관리방식이 완전하게 바뀌어야함을 의미하고 생각보다 많은 변화와 큰 비용이 들수 있습니다.
가령 다음과 같은 고민입니다.
"계획과 기획이 완료되고 변경이 없어야 착수 가능한 개발방법론에서 , 우리에게 필요한것은 무엇일까요?"
Doing Agile은 기존 실무자가 고찰해야하는 내용입니다.
수평적 개발절차를 워라벨(칼퇴보장/워터폴 보다 스트레스가 적은/수평으로인한 편안함)로 생각하면 오해입니다.
오히려 애자일을 너무 열심히 해서 프로덕트를 런칭시킨팀에서 번아웃이 발생할수 있습니다.
수평은 가만히 있어서 유지할수 있는 상태가 아니라, 연필을 손바닥에 세워 떨어트리지 않으려고 계속 균형을 맞추는
사실은 모두의 구성원이 능동적이고 적극적으로 프로젝트에 참여하고 책임을 분산하는 밸런스 게임이며 구성원이 적극적이지 않고 움직이지 않으면 그 수평은 유지될수 없습니다.
> 실리콘밸리의 애자일은, 움직이지 않는다고 판단되면 다음 스프린트에서 기능단위 특정 파트자체가 제외될수 있는 사실은 무서운 수평게임입니다. ( 보안을 위한 접근권한을 막는것을 포함 해고하는데 하루이상 걸리지 않으며 신속 정확합니다. )
다음은 사례는 팀을 운영하는 리더였을때 , 수평과 관련한 인터뷰내용중 FAQ를 요약하였습니다.
"수평적 개발문화가 좋은것 같습니다만~ 제 사수는 어디있나요?"
- 여기서 사수는 군용어로 가장 수직적 단어입니다. 코칭을 해줄 시니어가 존재하지만 당신의 성장을 책임 지지는 않습니다. 그러나 모두의 성장을 위해 함께 노력할수 있는 팀을 빌딩할것입니다.
"프로세스가 없는것 같아요?"
- 공정과 도구보다 개인과 상호작용을 더 중요하게 생각하며 이해와 상호작용을 조금씩 변화에 기여해주십시오, 좋은 개발문화가 정착될수 있도록 환경적 지원을 해드리겠습니다. 상호작용을 통해 변화하는 것이 우리의 가치이며 우리가 워터폴의 한계를 극복하려는 지난 노력들은 아직 완성되지 못했습니다.
"저는 주니어(3년차)이기 때문에 설계에 자신 없으며 이것은 팀리더의 역할또는 책임인것같습니다."
- 설계자와 구현자가 따로있는것은 실천적 해결방법에 멀어질수 있으며, 워터폴을 이해한다고 하면 워터폴의 절차속에 단순하게 코더 역할을 하는것입니다. 우리모두는 아마추어가 아닌 프로가 되어야하며 리더가 이 부분에 도움을 줄수 있지만 모두 대신할수는 없습니다. 프로세스보다는 그 공정에 설계가 없는것에 그리고 그것에 참여를 못하는것에 대한 문제를 저에게 주십시오 필요하면 함께 참여해서 어려운 문제를 같이 풀어갈수 있습니다.
TASK의 핵심은 작업의 완료에 있지 않다는것입니다. 가치를 어떻게 인식하느냐입니다.
우리는 어떤 설계를 하고 있을까? 우리는 설계대신 "작업 보드 셔플" 이라는것을 진행하게되며
할일과 작업중 그리고 완료로 이어지는 작업의 아이템 변화과정을 지식 집약적인 일의 전부로 여기고
나머지는 프로그래머가 소스를 쏟아내기만 하면 된다라고 생각한다.
이는 잘 드러나지도 않고, 존재하지도 않는 설계에 엄청난 비지니스 비용을 쏟아붓는일이다.
좋은 설계의 다음 대안은 나쁜설계이다. 이 문구의 요점은 설계를 절대하지 않는것에대한 이야기이다.
처음부터 좋은 설계를 할수 없으며, 이것이 좋은지,나쁜지 판단할수가 없다.
나쁜설계를 시도하고, 효율적인 설계를 어떻게 할지 설계에대한 고민을 시작하란의미이다.
설계가 없는것은 지식획득이라는 중요한 것을 놓치고 ,큰 진흙 덩어리를 계속 만들어 내게되며
소프트웨어 개발을 이익중심이 아닌 원가 중심으로 생각하는 비지니스 문화가 확고한 경우 설계문화가
생겨날수 없다란것을 경고도 하고 있다. -도메인 주도 설계중에
WBS를 바라보는 관점
wbs 방식이 구식인건 맞는데... 근데 그래도 산업군에 따라 그런 방식이 필요합니다. 고객에 의한 “가치 폭주 현상”이 발생합니다.
피드백을 통해서 자기도 기여한다고 느끼는 고객이 자신의 가치를 가지고 지나친 피드백을 해서 불필요한 품질상태를 만들기도 하니까요.그래서 고객의 피드백을 제동해야할 때가 있습니다.
가치가 어디로 향해야 하는지는 결국 애자일 조직 리더의 몫이니까요.
Quality is value to someone.
- Gerald Weinberg
변경을 허용하지 않는 것은 나쁜 계획이다. - 푸볼릴리우스 시루스
장기 계획은 세우지마라
사업 계획이라는 말 자체가 어불성설이다. 사업추측이라면 또 모를까. 재무계획은 재무 추측으로
전략 계획은 전략 추측으로 바꿔야 옳다. 이렇게 명칭을 바꾸고 나면 얼마나 편한지 모른다.
계획을 세우면 그 계획에 질질 끌려다니지만 , 추측은 기회를 잡기위해 다음과 같이 조정할수도 있다.
"이제 보니가 이쪽이 아니라 저쪽이 맞는군." 때로는 이렇게 되어야한다.
이것이 미래에 대해 생각하지 말라는 말은 아니며 장애물을 어떻게 다룰지 고민을 하라는 이야기다. -REWORK
2018년쯤 VGW 호주 개발사 에서 경험한 내용으로, 국내에서는 경험하지 못한 내용들을 정리 해보았습니다.
최근 스타트업은 실리콘밸리의 개발문화를 학습하여 이제는 공유되고 익숙한 내용일수 있습니다.
- 완성해야할 기획문서가 있는것이 아니라, 구성원 모두가 기획에 참여하며 이 구성원은 모두 도메인주도 개발을 기본으로 지속 학습해야하며 팀리더는 그 수준을 지속 모니터링 합니다. 기획자직군이 별도로 있는것이 아닌 비즈니스 분석가가 그 역할을 하게되지만 플로우를 정리하고 비즈니스 요구사항을 정리하는데 도움을 줍니다.
- 백로그에서 꺼낸 스토리를, BDD와 혼합된 이벤트스토밍을 사용하여 이벤트 발생순서대로 기능을 정의하고 문제정의와 함께 해결방법을 조심씩 완성해 나갑니다. 마지막 단계에서는 QA가 BDD베이스 TC를 작성할수 있을만큼의 텍스트가 정의됩니다. 이것이 완성되면 "Are You Happy?"와 함께 개발시작가능한 Ready To Play로 옮겨 놓습니다. 릴리즈보다 Ready To Play 로 옮겨놓는것에 더 열광을 했던것 같습니다.
- 설계와 함께 스토리포인트 측정이 완료되었다라는것을 의미하며 이 단계로 오지못한 Task는 스프린트 플래닝을 할수 없습니다. ( 러프하게 일정을 잡는것이 허용이 안되며, 스프린트에 포함이 된것 자체가 변동이 안됩니다. )
- 프로덕트 책임이 대부분 이벤트스토밍 초기단계에 참여하여 정책상 중요결정이 필요한경우 빠르게 내려줍니다. 비즈니스 전문가가 대부분 개발자가 아니기때문에 초반단계에서는 개발용어 사용이 금지됩니다. DDD에서는 유비쿼터스 언어라고 불립니다.
- 미팅문화는 모두가 균등하게 발언하고 이해하는 방향으로 진행되며, 침묵을 하게 되면 이해를 못하거나 이사람은 이 미팅의 주제에 필요없는 사람이라고 간주합니다. 하지만 발언을 하지 않고 대부분의 파편화된 미팅에 듣기모드로만 참석하는 딤간 정보를 취합하고 공유하는 전문가가 존재합니다.
- 브랜치 개발팀은 현재 해체되었지만 호주메인 개발팀과 한국 브랜치 개발팀이 있었으며, 주기적으로 크로스 방문을 합니다. 단순하게 방문하는 것이아닌 상대팀 스프린트에 직접참여하기위해 스프린트 참여 계획을 포함하여 방문합니다.
- 디자이너가 단순하게 디자인만 관여하는것이 아닌, 도메인 미팅 초기에 참여하고 기여도 하며 UX를 포함 프로덕트를 만들어가는데 기여를 합니다.
도메인 발견 가속화도구 - 이때 경험하고 배운것은 다시 정리하고 재 정리하였습니다.
스포티파이 모델은 애자일의 교과서 처럼 회사이름 자체가 애자일 모델이 된 케이스입니다.
Spotify는 세계에서 가장 크고 가장 인기 있는 오디오 스트리밍 구독 서비스로 약 2억 8600백만 명의 사용자를 보유하고 있습니다.
Spotify 성공의 핵심은 팀 애자일을 향상시키기 위해 업무를 조직하는 회사의 고유한 접근 방식에서 주도합니다.
Spotify의 엔지니어링 팀은 애자일 향상을 향해 나아가는 과정에서 경험을 문서화하여 전 세계와 공유했으며 궁극적으로 많은 기술 기업이 업무를 조직하는 방식에 영향을 미쳤습니다.
이것이 현재 Spotify 모델로 알려져 있습니다.
하지만 과거 성공한 모델이라고 할지라도 환경과 규모는 지속적으로 변하며 개선해야할 사항이 있을수 있습니다.
"내가 스포티파이에서 딱 하나만 고치고 싶었던 걸 고르라면, 자율성을 너무 강조하지 않았어야 한다는 것." - 스포티파이의 Agile Coach였던 Joakim Sunden
좋은 팀은 구성원이 계속 변경되어 새로운것을 시도하는것이 아닌 오래가는 숙련된팀입니다.
오래가는 팀은 스스로 좋은 팀문화를 만들 가능성이 있으며, 구성원은 그 과정에서 성장을 하게됩니다.
팀의 구성원도 결국 회사의 직원이며, 디지털 트랜스포머가 급격하게 증가하기 시작한 전후로
오너쉽(직장충성)을 직원에게 강조하는 시대가 변화하고 있습니다.
직장충성의 반대편에 있는 용어가 , 워라벨은 아닐것입니다.
모두가 동의할수 없지만, 오너쉽(직장충성)의 반대편에 있는 용어는 직원에게 좋은 경험을 줘야한다는 컨셉인 직원경험입니다.
위 두가지가 있을때 무엇을 선택할것인가? 당연히 후자쪽일것이다. 애자일 도입으로 성공한 기업의 케이스도 많지만. 실패하는 기업의 케이스도 꽤 있다.(실패는 알려지지 않기때문에)
우리만의 변종된 워터폴을 만들어가는것도 좋은 대안이 될수 있으며 애자일과 같은 개발방법또는 프로세스에 얽매이지 않는 Shape UP의 방식을 살펴보는것도 도움이 될수 있을것 같습니다.
과거 몇년간 어떻게 작은 팀으로, 높은 품질의 소프트웨어를 그렇게 빨리 개발해내는지 물어보곤 했다. 또, 개발자들을 오랫동안 유지하는지도.
우리는 우리의 길을 만들었다. - 이 방식을 무작정 따라하는것이 아닌 참고하여 자신만의 방식을 만들라란 의미로 해석하고 있습니다)
Shape UP - 개인해석본 정리
개발방법론과 프로세스등이 규모와 환경 그리고 품질등을 종합적으로 다루는