Page History
...
폭포수모델은 형식을갖춘방법이다.
소프트웨어를 개발하는질서 정연하고 체계적인방법이다.
폭포수는 나일강을 따라내려가는 여왕의유람처럼복잡하고장엄한 프로세스이며
수직적인 절차의 제일 하부목표는 성공이며, 규칙이 없는 팀이 처음 적용하기에 도움이될수 있다.
그래서 대개 큰조직에서 소프트웨어를 생산하는데 사용한다.
(또는 비즈니스 모델을 잘 이해하는 쪽이 제일 상부에 있다면, 폭포수모델을 따르는것이 비즈니스성공가능성이 높다.)
한마디로 폭포수모델은 프로젝트의 복잡성과 규모를관리하는하나의방법이다.
- 고약한문제 합당한 해결 책중에....
폭포수 모델의 논리적 근거
소프트웨어 개발에는 반드시 필요한 하위 목표가 있다. 하나의 단계를 성공시키면 배열된 다음 목표를 성공시켜나간다. 이렇게 배열된 맨 마지막 순서가 바로 성공이다.
또한 수행하는 업무를 전문적으로 만들며, 전문적인 롤이 폭포수모델의 단계와 일치한다. 경험정도도 반영되는데 일반적으로 초기에 경험 많은 시니어(착수,요구사항분석)가
참여하고 다음이 중간레벨(분석,설계) 그다음 직원이 코딩,유지보수등의 업무를 수행한다.
상위 절차가 중요며 일반적으로, 워터폴에서 IT직군은 다음 역활을 수행한다.
- PM : 변화는 곧 리스크이기때문에, PM의 역활이 중요합니다. WBS를 통해 리스크관리를 합니다.
- 기획 : 비지니스 요구사항을 잘정리하여 변경없는 문서를 만들어야합니다. 요구명세가 완성된후에 개발 착수가 가능합니다.
- 설계 : 경험많은 숙련자가 요구명세를 바탕으로 설계를 진행합니다.
- 구현/QA : 구현자는 주로, 코더로 분류됩니다.
규모에따라 PM+기획 / 설계+구현 동일 사람일수 있지만 절차적인 흐름에는 큰 변화가 없으며 직군이 더 전문화되어 세분화될수 있으며
폭포수의 단계가 변경 있지만, 설계가 포함되지 않은것을 개발 프로세스가 없다라고 이야기하기도 합니다.
폭포수모델역시 초기모델의 단점을 극복하고자 변형되어 소용돌이 모델/점진적 모델/나선형/린(프로토타입)등 다양한 개발모델들이 등장하게 됩니다.
어떠한 것은 개발조직을 운영하고 다루는 방법에 가까울수 있고 어떠한 것은 개발방법론 그 차체일수도 있습니다.
애자일은 개발조직을 운영하는 방법도, 구체적인 개발방법론도 아닙니다.
애자일 선언
2001년, 소프트웨어 업계를 주도하는 17인의 리더들이 모여 다음을 선언하였다.
- 공정과 도구보다 개인과 상호작용을
- 포괄적인 문서보다 작동하는 소프트웨어를
- 계약 협상보다 고객과의 협력을
- 계획을 따르기보다 변화에 대응하기
이 말은, 왼쪽에 있는 것들도 가치가 있지만, 우리는 오른쪽에 있는 것들에 더 높은 가치를 둔다는 것이다.
애자일이, 긴민함/민첩함 이란 형용사적 단어적 의미도 있지만, 애자일 선언문의 가치와 원칙을 실천하는 마음가짐이나 방법을 말한다.
애자일의 가장 큰 오해는 스피드로 보여질수 있다란것이다. 스피드보다는 올바른 방향을 찾기위해, 지속적으로 방향성 조정이 가능하다란것이다.
워터폴은 한번 정해지고 개발착수가되면, 그것이 완료될때까지 방향조정이 불가능한것과 비교해야하며 워터폴이 시원한 절차에의해
개발이 완료 되었다라고하면 오히려 워터폴이 스피드할수 있다.
소프트웨어의 복잡성과 변화가 아닌 규모를 관리하는 측면에서는 워터폴이 효율적일수 있습니다.
키워드로 살펴보는 애자일맵
우리의 시장상황
우리의 시장은 과거와는 달리 변덕스럽고,불확실하며,복잡하고 모호하다
폭포수 모델이 규모를 다루는 방법에 가까웠다고 하면 애자일은 변화를 만들고 변화에 대응하는 능력이며, 불확실하고 급변하는 환경에서 궁극적으로 성공을 거두기 위해 그 환경을 다루는 방법이다.
애자일의 기원
폭포수모델의 한계
소프트웨어 개발 중에 고약한 성질을 품은 문제를 만났을 때 그를 합당하게 해결하는 방법을 찾아나가고 있다.
주로 사용되는 폭포수 모델의 개괄적 원리를 설명하면서, 고약한 문제를 해결하는 데 부족함을 보여준다.
폭포수 모델의 변종인 소용돌이 모델 등에 대해서도 살펴보고 있다 나아가 폭포수 모델을 극복하기 위한 프로토타이핑 등 대안적 모델을 정의하고 찾아간다.
애자일 인식의 뿌리가 되는 고서이며 폭포수모델의 문제를 해결하기위해, 폭포수 모델을 이해 해야하는것은 당연하다.
고약한 문제는 해결책이 문제의 공간 안에 있는 문제를 일컫는다. 즉 문제가 완전히 풀려야 비로소 그 문제가
무엇인지 완전히 이해되는 그런 문제다. 반면 그 반대편에는 합당한 문제가 있다. 합당한 문제는 정의할 수 있
고, 이들에 대한 데이터를 수집해서 분석할 수 있으며, 해결책을 낼 수 있는 문제다. 마치 폭포수 모델의 시원한
절차처럼 말이다.
소프트웨어 개발 프로젝트에서 어떤 결과를 내는 데 필요한 정보를 제공하거나 체계화하는 것은 컴퓨터가 중심
인 것처럼 보이지만 사실 사람이 중심에 서 있다. 그리고 태생적으로 야기되는 불확실성의 문제는 그 정형성을
이루는 데 반드시 있어야 하는 객관적이고 명료한 기준을 세우기 어렵게한다.
기술중심/이익중심도 중요하지만, 결국 소프트웨어의 문제를 푸는것은 사람이며 사람을 중심에 놓고
문제를 해결하려는 이야기는 "Wicked Problems Righteous Solution" 30년도 더된 IT고서에서 이야기를 하고있으며
애자일이 생기기전 인식의 뿌리가 되는 내용입니다.
링크 :
- 서적 : http://www.kyobobook.co.kr/product/detailViewKor.laf?ejkGb=KOR&mallGb=KOR&barcode=9788991268869
- 폭포수 모델과 한계점 요약 : http://wiki.webnori.com/m/view-rendered-page.action?abstractPageId=50790420
폭포수 모델의 논리적 근거
소프트웨어 개발에는 반드시 필요한 하위 목표가 있다. 하나의 단계를 성공시키면 배열된 다음 목표를 성공시켜나간다. 이렇게 배열된 맨 마지막 순서가 바로 성공이다.
또한 수행하는 업무를 전문적으로 만들며, 전문적인 롤이 폭포수모델의 단계와 일치한다. 경험정도도 반영되는데 일반적으로 초기에 경험 많은 시니어(착수,요구사항분석)가
참여하고 다음이 중간레벨(분석,설계) 그다음 직원이 코딩,유지보수등의 업무를 수행한다.
폭포수모델역시 초기모델의 단점을 극복하고자 변형되어 소용돌이 모델/점진적 모델/나선형/린(프로토타입)등 다양한 개발모델들이 등장하게 됩니다.
품질과 데밍상
다음은 1950년 다음은 1950년 애드워즈 데밍이 한 이야기이다.
‘품질향상은 실질비용을 낮춘다’고 말했다. 또한 그는 “생산라인에서 가장 중요한 요소는 소비자다.
소비자를 만족시켜 주는 일이 회사의 모든 사람들이 해결해야 할 최우선 과제이다.
모든 직원들이 자기가 만든 제품의 품질에 대해서 스스로 책임을 지는 품질 책임체제를 구축해야 한다. 기
업의 수익은 제품과 서비스에 만족하고 이를 지속적으로 구매하는 단골고객으로부터 나온다.”라고 말했다.
품질과 관련한 , 관련해서 현재는 당연한 이야기인것처럼 보이지만, 1950대에 위 이야기는 미국에서 무시가되었으며무시가되었으며 오히려 일본기업인 도요타,소니,혼다등이 데밍의 이야기를 따르며 제조업에서 미국을 앞지르기 시작했으며 부흥기를 맞게되었다.
일본에서 데밍상이 생겨났으며, 추월당한 미국이 일본을 다시 연구하기 시작한다. 이 이야기를 소개하는 이유는, 애자일에서 선언하는 가치와 닮아 있으며 애자일이 2001년 갑자기 생겨난 새로운 이야기가 아니라 제조업에서 그동안 축적된 문화와 철학이 소프트웨어 개발에도 영향을 주기 시작했다란
토요타의 간반(看板)방식이나 지도카(自動化), JIT(Just-In-Time), 업무 표준화는 데밍의 품질 이론 속에서 태어난 것이다.
품질은 우리가 경쟁사로부터 살아 남을수 있는 마지막 기회이다. - 잭 웰치
더자세한 이야기 : https://steemit.com/kr/@loum/w
애자일
...
소프트웨어 개발 중에 고약한 성질을 품은 문제를 만났을 때 그를 합당하게 해결하는 방법을 찾아나가고 있다.
주로 사용되는 폭포수 모델의 개괄적 원리를 설명하면서, 고약한 문제를 해결하는 데 부족함을 보여준다.
폭포수 모델의 변종인 소용돌이 모델 등에 대해서도 살펴보고 있다 나아가 폭포수 모델을 극복하기 위한 프로토타이핑 등 대안적 모델을 정의하고 찾아간다.
애자일 인식의 뿌리가 되는 고서이며 폭포수모델의 문제를 해결하기위해, 폭포수 모델을 이해 해야하는것은 당연하다.
고약한 문제는 해결책이 문제의 공간 안에 있는 문제를 일컫는다. 즉 문제가 완전히 풀려야 비로소 그 문제가
무엇인지 완전히 이해되는 그런 문제다. 반면 그 반대편에는 합당한 문제가 있다. 합당한 문제는 정의할 수 있
고, 이들에 대한 데이터를 수집해서 분석할 수 있으며, 해결책을 낼 수 있는 문제다. 마치 폭포수 모델의 시원한
절차처럼 말이다.
소프트웨어 개발 프로젝트에서 어떤 결과를 내는 데 필요한 정보를 제공하거나 체계화하는 것은 컴퓨터가 중심
인 것처럼 보이지만 사실 사람이 중심에 서 있다. 그리고 태생적으로 야기되는 불확실성의 문제는 그 정형성을
이루는 데 반드시 있어야 하는 객관적이고 명료한 기준을 세우기 어렵게한다.
기술중심/이익중심도 중요하지만, 결국 소프트웨어의 문제를 푸는것은 사람이며 사람을 중심에 놓고
문제를 해결하려는 이야기는 "Wicked Problems Righteous Solution" 30년도 더된 IT고서에서 이야기를 하고있으며
애자일이 생기기전 인식의 뿌리가 되는 내용입니다.
링크 :
...
선언
2001년, 소프트웨어 업계를 주도하는 17인의 리더들이 모여 다음을 선언하였다.
- 공정과 도구보다 개인과 상호작용을
- 포괄적인 문서보다 작동하는 소프트웨어를
- 계약 협상보다 고객과의 협력을
- 계획을 따르기보다 변화에 대응하기
이 말은, 왼쪽에 있는 것들도 가치가 있지만, 우리는 오른쪽에 있는 것들에 더 높은 가치를 둔다는 것이다.
애자일이, 긴민함/민첩함 이란 형용사적 단어적 의미도 있지만, 애자일 선언문의 가치와 원칙을 실천하는 마음가짐이나 방법을 말한다.
애자일의 가장 큰 오해는 스피드로 보여질수 있다란것이다. 스피드보다는 올바른 방향을 찾기위해, 지속적으로 방향성 조정이 가능하다란것이다.
워터폴은 한번 정해지고 개발착수가되면, 그것이 완료될때까지 방향조정이 불가능한것과 비교해야하며 워터폴이 시원한 절차에의해
개발이 완료 되었다라고하면 오히려 워터폴이 스피드할수 있다.
소프트웨어의 복잡성과 변화가 아닌 규모를 관리하는 측면에서는 워터폴이 효율적일수 있습니다.
키워드로 살펴보는 애자일맵
우리의 시장상황
우리의 시장은 과거와는 달리 변덕스럽고,불확실하며,복잡하고 모호하다
폭포수 모델이 규모를 다루는 방법에 가까웠다고 하면 애자일은 변화를 만들고 변화에 대응하는 능력이며, 불확실하고 급변하는 환경에서 궁극적으로 성공을 거두기 위해 그 환경을 다루는 방법이다.
...
메타인지와 애자일
문제를 팀이 정의를 하고 해결해나가는 힘을 키우는것은 , 개인의 성장과 함께 팀의 수준또한 중요함을 의미합니다.
...