Page History
...
폭포수모델은 형식을갖춘방법이다.
소프트웨어를 개발하는질서 정연하고 체계적인방법이다.
폭포수는 나일강을 따라내려가는 여왕의유람처럼복잡하고장엄한 프로세스이며
수직적인 절차의 제일 하부목표는 성공이며, 규칙이 없는 팀이 처음 적용하기에 도움이될수 있다.
그래서 대개 큰조직에서 소프트웨어를 생산하는데 사용한다.
(또는 비즈니스 모델을 잘 이해하는 쪽이 제일 상부에 있다면, 폭포수모델을 따르는것이 비즈니스성공가능성이 높다.)
한마디로 폭포수모델은 프로젝트의 복잡성과 규모를관리하는하나의방법이다.
- 고약한문제 합당한 해결 책중에....
폭포수모델의 한계
고약한 문제(wicked problem)는 문제가 무언지 해결되어야 비로소 완전히 이해되는 문제이다. 이 책은 프로그래밍 과정에서 얼마나 많은 문제가 이런 고약한 성질을 품고 있는지를 살핀다. 그간 주요 방법론으로 채택되고 있는 폭포수 소프트웨어 개발 방식이 이 문제를 풀기에는 얼마나 택도 없이 모자라는지를 다양한 이론과 사례를 들어 그려낸다.
고약한 문제가 피할 수 없는 문제라 하여 극복의 노력조차 하지 않을 수는 없을 것이다. 이 책은 그런 노력의 산물로 나온 것이다. 이런 고약한 문제의 원인을 살펴보고 광범위하게 사용되는 폭포수 모델이 왜 이런 문제를 해결할 수 없는지를 설명한다. 그리고 대안적 방법론을 짚어보면서 해결의 가능성을 타진한다. 가히 지금은 많이 퍼져있는 애자일 방법론의 뿌리를 엿볼 수 있는 인식과 방법들이다. 눈 밝은 독자라면 현재 주된 개발 방법인 폭포수 모델의 한계를 바로 인식하고 그런 상황적 전제에 도전할 수 있는 이론적 근거를 잡아낼 것이다.
* 출처 : 예스24 <https://www.yes24.com/product/goods/4332036>
역자 서문
소개
Chapter 1소프트웨어 공학과 과학
Chapter 2프로그래밍의 ‘현재 수준’에 대한 개인적 견해
기술에 대한 열광, 유행, 그리고 우린 누구인가
요약
Chapter 3폭포수 모델
시작점과 끝점
단계와 변종
세부 논의
마무리 생각
요약
Chapter 4폭포수 모델에 존재하는 문제점
불완전한 요구사항
폭포수 모델은 비용이 지나치게 들어간다
폭포수 모델은 지나치게 오래 걸린다
폭포수 모델의 변종
최종사용자와 의사소통에서 생기는 틈
‘어떻게’에서 분리된 ‘무엇’
에러 관리
고약한 문제
마무리 생각과 요약
Chapter 5소용돌이 모델, 점진적인 모델, 나선형 모델
약화시키기와 축소하기
점진적 모델
Chapter 6프로토타이핑
프로토타이핑을 어떻게 사용하는가
언제, 어디서 프로토타이핑을 사용하는가
프로토타이핑을 사용할 때 이점
프로토타이핑의 문제점
하드웨어와 소프트웨어를 유사하게 보는 데 대한 몇 가지 마무리 생각
요약
Chapter 7즉각 모델
팀 접근방법- 사시미와 스크럼
투맨 접근방법- 수갑 채우기
원맨 접근방법- 해킹
요약
Chapter 8기타 모델들
비디오 모델
클린룸 모델
최종사용자 모델
시스템 엔지니어링
요약
Chapter 9프로의식과 과학
프로의식
과학
참고문헌
찾아보기
저자 : 피터 드그라스 Peter DeGrace
소프트웨어 개발 중에 고약한 성질을 품은 문제를 만났을 때 그를 합당하게 해결하는 방법을 찾아나가고 있다.
...
데밍의 14가지 지침 ( 50년전 제조업을 위한 이론으로 애자일 선언의 코어영역에 영향을 주었습니다. 린/칸반등은 애자일보다먼저 데밍품질이론에의해 탄생되었으며 애자일로 부분포함되기도 합니다. )
우리의 시장상황
우리의 시장은 과거와는 달리 변덕스럽고,불확실하며,복잡하고 모호하다
...
- 계속되는 개선이, 지연되는완벽함보다 낫다. 시장선도자는 혁신을 일상적인것으로만드는법을 배워야한다. -마크 트웨인
변경을 허용하지않는것은나쁜 계획이다. - 푸볼릴리우스 시루스
- 최종사용자와 의사소통에서 생기는 틈 : 폭포수 모델의 생명주기는 진열대를 돌아다닐 기회도 주지 않고 슈퍼마켓 입구에서 고객이 점원에게 완벽하게 주문하도록 강요하는 슈퍼마켓과 비교할수 있다. (진열대를 돌아다니면, 가격을 비교할수도 있고, 쇼핑 목록에 없는 항목을 기억할수도 있고, 그냥 외식하러 가기로 결정할수도 있다. -맥크래켄
장기 계획은 세우지마라
사업 계획이라는 말 자체가 어불성설이다. 사업추측이라면 또 모를까. 재무계획은 재무 추측으로
전략 계획은 전략 추측으로 바꿔야 옳다. 이렇게 명칭을 바꾸고 나면 얼마나 편한지 모른다.
계획을 세우면 그 계획에 질질 끌려다니지만 , 추측은 기회를 잡기위해 다음과 같이 조정할수도 있다.
"이제 보니가 이쪽이 아니라 저쪽이 맞는군." 때로는 이렇게 되어야한다.
이것이 미래에 대해 생각하지 말라는 말은 아니며 장애물을 어떻게 다룰지 고민을 하라는 이야기다. -REWORK
다문화 기업에서 경험한 도메인 발견 가속화방법
2018년쯤 VGW 호주 개발사 에서 경험한 내용으로, 국내에서는 경험하지 못한 내용들을 정리 해보았습니다.
최근 스타트업은 실리콘밸리의 개발문화를 학습하여 이제는 공유되고 익숙한 내용일수 있습니다.
- 완성해야할 기획문서가 있는것이 아니라, 구성원 모두가 기획에 참여하며 이 구성원은 모두 도메인주도 개발을 기본으로 지속 학습해야하며 팀리더는 그 수준을 지속 모니터링 합니다. 기획자직군이 별도로 있는것이 아닌 비즈니스 분석가가 그 역할을 하게되지만 플로우를 정리하고 비즈니스 요구사항을 정리하는데 도움을 줍니다.
- 백로그에서 꺼낸 스토리를, BDD와 혼합된 이벤트스토밍을 사용하여 이벤트 발생순서대로 기능을 정의하고 문제정의와 함께 해결방법을 조심씩 완성해 나갑니다. 마지막 단계에서는 QA가 BDD베이스 TC를 작성할수 있을만큼의 텍스트가 정의됩니다. 이것이 완성되면 "Are You Happy?"와 함께
개발시작가능한 Ready To Play로 옮겨 놓습니다. 릴리즈보다 Ready To Play 로 옮겨놓는것에 더 열광을 했던것 같습니다.- 설계와 함께 스토리포인트 측정이 완료되었다라는것을 의미하며 이 단계로 오지못한 Task는 스프린트 플래닝을 할수 없습니다. ( 러프하게 일정을 잡는것이 허용이 안되며, 스프린트에 포함이 된것 자체가 변동이 안됩니다. )
- 프로덕트 책임이 대부분 이벤트스토밍 초기단계에 참여하여 정책상 중요결정이 필요한경우 빠르게 내려줍니다. 비즈니스 전문가가 대부분 개발자가 아니기때문에 초반단계에서는 개발용어 사용이 금지됩니다. DDD에서는 유비쿼터스 언어라고 불립니다.
- 미팅문화는 모두가 균등하게 발언하고 이해하는 방향으로 진행되며, 침묵을 하게 되면 이해를 못하거나 이사람은 이 미팅의 주제에 필요없는 사람이라고 간주합니다. 하지만 발언을 하지 않고 대부분의 파편화된 미팅에 듣기모드로만 참석하는 딤간 정보를 취합하고 공유하는 전문가가 존재합니다.
- 브랜치 개발팀은 현재 해체되었지만 호주메인 개발팀과 한국 브랜치 개발팀이 있었으며, 주기적으로 크로스 방문을 합니다. 단순하게 방문하는 것이아닌 상대팀 스프린트에 직접참여하기위해 스프린트 참여 계획을 포함하여 방문합니다.
- 디자이너가 단순하게 디자인만 관여하는것이 아닌, 도메인 미팅 초기에 참여하고 기여도 하며 UX를 포함 프로덕트를 만들어가는데 기여를 합니다.
도메인 발견 가속화도구 - 이때 경험한 방법론을 경험하고 배운것은 다시 정리하고 재 정리하였습니다.
스포티파이 모델과 애자일
스포티파이 모델은 애자일의 교과서 처럼 회사이름 자체가 애자일 모델이 된 케이스입니다.
...
우리는 우리의 길을 만들었다. - 이 방식을 무작정 따라하는것이 아닌 참고하여 자신만의 방식을 만들라란 의미로 해석하고 있습니다)
Shape UP - 개인해석본 정리
지속 업데이트
"폭포수모델의 한계와 애자일인식을 통한 우리만의 방식찾기" 란 컨셉으로 관련 자료를 수집중에 있으며
폭포수모델도 한계가 있는것이지~ 모든상황에서 나쁜것은 아니며 애자일 인식은 한계와 환경을 개선하는데
도움을 주지만 단 하나의 마법은아니며 결국은 우리에게 가치가 있는것이 무엇인가 지속 고민하는것이 필요하며
오늘은 좋다고 생각한 방법론이 미래또는 어떠한 규모와 환경에는 안맞을수 있으며 관련 자료를 지속 연구하며 업데이트 중에 있습니다.