기획(어떤 것을 만들지 정하는 단계 )->개발(기획한 것을 만드는 단계)-> 테스트(개발이 기획대로 잘 되었는지 확인하는 단계)->배포(개발된 제품/서비스를 사용자가 사용하는 단계)->유지/보수(출시된 서비스를 변화 시키는 단계)
하나의 소프트 웨어를 출시하기 전까지는 다양한 사람들이 함께 일하게 되는데 여러사람이 모여 일하다 보니 의사소통에 문제가 생길수있고 소통이 쉽지 않다. 그래서 사용하는 가장 유명한 방식이
agile 방식과, waterfall 방식이다.
waterfall(폭포수)방식은 고전적인 방식으로 각 단계를 완료하고 다음 단계로 넘어가는 방식으로 이해하기가 쉽고 관리하기가 쉽다!,
1.기획: 기획자가 필요한 것을 문서로 작성
2.개발: 문서를 받아 프로그램을 제작
3.테스틔: 프로그램이 잘 작동하는지 확인
4.배포: 프로그램을 사용자가 사용 할 수 있도록 공개
5.유지/보수: 오류개선 및 추가적인 기능개발
하지만 만들고자 하는게 복잡해질 경우 각 단계를 한번에 완벽하게 끝내기가 힘들 수 있다. 예를 들어 기획에서 아무리 상세하게 문서에 모든걸 기록해도 프로그램이 복잡하면 의도한대로 오나벽히 전달되지 않을수도 있는데 의도하지 않은 방향으로 진행되어도 다음 단계로 넘어가기 전까지 그 문제를 발견할수 없다. 프로그램은 하나씩 기틀을만들고 쌓아가는 작업이다보니 완성되니 후에 결과물을 바꾸려면 실제 코드의 많은 부분을 갈아 엎어야한다. 이런 문제를 해결하기위해
agile 방식인데
잘못된 방향으로 넘어가기전에 제빨리 결과를 만들어서 미리 확인하고 고치면서 진행하는거다.
전체프로그램을 한번에 만드는 대신 프로그램을 적당한 크기의 기능으로 나누고 각기능에 대해 문서가아닌 실제동작하는 소프트웨어로 확인하면서 서로 소통한다.
이렇게 되면 잘못된걸로 멀리가지않고 기획자들도 자기가 상상한대로 가는지 확인하고 의견을 덧 붙일수있다.
기획할 때는 생각하지 못했지만 직접 써보면서 나오는 의견들도 그때 그때 수정하고 추가할 수 있다는 장점이 있다.
waterfall 방식은 이미 개발이 완료된 이후에 여러 수정사항 변경사항드링 생기면 개발자들은 전체코드를 뒤 엎어야 하는 경우도 있는데 agile 방식은 중간중간 사용하면서 발전시키기 때문에 기능 변경이 유연하게 대처할수있다.
서비스든 제품이든 복잡해지고 변화주기도 짧아진 요즘 기능변경이 유연한 agile방식이 적합한 때가 많다.
하지만 무조건 agile 방식이 옳고 waterfall 방식이 그른것은 아니다.
팀문화나 제품의 성격에 따라 waterfall 방식이 효율적일 수 있다. 프로그램의 기획이나 개발등 단계가 복잡하지 않다면 waterfall 방식도 좋은 선택이다
agile 방식은 동작하는 프로그래믕로 만들어서 소통하고 추가로 개발하고 소통하고 이런식으로 개발하다보니 폭포수 방식보다 관리가 어려워지는데 이 방식에서는 각기능을 쪼개고 그 안에서 소통하고 하다보니 훨씬 규모가 커지고 복잡해진다.
그래서 장점만 뽑아서 이 두 협업방식을 섞어 쓰기도한다.
결론은 그냥 회사 분위기 업무 분위기 따라서 잘쓰면 된다.. 그러니 옆사람 어떻게 하는지 잘 보고 파악하다는게... 중요하다구
