소프트웨어 프로세스는 프로젝트의 작업 순서, 구조, 기능 등 다양한 것을 포함하고 있다.
이런 과정을 체계화시켜 소프트웨어 프로세스 모델, 소프트웨어 개발 생명주기(SDLC)라고 한다.
애자일은 반복적이고 점진적인 개발 및 테스트에 중점을 둔 프로젝트 관리 원칙이다.
애자일은 대규모 프로젝트를 관리 가능한 작은 단위의 작업으로 나누고, 개발 내용을 즉시 테스트할 수 있도록 한다.
애자일 팀은 클라이언트와 긴밀하게 소통하며 클라이언트의 요구 사항을 수집하고, 작은 단위의 중요한 작업을 신속하게 수행한다. 그 결과를 클라이언트 및 이해 관계자와 바로 확인할 수 있어 즉각적인 피드백으로 다음 사이클을 준비하게 된다.
클라이언트는 백로그 우선순위에 대한 의견을 제시하는 등, 제공되는 새로운 기능에 대해 다양한 제안을 할수 있다. 이러한 의견은 애자일 팀이 최종 사용자에게 가장 높은 우선순위를 나타내는 작업 항목에 주력할 수 있게 하므로 큰 도움이 된다. (고정 가격 계약에서 가장 힘들어 하는 부분이기도 하다.)
애자일 방법론의 또 다른 핵심 요소는 광범위한 문서화보다는 사용 중인 소프트웨어에 집중하는 것이다. 문서화하지 않으면 신규 직원이 업무에 어려움을 겪을 수 있지만, 애자일 팀은 개발에 필요한 리소스를 생성하는 데 더 많은 시간을 할애할 수 있으므로 변화에 빠르게 대응할수 있고, 배포도 빨라진다.
애자일은 일반적으로 소프트웨어 개발에 사용되지만, 애자일 개념은 다양한 업계와 팀에서도 활용할 수 있다.
애자일 중심의 기업은 점진적인 개선, 대면 회의, 부서 간 협업을 장려하는데, 이는 마케팅 팀, 대학교, 심지어 군대에서도 애자일이 유용한 이유이다.
https://www.pm-partners.com.au/insights/the-agile-journey-a-scrum-overview/
스크럼은 제품 출시 시간을 단축하기 위한 애자일 원칙중 하나이다. 애자일 원칙을 따르는 데 도움이 되는 실행 가능한 프레임워크라 할 수 있다.
스크럼은 애자일을 이상적으로 가능하게 하는 규칙과 팀 역할을 정의한다.
개발자는 1~4주 단위의 ‘스프린트’로 작업합니다. 이때 팀은 광범위한 프로젝트나 목표에 기여하는 작은 단위의 작업을 수행한다. 최종 사용자의 우선순위에 맞도록, 모든 스프린트가 시작될 때 검토 및 수정 가능한 내외부 팀의 제품 백로그에서 각 작업을 가져온다. 스크럼 스프린트는 ‘애자일 스프린트’로 널리 알려져 있을 정도로 유용한 관리 툴입니다.
스크럼 팀에는 스크럼 마스터, 프로덕트 오너, 개발 팀으로 구성된다.
프로덕트 오너는 개발 팀에 작업을 지시하고, 새로운 기능에 대해 상세히 요청하며, 완료된 작업이 요구 사항과 표준을 충족하는지 확인.스크럼 마스터는 스프린트 계획, 제품 데모, 회고, 데일리 스탠드업 미팅을 주최한다. 프로덕트 오너가 제시하는 백로그의 스토리포인트를 팀과 함께 추정한다.개발 팀은 각 스프린트의 결과를 프로덕트 오너에게 제시.스프린트 시작전 스프린트 계획미팅을 진행한다. 이번 스프린트에 진행할 백로그를 제품백로그로 부터 선정하고, 스토리포인트를 추정한다. 이를 통해 계획을 세밀하게 조정한다.
스프린트 기간중 팀은 데일리 스탠드업 미팅을 통해 어제 한 일, 오늘 할 일, 업무 방해 요소를 검토한다.
스크럼 리더는 성과가 좋았던 작업과 다음 스프린트에서 개선할 수 있는 작업에 대해 논의하는 스프린트 회고 미팅을 진행한다. 새로운 스프린트가 시작될 때 팀은 스프린트 계획 미팅을 통해 스프린트 계획을 공유하며 다음에 수행할 작업을 설정한다.
스크럼의 체계적인 프로세스를 통해 모든 직원은 동일한 문서를 공유하고, 클라이언트는 정의된 일정에 맞게 원하는 결과를 얻는 것은 물론, 변화에 빠르게 대응할 수 있도록 한다.
| 용어 | 설명 |
|---|---|
| 스프린트(Sprint) | 스크럼에서 사용되는 일정 기간(보통 1~4주) |
| 스프린트 백로그(Sprint Backlog) | 해당 스프린트에서 완료해야 할 작업을 우선순위에 따라 정리한 목록 |
| 제품 백로그(Product Backlog) | 제품의 모든 요구사항을 우선순위에 따라 정리한 목록 |
| 스크럼 마스터(Scrum Master) | 스크럼 프로세스를 관리하고 팀이 스크럼의 원칙을 따르도록 지원하는 역할 |
| 프로덕트 오너(Product Owner) | 제품 개발 프로젝트에서 고객 또는 사용자와의 의사소통을 중개하고 제품의 우선순위를 결정하는 역할 |
| 개발팀(Development Team) | 제품을 개발하는 역할을 하는 팀 |
| 스프린트 계획 회의(Sprint Planning Meeting) | 스프린트를 진행하기 전, 해당 스프린트에서 완료해야 할 작업을 선정하는 회의 |
| 데일리 스크럼 회의(Daily Scrum Meeting) | 매일 진행되는 짧은 회의로, 진행 상황과 문제를 공유함 |
| 스프린트 리뷰 미팅(Sprint Review Meeting) | 해당 스프린트에서 개발한 제품의 작동 여부를 검증하는 회의 |
| 스프린트 회고 미팅(Sprint Retrospective Meeting) | 해당 스프린트에서 진행한 프로세스와 문제점을 검토하고 개선점을 도출하는 회의 |
| 스크럼 이벤트(Scrum events) | 스크럼 프로세스에서 일어나는 이벤트로서 스프린트 계획 회의, 데일리 스크럼 회의, 스프린트 리뷰 미팅, 스프린트 회고 미팅 등이 있다. |
스크럼과 마찬가지로, 칸반(Kanban)도 애자일 방법론의 한 유형.
칸반은 시각적 워크플로우를 통해 팀의 진행 상황을 공유한다. 칸반 보드에서 각 작업은 카드 또는 포스트잇으로 표현한다. 그리고 보드에는 작업 상태를 나타내는 열이 있다. 카드는 해당 작업이 완료되어야 다음 열로 이동한다.
칸반은 일정량의 작업을 스프린트로 가져오는 스크럼과 달리, 각 열에 포함할 수 있는 최대 카드 수를 설정한다.
팀이 이미 그 할당량을 충족했더라도 진행 중인 작업이 완료될 때까지는 프로젝트 백로그에서 추가 작업을 가져올 수 없다. 그러므로 팀원 모두가 현재 백로그 완료에 투입되기도 한다.
스크럼과 달리, 칸반은 프로젝트 팀의 역할과 스프린트, 팀 회의를 사전에 정의하지 않는다.
하지만 많은 칸반 팀이 데일리 스탠드업 미팅을 진행하고 있다. 칸반 팀원은 서로 협업하며, 필요에 따라 작업을 전달하는등, 어려움이 있을 때 서로 지원할 수 있다.
애자일 소프트웨어 개발 방법론 중 하나로 ‘개발자 중심의 방법론’을 의미한다.
고객과 개발자가 함께 일하며 고객이 원하는 기능을 우선순위에 따라 작은 단위로 나누어 개발을 한다.
이를 통해 고객의 요구 사항을 빠르게 반영하고 문제가 발생했을 때 빠르게 대처할 수 있다.
익스트림 프로그램은 페어 프로그래밍, 테스트 주도 개발, 지속적인 통합, 단순한 설계, 적극적인 리펙토링등 다양한 실천 방법을 이용하고 있다.
| 실천 방법 | 설명 |
|---|---|
| Pair Programming | 두 명의 프로그래머가 함께 작업하여 코드를 작성하는 방법. |
| 한 명이 코드를 작성하고, 다른 한 명이 코드를 검토하고 지속적인 피드백을 제공하며 협업한다. | |
| Unit Test + TDD | 소프트웨어의 작은 부분인 유닛에 대한 테스트를 수행. |
| 유닛 테스트는 개별 함수 또는 모듈이 예상대로 작동하는지 확인하는 데 사용한다. | |
| Pair Negotiation | 두 명의 사람이 함께 협상하여 문제를 해결하고, 결정을 내리는 과정. |
| 각각의 의견을 고려하며 협업하여 최선의 결론을 도출. | |
| Stand-up Meeting | 팀 구성원들이 매일 짧은 시간 동안 서로의 진행 상황과 장애물을 공유하는 미팅. |
| 팀의 커뮤니케이션과 협업을 도울 수 있는 기회를 제공한다. | |
| Acceptance Test | 소프트웨어가 요구사항을 만족하는지 확인하는 테스트. |
| 사용자의 관점에서 시스템을 검증하며 사용자 승인을 받을 수 있는지 확인한다. | |
| Iteration Plan | 작은 주기로 소프트웨어를 개발하는 방법. |
| 각 이터레이션은 목표와 일정을 설정하고, 해당 이터레이션 동안 필요한 작업을 계획한다. | |
| Release Plan | 소프트웨어 제품을 출시하기 위한 계획. |
| 기능 및 버그 수정 등의 작업을 포함하여 출시 일정과 전략을 계획한다. |
KPT는 각각 Keep, Problem, Try 3가지 관점에서 업무를 돌아보고, 다음 액션 아이템을 도출하는 템플릿.
Keep 프로젝트에서 만족했고, 앞으로의 업무에서 지속하고 싶은 부분Problem 프로젝트에서 부정적인 요소로 작용했거나 아쉬웠던 점Try Problem에 대한 해결 방식으로 다음 프로젝트에서 시도해볼 점무엇보다 KPT에서 중요한 관점은 Try이다. 이번 프로젝트에서 아쉬웠던 점을 Try를 통해 어떻게 보완할 수 있을지 정리해보면서 구체적인 실천 방안을 세울때 좋은 효과를 발휘한다.
인프런 팀
KPT 프로젝트 회고 예시
Fact 사실: 무슨 일이 있었나?Feeling 느낌: 무슨 느낌이 들었나?Finding 배운 점: 어떤 인사이트를 얻었나?Future action 향후 행동: 앞으로 무엇을 해야 할까?Feedback 피드백: 앞서 정한 향후 행동을 실천해본 뒤, 이에 대해 어떤 피드백을 받았나?특히 5F는 개인이 한 활동을 회고하는 데 유용하다.
어떤 일이 있었고 무엇을 느꼈는지를 시간 순서대로 정리하는 데 도움이 되는 편이다.
4L은 특정 활동에 대해 느낀 생각과 경험을 중심으로 회고를 진행
Liked 좋았던 점Lacked 아쉬웠던 점Learned 배운 점Longed for 앞으로 바라는 점4L 역시 여러 상황과 여건에 적용해볼 수 있지만, 협업 프로젝트 진행 과정의 특정 지점(마일스톤)에서 구성원들과 중간 점검을 할 때 유용하다.
아이디어 도출 및 평가를 위해 고안된 방식