원래 폭포수 방식은 한번 진행한 프로세스에 대해서 다시 돌아가는게 없기 때문에 요구 사항이 바뀌지 않아야 됨.
그런데.. 실제는.. 다르지.
ㅇㅇ
댓글 10
이론서에는 워터폴은 요구사항 변경 못한다는 식으로 되어 있는데 실제로는 잘만 바꿈. 그리고 애자일에 retrospective가 집중적으로 언급되기 시작한게 agile retrospective 책 나온 즈음인가? 2008? 실제로는 retrospective는 엄청나게 무거운 프로세스에서 waterfall에서도 가장 강조하고 일반화된 기법임. 아예 공식행사가 잡혀있음.
xx(125.191)2018-04-22 20:32
애자일 책에 있는걸 글자 그대로 믿지 말아라.
xx(125.191)2018-04-22 20:33
ㄴ 결국 마일스톤이랑 단가는 폭포수로 잡는데.. 결국 요구사항 다시 나오면서 그게 일정에 버프로 반영 되어 있지 않으면 개발 실무를 희생시켜서 야근을 강요하게 되는거지.
☎2.80™(roidz)2018-04-22 20:35
ㄴ 결국 프로세스를 안지키면 비용은 발생하게 되어 있는데.. 그걸 누가 부담하느냐 인데.. 고객도 실행측도 안하면 결국 실무자에게 희생을 뒤집어 씌우게 되는거.
☎2.80™(roidz)2018-04-22 20:35
2.80 // 그렇다면 애자일은 어떨까. 요구사항 다시 나오면 애자일은 수가 있을까? 없음
ㅌㅌ(125.191)2018-04-22 20:46
2.80 // 폭포수와 같은 경우는 "계약", "기한"이 정해져 있는걸 감안하고 아예 fp로 산정함. PI, RFP(개발을 원하는 기능이 아예 박혀있음), 착수(RFP에 낸게 맞는지 더 추가될게 있는지 확인하고 조정함), 요구사항 분석(구체화 시켜놓고 확인함). 이런식으로 미리미리 산정하고 달라지면 조정함. 당연히 이후에도 요구사항 추가, 변경되고 그걸 다 조정함.
ㅌㅌ(125.191)2018-04-22 20:48
ㄴ 몇번 반복 루프 돌 것인가 ?랑 어떤 지점에서 통합 배포 진행 마일스톤 잡지 않으면 끝이 없지. 그래서 애자일은 자기 자체 프로젝트할때 쓸만하고.. 스타트업 같이 빠른 자금 회전 필요한 곳에서 많이 하는거니깐 ㅇㅇ
☎2.80™(roidz)2018-04-22 20:49
2.80 // 그리고 애초에 발주하거나 수주할때 fp에 여비를 산정함. 그리고 waterfall에서는 business case라고 해서 단계나 이터레이션 별로 비용에 대한 위험이나 효율화 부분도 진행함. 쓸게 너무 많네. 여튼 waterfall이라고 하는건 생각과 다름.
ㅌㅌ(125.191)2018-04-22 20:52
ㄴ 뭐 실무는 여러 방법론 또는 기존 방법론을 상황 맞게 섞어 쓰는거지 뭐. ㅇㅇ 그런데.. 프로젝트 진행해보면 개발 진행 단계랑 별개로 원래 일정 잡혀진되로 보고하고, 검사할려고 하는 애들이 있다보니.. SI에서는 그런게 문제징. ㅇㅇ
☎2.80™(roidz)2018-04-22 20:53
그래서 제가 어자일 펜인데 client facing 할때는 wagile 로 했습니다. internal = agile external = waterfall 보여주는건 waterfall 로 단가계산
이론서에는 워터폴은 요구사항 변경 못한다는 식으로 되어 있는데 실제로는 잘만 바꿈. 그리고 애자일에 retrospective가 집중적으로 언급되기 시작한게 agile retrospective 책 나온 즈음인가? 2008? 실제로는 retrospective는 엄청나게 무거운 프로세스에서 waterfall에서도 가장 강조하고 일반화된 기법임. 아예 공식행사가 잡혀있음.
애자일 책에 있는걸 글자 그대로 믿지 말아라.
ㄴ 결국 마일스톤이랑 단가는 폭포수로 잡는데.. 결국 요구사항 다시 나오면서 그게 일정에 버프로 반영 되어 있지 않으면 개발 실무를 희생시켜서 야근을 강요하게 되는거지.
ㄴ 결국 프로세스를 안지키면 비용은 발생하게 되어 있는데.. 그걸 누가 부담하느냐 인데.. 고객도 실행측도 안하면 결국 실무자에게 희생을 뒤집어 씌우게 되는거.
2.80 // 그렇다면 애자일은 어떨까. 요구사항 다시 나오면 애자일은 수가 있을까? 없음
2.80 // 폭포수와 같은 경우는 "계약", "기한"이 정해져 있는걸 감안하고 아예 fp로 산정함. PI, RFP(개발을 원하는 기능이 아예 박혀있음), 착수(RFP에 낸게 맞는지 더 추가될게 있는지 확인하고 조정함), 요구사항 분석(구체화 시켜놓고 확인함). 이런식으로 미리미리 산정하고 달라지면 조정함. 당연히 이후에도 요구사항 추가, 변경되고 그걸 다 조정함.
ㄴ 몇번 반복 루프 돌 것인가 ?랑 어떤 지점에서 통합 배포 진행 마일스톤 잡지 않으면 끝이 없지. 그래서 애자일은 자기 자체 프로젝트할때 쓸만하고.. 스타트업 같이 빠른 자금 회전 필요한 곳에서 많이 하는거니깐 ㅇㅇ
2.80 // 그리고 애초에 발주하거나 수주할때 fp에 여비를 산정함. 그리고 waterfall에서는 business case라고 해서 단계나 이터레이션 별로 비용에 대한 위험이나 효율화 부분도 진행함. 쓸게 너무 많네. 여튼 waterfall이라고 하는건 생각과 다름.
ㄴ 뭐 실무는 여러 방법론 또는 기존 방법론을 상황 맞게 섞어 쓰는거지 뭐. ㅇㅇ 그런데.. 프로젝트 진행해보면 개발 진행 단계랑 별개로 원래 일정 잡혀진되로 보고하고, 검사할려고 하는 애들이 있다보니.. SI에서는 그런게 문제징. ㅇㅇ
그래서 제가 어자일 펜인데 client facing 할때는 wagile 로 했습니다. internal = agile external = waterfall 보여주는건 waterfall 로 단가계산