30년된 고서이지만 , 폭포수 모델의 한계와 애자일 인식의 뿌리에 대해 이야기하고 있다.

책 내용을 약간 언급하며, 개인적인 관점으로 몇가지 해석본을 첨부하였습니다.


link : http://www.yes24.com/Product/Goods/4332036

고약한 문제 정의 - 책내용중

고약한 문제는 해결책이 문제의 공간 안에 있는 문제를 일컫는다. 즉 문제가 완전히 풀려야 비로소 그 문제가

무엇인지 완전히 이해되는 그런 문제다. 반면 그 반대편에는 합당한 문제가 있다. 합당한 문제는 정의할 수 있

고, 이들에 대한 데이터를 수집해서 분석할 수 있으며, 해결책을 낼 수 있는 문제다. 마치 폭포수 모델의 시원한

절차처럼 말이다.

소프트웨어 개발 프로젝트에서 어떤 결과를 내는 데 필요한 정보를 제공하거나 체계화하는 것은 컴퓨터가 중심

인 것처럼 보이지만 사실 사람이 중심에 서 있다. 그리고 태생적으로 야기되는 불확실성의 문제는 그 정형성을

이루는 데 반드시 있어야 하는 객관적이고 명료한 기준을 세우기 어렵게한다.

  • 고약한 문제는 정형화되어 있지 않다.
  • 고약한 문제를 푸는 해결책은 옳으냐 틀리냐가 아니라 좋으냐 나쁘냐다.
  • 고약한 문제에는 중단의 규칙이 없다.


빅뱅이론은, 기 이론이 우주의 탄생을 설명하 기에 적합한 내용인지 모든 천문학자가 동의하는 건 아니지만,

천문학자 라면 이해는 한다. 하지만 소프트웨어 공학 분야에서는 모든 사람이 동의
하는 전문용어가 없다. 예를 들어, 객체지향 프로그래밍의 정의는 다양하다.

비즈니스 환경에서 우리 분야를 원래 '데이터 처리'라고 불렀지만 지금은 '정보 처리'라고 부른다.

공학 환경에서는 '컴퓨팅'이라고 부른다. 우리 가운데 일부는 이제 우리분야의 이름을 '지식 처리'라고

바꿔 부르기를 원하기도 한다. 

소프트웨어 공학에서 모두가 동의하는 전문용어가 없고 고민해본적이 없다. 


폭포수모델

개발의 라이프사이클이 폭포수처럼 시원하게 아래로 떨어져서 폭포수 모델이라고 불리며

절차를 수행하는 방법이 변경된 여러가지 변종이 있음

폭포수 모델의 변종

  • 소용돌이 모델
  • 점진적인 모델
  • 나선형 모델

폭포수모델에서 설명하는 몇가지 중요요소(WBS/설계/구현/테스트/배포)

생략할수 있는것이 아니며, 단지 절차식이 아닌 다른 슬라이싱과 시간방법으로 해결 하자는 이야기 이기 때문에

폭포수 모델을 먼저 이해하는것은 중요합니다.


위 모델은 폭포수모델에서 언급되는 모델이며

폭포수 모델의 특성으로 다음과 같이 설명합니다.

폭포수 모델은 형식을 갖춘 방법이다.

소프트웨어를 개발하는 질서졍연하고 체계적인 방법이다.

폭포수는 나일강을 따라 내려가는 여왕의 유람처럼 복잡하고 장엄한

프로세스다. 그래서 대개 큰조직에서 소프트웨어를 생산하는데 사용한다.

한마디로 폭포수 모델은 프로젝트의 복잡성과 규모를 관리하는 하나의 방법이다.

 - 고약한문제 합당한 해결중에…..


이야기의 중반부에서는 이러한 폭포수모델의 한계를 지적하고 애자일 인식의 뿌리가 되는

여러가지 대안을 제시한다.


개발방법에대해 어떠한 모델도 이해한적도 없고, 경험한적 없는 수평문화와 애자일을 외치는

Pa(아래에 추가설명) 에게 추천해주고 싶은책이다.


애자일을 포함하는 비교적 최신버전인 도메인주도설계또한 이러한 과거의 개발방법론이 없었던 상태에서 짠하고 나타난것이 아니기때문에

폭포수 모델은 적어도 형식을 갖추고 있으며 가장 유명한 동시에 아직도 선호되기도 합니다.

하지만 이러한 모델도 한계가 있으며 개선된 개발방법을 도입하기 전에 먼저 학습해야하는 모델임에는 분명합니다.


폭포수 모델의 단점

실제는 개발방법론보다는 프로젝트 관리기법에 더 가깝고

( 90프로가 작업한 내용의 언급과 보고, 10퍼센트만이 무엇을어떻게해야하는지에대한 설명)

이러한 하향식 설계방법이 엄청난 시간과 비용이 들며 효율적이지 못하다란점이다.

제대로 하기엔 , 비용이 너무 많이 든다는 점과, 변화에 대응하기 어렵습니다.

한번 흘러내린 폭포수는 위로 역류할수 없기 때문입니다. ( 변화에대한 비용 측정 불가 )


폭포수 모델의 단점 자체보다는, 폭포수 모델을 사용하면서 발생한 현상자체를 이야기합니다.

폭포수 모델자체도 아무것도 없이 개발하는 개발형태의 문제를 해결하기 위해 등장한 방법론입니다.

폭포수 모델을 사용하는 것이 많은 프로젝트에 도움이 됐고 수년 전의

'코딩부터 시작하는' 회사들에 비해 개선되었다는 것은 의심할 바 없는 사실이다.

... 폭포수 모델의 도움으로 풀어왔던 문제는 우리가 풀 만한 문제였다.

"여러분이 가진 유일한 도구가 망치라면 문제를 못의 관점에서만 보게 된다."

"우리가 가진 유일한 모델이 폭포수 모델이라면 우리는 폭포수를 사용하는 관점으로

우리 분야의 문제를 볼것이다. 우리의 세상과 분야는 이것보다 더 다양하다,

우리는 모델로 가득한 공구상자가 필요하다.

고약한문제 합당한 해결 .p144

코딩부터 시작하는 회사에게, 폭포수 모델을 먼저 학습하는것을 추천합니다. ( 도입을 하라는 이야기는 아님)

WBS작성 경험 없는 PM/PL이, 애자일의 스크럼 마스터 부터 접근하여 스케쥴관리가 망하는 케이스를 수없이 봐왔습니다.

또한 어떠한 개발 생명주기 필요없이 코딩부터 시작하는 개발사(자)가 분명 아직도 존재하며

개발문화없이 단기적인 수익을 내는 서비스에서는 적합할지도 모릅니다.

자신만의 개발생명주기가 없는 개발자 자체를, 이 책에서는 Pa라고 부릅니다. 

이 책에서 설명하는 Pa에대한 정의

브룩스와 피터스는 우리들, 즉 프로그래머가 소프트웨어 공학에서 긍정적 변화의 핵심이라고 지적한다.

이것은 프로의식(professionalism)과 관련이 있다. 사람들 대다수는 프로그래머가 아마추어인지

프로인지는 깔끔하게 구분된다고 생각하고 있다고 레거스는 적었다. 그러나 이런 부류가 있다.

바로 프로라고 불리는 아마추어다. 레거드는 이들을 P밑에 a를 적은 Pa프로그래머로 불렀다.


Pa에는 몇가지 유형이 있다.

  • 첫번째는 최근에 졸업한 사람으로 스스로 전문가라고 여기는아마추어다.
  • 두번째는 전문가 위치로 옮겨가고 있는 초보자처럼 프로가 되려고 배우는 아마추어다.
  • 세번째는 필수 기술 보유유무와는 상관없이 승진한 사람처럼 프로라고 불리지만 실제는 아마추어인 경우다.


그리고 다음과 같은 특성을 보인다.

책의 언급내용 ( Pa) - p.55

아마추어는 사용자가 프로그래머와 똑같이 알고 있다고 가정하는 반면 프로는 결코 사용자가 알고 있다고 가정하지 않는다.

아마추어는 예외를 살면서 일어날 수 있는 것으로 여기지만, 프로는 설계할 때 이미 그 예외적인 경우를 포함시킨다.

아마추어는 리뷰를 귀찮게 여기지만, 프로는 리뷰를 환영한다.

아마추어는 버그를 닥치는 대로 만들어내지만, 프로는 에러가 없는 프로그램을 출시한다.

아마추어는 문서를 마지막에 작성하지만, 프로는 처음부터 작성한다.

아마추어는 불완전한 명세서 스펙으로 작업하지만, 프로는 명세서를 매우 자세하게 만든다.

아무추어는 생명주기를 잘 따르지 않지만, 프로에게는 잘 정의된 단계와 기준이 있다.

Pa들은 당면한 일을 그럭저럭 해나갈 뿐이지만, 프로는 미래와 더 큰 시스템에 대한 관심을 보이며 일한다.

아마추어는 컴퓨터를 위해 프로그래밍하지만,프로는 사람을 위해 프로그래밍한다.


고약한 문제는 결국 사람이 만들어내며, 이것을 해결하는것도 사람이다. 30년전 고서이지만,

아마추어같은 프로가 존재한다란것을 지적하고 있으며

이것은 지금도 유효해 보인다. p.37 에서  고약한 문제를 해결하 전 우리의 수준에 대한 고찰을 먼저한다.

즉 현재가진 개발자의 수준을 파악하여 높이거나 갖추는것을 처음으로 여긴다.


중요한 일부터 먼저

애자일과 함께 비교적 최근에 나온 개발방법론으로 DDD(도메인주도설계) 가 있다.

이것역시 10년전에 나온 개념이였지만, 왜 최근에야 클린아키텍트와 함께 각 진영에서

중요하게 생각하고 지원하고 있는지? 고민할 필요가 있다. 

좋은 개발방법론을 이야기를 하는 아키텍처의 시대를 지나, 구현에 참가하는 모두가 실천형 아키텍처가 되어야함을 강조한다.


참고자료: ddd with 관심언어 를 검색하면 DDD와 함께 클린아키텍트로 구현할수 있는 수준 높은 코드들을 찾아볼수 있다. 각진영 정확하게는 모든 언어의 진영에서 찾을수 있다.


DDD를 프로젝트에 성공적으로 적용하기 위해 가장 중요한 것 중 하나는 좋은 사람들을 고용하는 것이다.

좋은 사람들을 간단히 대체할 수 있는것은 없다. 이 관점에서 보면 평균을 넘는 개발자들이 필요하다.

DDD처럼 소프트웨어를 개발하는 고급 철학이자 기술관점에서 볼 때, 평균 이상의 개발자. 

더 정확히 말하면, 매우 좋은 개발자가 필요하다. 

도메인 주도 설계 핵심 . p188에서


 폭포수모델의 한계와 이를 해결하는 방법을 설명하다가 갑자기 DDD를 이야기한것은

30년전 고서와 마찬가지로, 최근에 나온 방법론에서도 이야기하는 먼저 해야할것은

평균 이상의 수준 높은 개발자가 있어야한다란 점이다. 



  • No labels
Write a comment…