Page History
...
제조업에서 그동안 축적된 문화와 철학이 소프트웨어 개발에도 영향을 주기 시작했다란 것이다.
품질은 우리가 경쟁사로부터 살아 남을수 있는 마지막 기회이다.
- 잭 웰치
더자세한 이야기 : https://steemit.com/kr/@loum/w
...
폭포수 모델의 변종인 소용돌이 모델 등에 대해서도 살펴보고 있다있다 나아가 폭포수 모델을 극복하기 위한 프로토타이핑 등 대안적 모델을 정의하고 찾아간다.애자일 인식의 뿌리가 되는 고서이며
폭포수모델의 문제를 해결하기위해, 폭포수 모델을 이해 해야하는것은 당연하다.
고약한 문제는 해결책이 문제의 공간 안에 있는 문제를 일컫는다. 즉 문제가 완전히 풀려야 비로소 그 문제가
무엇인지 완전히 이해되는 그런 문제다. 반면 그 반대편에는 합당한 문제가 있다. 합당한 문제는 정의할 수 있
고, 이들에 대한 데이터를 수집해서 분석할 수 있으며, 해결책을 낼 수 있는 문제다. 마치 폭포수 모델의 시원한
절차처럼 말이다.
소프트웨어 개발 프로젝트에서 어떤 결과를 내는 데 필요한 정보를 제공하거나 체계화하는 것은 컴퓨터가 중심
인 것처럼 보이지만 사실 사람이 중심에 서 있다. 그리고 태생적으로 야기되는 불확실성의 문제는 그 정형성을
이루는 데 반드시 있어야 하는 객관적이고 명료한 기준을 세우기 어렵게한다.
애자일의 철학도, 기술중심/이익중심도 중요하지만 결국 사람을 중심으로 만들기위한 고급철학도 포함되어 있다.
링크 :
- 서적 : 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
...
이것은 메타인지와 연관이 있다. 탑다운의 정형화된 폭포수모델에서는 대부분의 문제는 중요문제는 상위에서만 정의를 하였다.
반대로 이야기하면, 정보가 거의 없을 초기시점 그러니까 우리가 정보를 가장 모르는 초기시기 숙련된 상위 책임자의
능력이 대단해야 했다.
애자일을 하기위해서는 팀구성원 모두가 자체가 메타인지 능력을 사용해야 사용해서 문제인지와 해결방법을 찾아가야 하며, 그것이 역량이
그것 자체가 팀역량이 될수 있다. 여기서 주니어이기 때문에
관련링크 : 메타인지 생각의기술 - IT개발Part - WebNOri
DDD와 애자일
소프트웨어가 일반적으로 복잡해지는 이유는, 우리가 사용하는 기술자체의 복잡성 때문이 아니라
우리가 가진 도메인 자체의 복잡성에 기인하며, 도메인을 중심에 놓고 도메인 전문가 까지
모델을 만드는 단계에 참석을 시키는, 개발문화의 변화와 성숙에 대한 도전 과제로이야기가 이어집니다.
DDD를 하기위해서는 애자일이 필요하다. 애자일이 좋은 소프트웨어를 만들기위한 가치와 마음가짐을 포함
방법론을 이야기한다고 하면 이야기한다고 하면 DDD는 그것을 실천하기위한 구체적인 전략/전술을 이야기한다이야기하며 애자일의 코어영역과 상당수 일치한다.
...
개발방법/프로세스에 얽매이지 않는 Shape UP의 방식을 살펴보는것도 도움이 될것이다.
Basecamp 의 개발 프로세스 - Shape Up 요약정리
...
과거 몇년간 어떻게 작은 팀으로, 높은 품질의 소프트웨어를 그렇게 빨리 개발해내는지 물어보곤 했다. 또, 개발자들을 오랫동안 유지하는지도.
첫째, 우리는 워터폴, 스크럼같은 프로세스에 얽매이지 않았다. 둘째, 우리는 벽에 포스트잇을 줄세우지 않았다. 셋째, 우리는 데일리 스탠드업, 스프린트, 백로그, 칸반, 벨로시티 체킹등 어느 것도 하지 않았다.
우리는 우리의 길을 만들었다.
링크 :
...
제대로 하면 개발자에게 코딩할 시간이 주어지지 않는게 사실입니다사실이며 그것에 엄청난 공을 들입니다.( 퇴근 1시간전에 집중 코딩 필요 )
그리고 칸반보드로 보고를 대체할수 있을까요? 칸반보드는 다시 WBS로 변환되기 까지 합니다. ( 그럴꺼면 WBS만을 잘 사용하기를 권장합니다.)
다음은 애자일의 칸반보드를 잘못사용하는 팀에대한 경고이며, 도메인 주도설계 책에서 언급된 이야기입니다.
( WBS에대한 이야기가 아닙니다. 칸반보드를 폭포수모델에서 했던 WBS의 Task관리와 동일하게 사용하는것에 대한 문제 )
우리는 어떤 설계를 하고 있을까? 우리는 설계대신 "작업 보드 셔플" 이라는것을 진행하게되며
할일과 작업중 그리고 완료로 이어지는 작업의 아이템 변화과정을 지식 집약적인 일의 전부로 여기고
나머지는 프로그래머가 소스를 쏟아내기만 하면 된다라고 생각한다.
이는 잘 드러나지도 않고, 존재하지도 않는 설계에 엄청난 비지니스 비용을 쏟아붓는일이다.
좋은 설계의 다음 대안은 나쁜설계이다. 이 문구의 요점은 설계를 절대하지 않는것에대한 이야기이다.
처음부터 좋은 설계를 할수 없으며, 이것이 좋은지,나쁜지 판단할수가 없다.
나쁜설계를 시도하고, 효율적인 설계를 어떻게 할지 설계에대한 고민을 시작하란의미이다.
설계가 없는것은 지식획득이라는 중요한 것을 놓치고 ,큰 진흙 덩어리를 계속 만들어 내게되며
소프트웨어 개발을 이익중심이 아닌 원가 중심으로 생각하는 비지니스 문화가 확고한 경우 설계문화가
생겨날수 없다란것을 경고도 하고 있다.
Shape Up방식을 단순하게 따라한다고하면 또다른 애자일의 파생을 답습하는것이 될것입니다.
정형화되고 있는 애자일 개발방법론에서 어떻게 탈출해, Shape Up방식을 따라하는게 아닌, 어떻게 자신만의 방식을 만들었는지 연구해볼 필요가 있을것같습니다.
...