[💻 코드스테이츠 FE 44기] 소프트웨어 개발 방법론

✔️ 시작

대표적인 소프트웨어 개발방법론인 워터폴과 애자일 방법론이 무엇인지 학습했다.
이번 솔로 프로젝트를 5일 동안 진행하는데 그 때 애자일 방법론을 구체적으로 실현하기 위해 준비 운동을 했다.

---

📍 배운 것

소프트웨어 개발 방법론

• 소프트웨어 개발에 대한 체계적인 접근 방식을 의미
• 소프트웨어 개발 과정에 필요한 단계, 활동, 산출물, 순서 등을 정의하고 설명한다.

소프트웨어 개발 방법론의 일반적 단계

1. 요구사항 분석

• 소프트웨어가 해결해야 할 문제와 고객의 요구사항을 파악하고 정의하는 단계
• 다양한 이해관계자 간에 상충할 수 있는 요구사항을 고려해 새로운 제품이나 변경된 제품에 부합하는 요구와 조건을 결정하는 단계

기능 요구사항, 비기능 요구사항

2. 설계

• 소프트웨어의 구조와 기능, 인터페이스, 알고리즘 등을 대략적으로 설계하는 단계

시스템 구조 설계, 프로그램 설계, 사용자 인터페이스 설계

3. 구현 또는 코딩

• 설계한 내용을 프로그래밍 언어로 작성해 실제로 동작하는 소프트웨어를 만드는 단계
• 프로그래밍 언어 선택, 기법, 스타일, 순서 등을 결정하는 단계

인터페이스 개발, 자료구조 개발, 오류 처리

4. 테스트

• 구현 단계에서 만들어 낸 소프트웨어가 오류나 결함 없이 예측했던 대로 동작하는지 검증하는 단계

단위 테스트, 통합 테스트, 시스템 테스트, 인수 테스트

5. 유지보수

• 시스템이 인수되고 설치된 후 일어나는 모든 활동을 의미
• 배포된 소프트웨어의 성능을 개선하거나 새로운 기능 및 요구사항을 정의하고, 변화에 대응해 수정 및 업데이트 하는 등 배포 후 일어나는 모든 과정

예방, 완전, 교정, 적응 유지보수

대표적으로 사용되는 소프트웨어 개발 방법론

폭포수 모델(Waterfall Model)

• 타당성 검토->계획->요구사항 분석->설계->구현->테스트->유지보수 순으로 단계 진행
• 가장 전통적이고 오래된 모델
• 각 단계는 순차적으로 진행되고, 이전 단계가 완료 되어야 다음 단계로 넘어갈 수 있다.

장점

• 모델 적용 사례와 성공 사례가 가장 많다.
• 단계별 정의와 산출물이 명확하다.

단점

• 요구사항 변경에 대한 대처가 어렵다.
  (요구분석, 기획 단계에서 진행했던 일련의 과정들이 고객의 요구를 100% 충족하기 힘들다는 것)

계획이 명확하고 변경이 적은 프로젝트에 적합하다.

애자일 모델(Agile Model)

• 고객의 피드백을 빠르게 반영하고 잦은 변화에 유연하게 대응하는 모델
• 작은 단위로 개발하고 테스트 하며 지속적으로 개선하는 모델
• 사용자의 요구사항 일부분 혹은 제품의 일부분을 반복적으로 개발해 최종 시스템으로 완성하는 모델

요구사항이 자주 바뀌고 협업이 많이 필요한 프로젝트에 적합

소프트웨어 개발 방법론 선택 시 고려 사항

1. 프로젝트의 특성

• 프로젝트의 목적, 규모, 복잡도, 기간, 예산 등을 모두 고려해 적절한 모델을 선택
  - 폭포수 모델 : 명확하고 안정적, 변화할 여지가 적은 요구사항, 단순한 프로젝트
  • 애자일 모델 : 불확실, 요구되는 기능에 변화가 일어날 가능성 높은, 잦은 변화가 일어나고 복잡한 프로젝트

2. 고객 참여도

• 고객이 프로젝트에 얼마나 관여하고 피드백을 제공할 수 있는지 고려
  - 폭포수 모델 : 고객이 최초 목표 수립과 요구사항 제시 이후에 프로젝트와 밀접하지 않고, 상대적으로 소극적 참여
  • 애자일 모델 : 고객이 프로젝트와 아주 밀접하게 있거나, 빠르고 잦은 피드백을 원한다면

3. 팀의 역량과 문화

• 팀의 인원 수, 역할, 책임, 기술 수준, 협업 방식 등을 고려해 적절한 모델 선택
  - 폭포수 모델 : 팀의 규모가 크고, 계층 구조, 상대적으로 낮은 기술 수준과 협업이 중요하지 않은 환경
  • 애자일 모델 : 팀의 규모가 작고, 자율적, 상대적으로 높은 기술 수준과 협업이 잦은 환경

이번 솔로 프로젝트는 애자일 모델로 진행한다.

등장 배경

문서에 의존하기 보다는 코드 지향적으로 효율적인 개발을 지향하는 목적에서 탄생

• 요구사항이 변화하는 것을 당연한 전제로 두고, 변화하는 요구사항에 민첩하게 대응하며 개발을 수행하는 소프트웨어 개발 방법론
• 스크럼(Scrum), 익스트림 프로그래밍(XP), 칸반(Kanban) 등 좋은 것을 빠르고 낭비없게 만드는 다양한 방법론

절차보다는 사람이 중시되어 변화에 유연하고 신속하게 대처하면서 효율적으로 빠르게 시스템을 개발할 수 있는 방법론

폭포수 방법론은 요구분석부터 기획, 개발, 테스트, 출시까지 순차적으로 진행하여 마치 폭포가 떨어지는 식으로 순차적인 단계를 밟는 전통적인 개발 방법론

스크럼(Scrum)

스프린트 작업 단위를 부여하며 스프린트는 보통 2주를 기준으로 하고, 팀의 특성에 맞춰 줄이거나 늘릴 수 있.

1. 해당 스프린트 기간 동안 작업할 수 있는 개발자 개개인의 시간들을 모두 합쳐 총 작업시간을 책정하고, 스프린트 동안 할 작업들을 추산하는 플래닝
   2.플래닝은 PO(product owner), 스크럼 마스터(Scrum Master), 개발자가 참여하여 플래닝 포커를 통해 진행(작업 소요 시간 정하기)
2. 스프린트 진행하기 (Backlog >> Todo >> Done, 이슈가 있을 때 In progress로 이동)
3. 작업에 대한 회고 진행 (스프린트를 진행한 후 스프린트 마지막날 스프린트 기간 동안 진행한 작업들을 플래닝 내용을 가지고 회고)

관리자 페이지 개발보다는 관리자 페이지 내 회원가입기능 중 이메일 인증 부분 개발이 더 작은 단위로 분리되었다고 할 수 있다.

칸반(Kanban)

• 핵심 : WIP(Work In Progress) 제한
• 스크럼의 스프린트 처럼 정해진 업무 종료일이 없다.

스크럼과 마찬가지로 새롭게 들어온 이슈카드에 대해 시간을 추정하는 작업한다.
스크럼과는 달리 플래닝을 하는 날이 따로 정해져 있지 않고 매일 적은 시간을 투자해 진행되는 데일리 미팅에서 새롭게 들어온 이슈카드의 기능을 구현하기 위한 요구사항을 분석하고 시간이 얼마나 걸릴지 플래닝을 진행한다.

어느 상태에 선택?

스크럼

프로젝트같은 종료일이 정해져야 하는 업무가 많이 발생하는 경우

칸반

지속적인 업무를 다루며 프로젝트 개발 및 Ops까지 함께 다뤄야 하는 상대적으로 작은 단위의 팀

Hotifx

• 지금 당장 수정해서 실제 돌아가는 Production 서비스에 바로 배포를 내보내야하는 플래닝 시점에 미리 예측되지 않았던 긴급한 버그나 오류 이슈를 말한다.

스크럼에서 HotFix는 해당 스프인트에 절대! 넣지 않는다.

기본적으로 아주 매출에 직접적인 영향을 미치는 Top Priority급 Hotfix가 아니라면,
스프린트 진행 중 발생하는 모든 Hotfix는 무조건 다음 스프린트의 백로그로 쌓이게 되고 다음의 스프린트의 업무가 된다.

칸반에서는 HotFix 또한 바로 프로젝트 backlog에 쌓는다.

• 쌓여진 Hotfix를 바로바로 처리할 수 있다.
• 해당 프로젝트를 끝내기 위해 처리해야 할 이슈카드로 동일하게 취급
• 언제까지 마무리 지어야하는지 정해지지 않아서 가능한 일

---

✏️ 마치며

이번 개인 프로젝트는 5일동안 진행되며
예전 과제와는 다르게 처음 부터 끝 까지 일정을 정리하고 기록한다.

여기서 배워야하는 점은
현업에서 어떤 식으로 프로젝트를 진행하고
어떤 단위로 나눠 시간을 분배 하는 것이다.

무엇 보다 정해지 기간 안에 본인이 맡은 업무를 전부 끝낼 수 있느냐가 아닐까 싶다.

프로젝트에 있어 기획 단계도 중요하지만 마감 시간을 지킬 수 있는거냐가 아닐까 싶다.