폭포수모델(워터폴)에서 시작하여 애자일까지 다양한 IT와 관련한 개발방법론및 필요한것들을 정리를 하였으며 이미 성공한팀은 더 휼륭한 방법론과 철학이 존재하겠지만 처음시작하는 개발팀에서 우리의 수준은 어디까지이고?, 무엇을 채택하면 될지? 참고또는 도움되었으면 좋겠습니다. |
폭포수모델은 형식을갖춘방법이다.
소프트웨어를 개발하는질서 정연하고 체계적인방법이다.
폭포수는 나일강을 따라내려가는 여왕의유람처럼복잡하고장엄한 프로세스이며
수직적인 절차의 제일 하부목표는 성공이며, 규칙이 없는 팀이 처음 적용하기에 도움이될수 있다.
그래서 대개 큰조직에서 소프트웨어를 생산하는데 사용한다.
(또는 비즈니스 모델을 잘 이해하는 쪽이 제일 상부에 있다면, 폭포수모델을 따르는것이 비즈니스성공가능성이 높다.)
한마디로 폭포수모델은 프로젝트의 복잡성과 규모를관리하는하나의방법이다.
- 고약한문제 합당한 해결 책중에....
폭포수모델을 이해할때, 대기업 SI프로젝트를 진행하면 따르는 개발모델이기때문에
SI의 부정적인점과 함께, 폭포수모델을 언급하는경우가 많지만 폭포수 모델은 ,과거(최근까지도)에 성공했던 IT기업들이 성공했던 가장많이 사용한 방식입니다.
SI와 폭포수모델을 분리해서 이해할필요가 있습니다.
윈도우가 나오기 이전 일반인들에게 IT는, 어떤 기능을 가진 컴퓨터(하드웨어)를 사는 것이었습니다. 그런데 PC는 조립이 간단했지만 기업용 서버는 설치 환경까지 고려해야 하기 때문에 복잡했습니다.
그래서 시스템 통합(System Integration)이란 분야가 등장했습니다. 즉 SI는 초기에 사용자가 요구하는 기능을 가진 하드웨어를 만들어 판매하는 행위였습니다.
업체들은 사용자가 원하는 기능을 만들기 위해 솔루션이나 패키지를 설치하고 필요한 기능을 직접 개발하기도 했습니다. 그런데 하드웨어가 발전화되면서 표준화되고 소프트웨어의 비중이 커지게 되자SI는 자연스레 소프트웨어 개발 아웃소싱을 지칭하는 말이 되어버렸습니다. 초창기 SI시장은 대부분 수작업을 전산화하는 경우로 ‘불확실성’이 적었습니다. ‘주민등록 관련 업무’나 ‘회계 업무’ 등을 생각하시면 됩니다.
오랫동안 반복적으로 해왔던 업무이므로 기성품을 선택하거나 기능을 새로 만들기도 어렵지 않았습니다. 그리고 납품되고 나면 소프트웨어 변경이 거의 필요없었습니다.
이후 IT가 발달하자 온라인 비즈니스가 중심에 서기 시작했습니다.
기존에 없었던 새로운 일들을 바로 시스템으로 만들게 됩니다. 어떤 비즈니스는 매일 변화가 필요합니다. 인터넷 쇼핑몰, 인터넷 뉴스 서비스, 인터넷 뱅킹 서비스 등을 생각하시면 됩니다.
그래서 이 시스템들은 매번 개발자들의 손이 필요합니다. 사업 환경이 수시로 변하다보니 ‘설계 후 개발’을 하는 것도 어려워 졌습니다. 또한 개발이 완료되어도 종료라고 보기 힘들어졌습니다. ‘불확실성’이 높아진 것입니다.
소프트웨어 개발에는 반드시 필요한 하위 목표가 있다. 하나의 단계를 성공시키면
배열된 다음 목표를 성공시켜나간다. 이렇게 배열된 맨 마지막 순서가 바로 성공이다.
또한 수행하는 업무를 전문적으로 만들며, 전문적인 롤이 폭포수모델의 단계와
일치한다. 경험정도도 반영되는데 일반적으로 초기에 경험많은 고참(착수,요구사항분석)이
참여하고 다음이 중간레벨(분석,설계) 그다음 직원이 코딩,유지보수등의 업무를 수행한다.
상위 절차가 중요며 일반적으로, IT직군은 다음 역활을 수행한다.
규모에따라 PM+기획 / 설계+구현 동일 사람일수 있지만 절차적인 흐름에는 큰 변화가 없으며 직군이 분리됨에 따라 더 세분화될수 있습니다.
규모에따라 폭포수의 단계가 축소될수 있지만, 설계가 없는것은 개발 프로세스가 없다라고 보면되겠습니다.
폭포수모델역시 초기모델의 단점을 극복하고자 변형되어 소용돌이 모델/점진적 모델/나선형등 다양한 개발모델들이 등장하지만
애자일이란 큰 변화가 발생하지만, 폭포수모델의 단점을 극복하려는 수많은 개발모델들은 애자일의 기원으로 볼수 있습니다.
2001년, 소프트웨어 업계를 주도하는 17인의 리더들이 모여 다음을 선언하였다.
애자일이, 긴민함/민첩함 이란 형용사적 단어적 의미가 아닌, 애자일 선언문의 가치와 원칙을 실천하는 마음가짐이나 방법을 말한다.
애자일의 가장 큰 오해는 스피드로 보여질수 있다란것이다. 스피드보다는 올바른 방향을 찾기위해, 지속적으로 방향성 조정이 가능하다란것이다.
워터폴은 한번 정해지고 개발착수가되면, 그것이 완료될때까지 방향조정이 불가능한것과 비교해야하며 워터폴이 시원한 절차에의해 개발이 완료 되었다라고하면
오히려 스피드는 워터폴이 훨씬 빠를수있다.
우리의 시장은 과거와는 달리 변덕스럽고,불확실하며,복잡하고 모호하다
폭포수 모델이 규모를 다루는 방법이 였다라고 하면
애자일은 변화를 만들고 변화에 대응하는 능력이며, 불확실하고 급변하는 환경에서 궁극적으로 성공을 거두기 위해 그 환경을 다루는 방법이다.
다음은 1950년 애드워즈 데밍이 한 이야기이다.
‘품질향상은 실질비용을 낮춘다’고 말했다. 또한 그는 “생산라인에서 가장 중요한 요소는 소비자다.
소비자를 만족시켜 주는 일이 회사의 모든 사람들이 해결해야 할 최우선 과제이다.
모든 직원들이 자기가 만든 제품의 품질에 대해서 스스로 책임을 지는 품질 책임체제를 구축해야 한다. 기
업의 수익은 제품과 서비스에 만족하고 이를 지속적으로 구매하는 단골고객으로부터 나온다.”라고 말했다.
품질과 관련한 , 현재는 당연한 이야기인것처럼 보이지만, 1950대에 위 이야기는 미국에서 무시가되었으며
오히려 일본기업인 도요타,소니,혼다등이 데밍의 이야기를 따르며 제조업에서 미국을 앞지르기 시작했으며 부흥기를 맞게되었다.
일본에서 데밍상이 생겨났으며, 추월당한 미국이 일본을 다시 연구하기 시작한다. 이 이야기를 소개하는 이유는,
애자일에서 선언하는 가치와 닮아 있으며 애자일이 2001년 갑자기 생겨난 새로운 이야기가 아니라
제조업에서 그동안 축적된 문화와 철학이 소프트웨어 개발에도 영향을 주기 시작했다란 것이다.
품질은 우리가 경쟁사로부터 살아 남을수 있는 마지막 기회이다.
더자세한 이야기 : https://steemit.com/kr/@loum/w
소프트웨어 개발 중에 고약한 성질을 품은 문제를 만났을 때 그를 합당하게 해결하는 방법을 찾아나가고 있다.
주로 사용되는 폭포수 모델의 개괄적 원리를 설명하면서, 고약한 문제를 해결하는 데 부족함을 보여준다.
폭포수 모델의 변종인 소용돌이 모델 등에 대해서도 살펴보고 있다 나아가 폭포수 모델을 극복하기 위한 프로토타이핑 등 대안적 모델을 정의하고 찾아간다.애자일 인식의 뿌리가 되는 고서이며
폭포수모델의 문제를 해결하기위해, 폭포수 모델을 이해 해야하는것은 당연하다.
고약한 문제는 해결책이 문제의 공간 안에 있는 문제를 일컫는다. 즉 문제가 완전히 풀려야 비로소 그 문제가
무엇인지 완전히 이해되는 그런 문제다. 반면 그 반대편에는 합당한 문제가 있다. 합당한 문제는 정의할 수 있
고, 이들에 대한 데이터를 수집해서 분석할 수 있으며, 해결책을 낼 수 있는 문제다. 마치 폭포수 모델의 시원한
절차처럼 말이다.
소프트웨어 개발 프로젝트에서 어떤 결과를 내는 데 필요한 정보를 제공하거나 체계화하는 것은 컴퓨터가 중심
인 것처럼 보이지만 사실 사람이 중심에 서 있다. 그리고 태생적으로 야기되는 불확실성의 문제는 그 정형성을
이루는 데 반드시 있어야 하는 객관적이고 명료한 기준을 세우기 어렵게한다.
기술중심/이익중심도 중요하지만, 결국 소프트웨어의 문제를 푸는것은 사람이며 사람을 중심에 놓고
문제를 해결하려는 이야기는 "Wicked Problems Righteous Solution" 30년도 더된 IT고서에서 이야기를 하고있으며
애자일의 뿌리가 되는 내용입니다.
링크 :
문제를 팀이 정의를 하고 해결해나가는 힘을 키우는것은 , 개개인의 성장과함께 일정수준이 되어야함을 의미한다.
이것은 메타인지와 연관이 있을수 있다. 탑다운의 정형화된 폭포수모델에서는 대부분의 중요문제는 상위에서만 정의를 하였다.
반대로 이야기하면, 정보가 거의 없을 초기시점 그러니까 우리가 정보를 가장 모르는 초기시기 숙련된 경험자만이
설계단계에서 문제정의를 하였다. 애자일에서는 가장 모르는지점 감으로 문제정의를 모두내리는것에 대한 리스크를 이야기하며
애자일을 하기위해서는 팀구성원 모두가메타인지 능력을 사용해서 지속적인 문제정의와 해결방법을 찾아가야 하며
팀의 공유된 메타인지(shared meta-cognition)라고 부르기도합니다.
소프트웨어가 일반적으로 복잡해지는 이유는, 우리가 사용하는 기술자체의 복잡성 때문이 아니라
우리가 가진 도메인 자체의 복잡성에 기인하며, 도메인을 중심에 놓고 도메인 전문가 까지
모델을 만드는 단계에 참석을 시키는, 개발문화의 변화와 성숙에 대한 도전 과제로이야기가 이어집니다.
DDD를 하기위해서는 애자일이 필요하다. 애자일이 좋은 소프트웨어를 만들기위한 가치와 마음가짐을 포함
방법론을 이야기한다고 하면 DDD는 그것을 실천하기위한 구체적인 전략/전술을 이야기하며 애자일의 코어영역과 상당수 일치한다.
수평적 개발문화를 이해하기위해 애자일의 선언을 다시 살펴보자
20년도 전에 애자일을 도입하여 성공하는 기업들은 수직적 의사결정에서 수평적 기업문화로 조금씩 발전하기 시작하였으며
한국에서는 유독 MZ세대와 의사소통을 이야기하면서 수평적 기업문화에 접근을 하고 있는것같습니다. 이것은 수평이아닌 직원경험또는 맥락전달로 분리되어야하는 내용입니다.
수평적 개발문화를 워라벨(일을 적당히하는/워터폴 보다 스트레스가 적은)로 생각하면 큰 오산입니다. 오히려 애자일을 너무 열심히 한나머지 번아웃이 올수 있습니다.
수평은 가만히 있어서 유지할수 있는 상태가 아니라, 연필을 손바닥에 세워 떨어트리지 않으려고 계속 균형을 맞추는
사실은 모두의 구성원이 능동적이고 적극적으로 프로젝트에 참여하는 밸런스 게임이며 구성원이 적극적이지 않고 움직이지 않으면 그 수평은 유지될수 없습니다.
애자일 조직에서 OOO , 자기 직군을 검색해보면
어떠한 개발방법론이던지, 그 목표는 비즈니스의 성공에 있습니다.
복지와 관련된것이 아닙니다. 좋은 개발팀은 이상적 개발방법론을 도입한것이 아닌 오래가는 팀입니다.
오래가는 팀은 스스로 좋은 개발방법론을 만들게 되며, 구성원은 그 과정에서 성장을 하게됩니다.
지속하는 좋은 개발팀을 위한 장치로 좋은개발방법론 도입이 아닌, 최근 직원경험이란 키워드를 알게 되었고
개발팀의 구성원도 결국 회사의 직원이며, 오너쉽(직장충성)을 직원에게 강조하는 시대가 변화하고 있으며
이 시대에는 근속 3년을 못버틴 지원자는서류 광탈이였지만, 지금은 1년 경력도 소중한 시대가 되었습니다.(특히 개발자군)
그만큼 평균적으로 직장 라이프사이클이 짧아졌다란 이야기입니다.
직원경험은 구성원이 처음 회사를 접한 순간부터 회사를 떠날 때까지의 전반적인 모든 경험을 뜻하며
역량있는 사람을 처음부터 채택하는것도 중요하지만, 회사차원에서 직원경험 향상에 투자함으로
직원을 성장하고 좋은 직원을 유지하는것입니다.
애자일로 성공한 회사의 수평적문화를 잘못해석하여,국내기업이 도입시도한 수평적문화=좋은회사 가 아니라~
중요 컨셉은 구성원들을 이해하면서 직원경험을 발전시켜나가는데 있습니다. 단순하게 "급여","복지향상","고급사무실인테리어"
등이 필수조건이 아니기때문에 럭셔리하지 않은 중소기업개발문화에서도 생존을위해 투자하고 도입할수 있는것으로 보여집니다. (물론 럭셔리하지 않게~)
직원경험 자체를 향상시키는데 도움주는 솔류션으로 최근 MS(비바)까지 가세하였으며
성장하는 국내기업도 최소 2~3년안에 ERP만큼 도입만큼, 기업이 도입해야할 필수 솔류션이
되지 않을까? 조심스러운 예상을 해봅니다.
직원경험 솔류션
모든것(UI/UX/작동방법)을 표현하지말고 중요한것(요구사항분석,스토리보드,플로우)을 이야기할것
빈틈없는 정교함보다 심오한 간결함을 유지하고, 지속 업데이트
링크: https://brunch.co.kr/@cysstory/163
핵심은 작업에 있지 않다는것입니다. 가치를 어떻게 인식하느냐입니다.
https://ichi.pro/ko/wbsneun-ij-eo-beoliseyo-agileeseoneun-vbsga-pil-yohabnida-214235113856846
우리는 어떤 설계를 하고 있을까? 우리는 설계대신 "작업 보드 셔플" 이라는것을 진행하게되며
할일과 작업중 그리고 완료로 이어지는 작업의 아이템 변화과정을 지식 집약적인 일의 전부로 여기고
나머지는 프로그래머가 소스를 쏟아내기만 하면 된다라고 생각한다.
이는 잘 드러나지도 않고, 존재하지도 않는 설계에 엄청난 비지니스 비용을 쏟아붓는일이다.
좋은 설계의 다음 대안은 나쁜설계이다. 이 문구의 요점은 설계를 절대하지 않는것에대한 이야기이다.
처음부터 좋은 설계를 할수 없으며, 이것이 좋은지,나쁜지 판단할수가 없다.
나쁜설계를 시도하고, 효율적인 설계를 어떻게 할지 설계에대한 고민을 시작하란의미이다.
설계가 없는것은 지식획득이라는 중요한 것을 놓치고 ,큰 진흙 덩어리를 계속 만들어 내게되며
소프트웨어 개발을 이익중심이 아닌 원가 중심으로 생각하는 비지니스 문화가 확고한 경우 설계문화가
생겨날수 없다란것을 경고도 하고 있다. -도메인 주도 설계중에
wbs 방식이 구식인건 맞는데... 근데 그래도 산업군에 따라 그런 방식이 필요합니다. 고객에 의한 “가치 폭주 현상”이 발생합니다.
피드백을 통해서 자기도 기여한다고 느끼는 고객이 자신의 가치를 가지고 지나친 피드백을 해서 불필요한 품질상태를 만들기도 하니까요. 그래서 고객의 피드백을 제동해야할 때가 있습니다.
가치가 어디로 향해야 하는지는 결국 애자일 조직 리더의 몫이니까요.
Quality is value to someone.
- Gerald Weinberg
개발을 어떻게할지도 결정하지도 않았는데 , 개발이 언제까지 완료되고 디자인은 언제까지되고...
변경을 허용하지 않는 것은 나쁜 계획이다. - 푸볼릴리우스 시루스
더 자세한 자료 : http://wiki.webnori.com/m/view-rendered-page.action?abstractPageId=39583888
위 두가지가 있을때 무엇을 선택할것인가? 당연히 후자쪽일것이다.
애자일 도입으로 성공한 기업의 케이스도 많지만. 실패하는 기업의 케이스도 꽤 있다.(실패는 알려지지 않기때문에)
우리만의 워터폴을 만들어가는것도 좋은 대안이 될수 있으며
애자일과 같은 개발방법/프로세스에 얽매이지 않는 Shape UP의 방식을 살펴보는것도 도움이 될것이다.
과거 몇년간 어떻게 작은 팀으로, 높은 품질의 소프트웨어를 그렇게 빨리 개발해내는지 물어보곤 했다. 또, 개발자들을 오랫동안 유지하는지도.
첫째, 우리는 워터폴, 애자일, 스크럼같은 프로세스에 얽매이지 않았다.
둘째, 우리는 벽에 포스트잇을 줄세우지 않았다.
셋째, 우리는 데일리 스탠드업, 스프린트, 백로그, 칸반, 벨로시티 체킹등 어느 것도 하지 않았다. 우리는 우리의 길을 만들었다.
소프트웨어팀이 성장하면서 유사한 문제점들이 생겨난다.
- 팀원들은 프로젝트가 끝없는 행군처럼 느껴진다.
- 프로덕트 매니저들은 프로덕트에 대해 전략적으로 생각할 시간을 낼 수가 없다.
- 창업자들은 자문한다. 왜 우리는 예전에 했던 것처럼, 신속하게 기능을 출시할 수가 없을까?
우리는 4명에서 50명으로 늘어나면서 이런 문제에 직면했다.
사람 수가 늘어나면서, 창업자들의 직관을 전달하기가 어려워졌다. 그래서 새로운 스케일에 맞는 구조가 필요했다.
6주 사이클.
새 스케일에 맞는 매니지를 위해, 프로젝트 길이가 그때그때 달랐던 것에서, 반복적인 사이클로 변경했다. 6주는 뭔가 의미있는 것을 만들기에 충분히 길었고, 마감일이 눈앞에 보이기 때문에 시간을 효과적으로 계획하게 만들었다.
우리의 의사결정은 시간을 마이크로매니지하는 것이 아니라, 다음 6주간 제품을 어떻게 발전시킬 것인지에 대한 것이 되었다.우리는 개별 기능에 몇시간을, 또는 며칠을 썼는지 세지 않았고, 일일 미팅도 하지 않았다. 우리의 로드맵을 2주마다 새로 생각하지 않았다. 우리의 촛점은 좀 더 상위에 있었다. 우리는 스스로에게 얘기했다. "이 제품이 6주 후에 업데이트되면 우리는 시간을 잘 쓴게 될 거야". 이후에 우리는 6주를 팀에게 보장하고, 해내도록 내버려두었다.
기업은 경쟁을 좋아한다. 밟고 이기고, 1 or 0으로 만들길 원한다.
우리는 그렇지 않다. 나는 다른 누군가와 경쟁하는 것에 흥미가 없다. 그리고 우리는 경쟁적인 관점에서 결정을 내리지도 않는다.
내게 비즈니스란 경쟁과는 무관하다.
시장에선 HEY(Basecamp가 만든 이메일 서비스 - hey.com)가 Gmail과 경쟁한다고 생각할 수 있지만 사실 그렇지 않다.
Gmail의 사용자는 거의 20억 명에 이르는데 그 중 0.01% 정도의 사용자만 우리를 사용한다 해도 정말 운이 좋다고 말할 수 있다.
Gmail의 시장 점유율은 약 40% 정도인데 반해 HEY는 시장 점유율이란 레이더에서 보이지 않는 수준이고 Gmail이 전체 이메일의 약 27%를 차지하는데 비해 아마 HEY는 앞쪽에 0이 한참은 붙어 있다.
즉, 이렇게 비교하기 시작하면 우리는 계속 지는 게임을 하고 있는 게 되는 셈이다.
말 그대로 패배자다.
그래서 우린 승패를 별로 생각하지 않는다. 경쟁은 스포츠를 위한 것이지 비즈니스를 위한 것이 아니다.
링크 :