아기곰푸우 :: 애자일

애자일

Scrum, kanban, XP(eXtreme Programming)와 같은 애자일 소프트웨어 개발 프레임워크는 DevOps 및 CI/CD(지속적 통합/지속적 배포)와 같은 대중적인 소프트웨어 개발 프로세스의 기반을 형성합니다.

스크럼

솔루션에 포함할 기능/개선점에 대한 우선 순위를 부여한다.
개발 주기는 1~4주 정도로 하고 개발 주기마다 실제 동작할 수 있는 결과를 제공하라.
(설명:너무 짧으면 개발(분석/설계/개발/테스트) 할 수 있는 시간이 부족하고, 너무 길면 느슨해지고 재작업의 양도 늘어나므로 적용해보면서 필요시 조율 필요)
개발 주기마다 적용할 기능이나 개선에 대한 목록을 제공하라.
(설명:해당 주기의 Goal을 작성하지 않으면 목적을 잃은 기능 목록이 될 수 있음)
매일 15분 정도의 Scrum meeting 회의를 가져라.
(설명:공유이지 보고하는 자리가 아니다. 교과서적으로 Scrum meeting은 개발팀원만 참여해야하고, 팀원이 아닌 사람은 발언기회는 없다고 한다. 개인적인 생각으로는 수평문화가 되어 있는 Agile Culture의팀이라면 PO 및 관리자가 함께 참석하여 공유하면 좋다고 생각한다. 이들도 참석한다면 이 프로젝트와 관련되어 한일/할일/이슈를 공유해야 한다. 안그러면 한팀이 아닌 관리자 모드로 돌아선다.)
항상 팀을 우선으로 생각하라.
(설명:자신의 task보다 주변 이슈가 더 급하면 도와줘야 한다. 마치 배에 구멍이 나면 그 문제 해결이 1순위이다.)
원활한 의사소통을 위하여, 구분 없는 열린 공간과 마음을 유지하라.

분석, 설계, 개발, 테스트 반복

폭포수 모델중 일부를 반복

사용자 스토리(User Story) : 과거 요구사항 명세처럼 업무 범위를 구체화하기 위한 개발자 입장이 아닌, User Story는 사용자가 사용하는 관점에서 어떤 가치를 제공할 것인지를 설명
(해설 : PO는 이 기능이 누구에게 무슨 value를 제공하는지를 설명하고, 향후 개발자는 그 기능의 Value를 제공하기 위한 기술적인 역할과 책임을 가짐)

완료 기준(Definition of Done), 인수 기준(Acceptance Criteria) : 사용자 스토리를 완료시키기 위한 조건 명세(Given, When, Then)

잠재적 출시 가능 제품(Potentially Shippable Product Increment) 또는 최소 실행 가능 제품(Minimum Viable Product, MVP) : 팀이 최소 노력으로 고객에게 검증 결과를 받을 수 있는 수준의 제품

스프린트 계획 회의(Sprint Planning Meeting) : 스프린트 목표와 스프린트 백로그를 계획하는 회의(4주 스프린트 기준 8시간 정도 수행)

칸반 보드(Kanban Board) : 작업을 시각적으로 업무 상태, 흐름을 보여주는 게시판
일일 스크럼 회의(Daily Scrum Meeting) : 매일 어제 한일, 오늘 할일, 해결해야 할 장애/문제 요소를 공유하는 회의(매일 15분 정도 수행)
스프린트 리뷰(Sprint Review) : 스프린트 마지막날 개발자가 개발한 내용을 Stakeholder, 고객, 제품 책임자에게 시연하고 검토(4주 스프린트 기준 4시간 정도 수행)
스프린트 회고(Sprint Retrospective) : 스프린트 마지막날 좋았던 점, 개선할 점을 도출하고 더 나은 방향으로 개선(4주 스프린트 기준 3시간 정도 수행)

Posted by 아기곰푸우