Page History

...

할일을 생성하고 완료로 옮기는일은 폭포수모델이나,스커럼,애자일등 모두가 

Task를 관리하는 기본적인 방법이다. 

완료로 옮기기위한 활동만을 우아하거나 고급스럽게 엄청난 시간들들여 하는것을 수없이 봐왔다. 

이것만 하는것은 소프트웨어를 만드는 중요한 기법들을 모두 무시하는것이다.

 

"올바르게 만들어지고 있는가?"  VS "완료되었는가?"

WBS,칸반보드등 올바르게 만들어지고 있는가? 에 관심을 가지는경우를 거의 보지 못하였다. 

 

스크럼을 최근 도입한 팀이, 엑셀WBS보고서를 탈출하고자 , 지라의 자동보고서를 어떻게 잘구축하였다.

유져스토리를 먹기좋게 가로로 자르냐? 세로로 자르냐? 고민을 했고 결국 자동 보고서와 호환이 되지 않아

먹기좋은 형태가 아닌, 보고서에 잘나오는 형태로 자르게 되었다. ( 기본기능으로 지라는 이부분에대해 아무것도 하지못한다. - 유료 JPQL쿼리로 어떻게 될수는 있다. )

결국 일을 잘할수있는 작업자 중심이 아닌~ 보고하기 용이한 단위로 쪼게어 진다.  

이것에대한 문제는 폭포수모델과 상관없어보인다. 
참고링크 : 

https://www.humanizingwork.com/the-humanizing-work-guide-to-splitting-user-stories/

https://www.visual-paradigm.com/scrum/user-story-splitting-vertical-slice-vs-horizontal-slice/

 

...

• 사시미 : 개발속도와 유연성을 중요시한 일본에서 폭포수를 경험하면서 만든 모델(하향식절차를 간소화하고 약간씩 겹치게만듬, 개인적으로 애자일 인식의 시초라고 보여집니다. )
• 스크럼 : 사시미에서 한번 더 나아가, 하나로 뭉침  (럭비시 밀집하는 모양에서 유려 유례, 럭비공 모양이 됨 )

중요결정과 책임이 점점 수평화되어 갑니다.

하향식접근 방식이 아닌, 중첩이 되며 더 많은 피드백및 수정을 할수있게됩니다.

피드백을 주고받으며 완성해나가기때문에, 훨씬많고 적은 단위의 일이 계속 발생할수 있습니다. 

...