[2019-08-27] 애자일에 관한 세션을 들었다.

telnet turtle·2022년 11월 25일
0

1:30-3:30 오후, 애자일에 관한 사내 세션을 들었다. 개인용으로 정리한 내용이고 키워드 위주로만 적었지만, 일부 수정해서 공개해본다.


목차

전통적인 개발방법론

애자일

XP

SCRUM

애자일의 오해


전통적인 개발방법론

  • 폭포수 모델
  • 나선형 모델

문서

SRS: SW Requirement Specification

SDS

WBS ~= backlog

워터폴

req -> design -> imp -> verification -> maintenance

그 고객과 디자이너와 개발자와 비즈니스 그네 그림

커뮤니케이션을 못해서 이렇다.

애자일이란

SW 개발 방법, 무계획과 지나치게 많은 개발 사이에 타협을 찾는 방법

애자일 선언

“xx보다 ㅁㅁ을” 그 문장들

https://agilemanifesto.org/

12가지 원칙

  1. 가치있는 sw를 일찍 지속적으로 전달해서 고객을 만족시키는게 우리의 최우선
  2. 비록 개발의 후반부일지라도 요구사항 변경을 환영하라
  3. 작동하는 소프트웨어를 자주 작성하라
    1. 고객에게 자주 전달해서 확인받아라
    2. 너무 많은걸 작성해서 전달했다가
  4. 비즈니스 쪽의 사람들과 개발자들은 프로젝트 전체에 걸쳐 함께 일해야 한다
  5. 동기 부여하고 환경과 지원을 주고 그들이 일을 끝내리라고 신뢰하라
  6. 정보를 전하는 가장 효율 효과적인 방법은 면대면 대화다
  7. 진척의 주된 척도는 작동하는 소프트웨어
  8. 애자일 프로세스는 지속 가능한 개발을 장려한다. 일정한 속도를 계속 스폰서, 개발자, 사용자는 유지할 수 있어야 한다.
  9. 기술적 탁월성, 좋은 설계에 대한 지속적 관심 -> 기민함을 높인다 안 하는 일의 양을 최대한 기술 - 단순성 - 필수다.
  10. 최고의 아키, 요구사항, 설계는 자기 조직적인 팀에서 창발한다
  11. 자기 조직적이란게 무슨 말일까
  12. 팀은 정기적으로 어떻게 더 효과적이 될지 숙고하고, 이에 따라 팀의 행동을 조율하고 조정한다.

애자일을 하는 방법

XP와 스크럼의 장점을 혼합한 방법을…

XP

여러가지, 효과 좋은, 프랙티컬한 방법을 극한으로 실천하는 것

예시가 없으니 이해가 안됨

이건 그냥 특정 상황에서 쓰는 극단적일수도 있는 예시일까?

특징

  • 5~10 개발자 고객과 함께 한 장소에서 개발한다.
  • 점진적 개발, 각 단계마다 산출물의 기능을 덧붙여나감
  • 요구사항 명세를 사용자의 스토리 형태로 구체적으로 작성한다.
  • 개발자는 코딩 규칙을 준수하고 Pair TDD 개발한다.
  • 요구사항, 아키, 디자인은 플젝 중간에 언제든지 생긴다.
  • 주, 분기 단위 일을 계획하고, 지난 기간 진행상황을 검토한다.

이터레이션, 스몰 릴리즈.

다섯 가지 가치

커뮤니케이션

문제를 이미 해결법을 알고있는 경우가 많다.

문제 해결법이 당사자에게 전달 안 되는 경우가 만다.

단순성

피드백

용기

문제가 뭔지 안다면 그거에대해 뭐든 해보는 것

자기가 알고 있는것을 오픈하는것

존중

팀원의 기여를 존중하는것

원칙

인간성 경제성 상호 이익 자기 유사성 다른 원칙들

중복 Redundancy 어떤 문제에 중복되지만 여러 해결책을 만들어 놓으면 그중에 하나가 해결책이 될 수 있지

실패

품질 은 양보할 수 없다

잔걸음 → 이터레이션, 스몰 릴리즈

수용된 책임감 (Accepted Responsibility) 책임을 주면 권한도 주고

실천 방법 (프랙티스)

함께 앉기

하나의 팀

informative workspace - JIRA, WIki

열정적인 작업

질답

redacted

redacted

redacted

redacted

스크럼

특징

  • 팀을 운영하는 효율적인 운영 방식

이론

  • 투명도
    • 프로세스를 언급하는 내용, 참여자에게 공유
  • 검사
    • 자주 검사
    • 검사가 너무 잦아서 개발에 방해가 되지않도록
  • 적응

가치

  • 용기
  • 집중력
  • 헌신
    • 약속한 것을 실현하는것
  • 존중
    • 자신과 다른 의견을
  • 개방성
    • 자신이나 팀에게 불리하더라도 숨기지 않고 오픈하는것

프로세스

[스크럼 프로세스 그림]

스크림 팀

프로덕트 오너

  • 사용자 역할을 대변한다
  • 스토리 정의한다
  • 개발팀이 수행하는 업무의 가치를 최적화한다
  • 백로그 항목을 개발팀이 이해하도록 설명한다
  • 릴리즈 타이밍을 관리한다
  • 이해관계자의 의사소통을 돕는다

개발팀

  • 5-7명
  • 전문가
  • 팀 안에서 모든 문제를 해결할 수 있어야한다

스크럼 마스터

  • 서포터
  • 스크럼 팀 모든 사람이 이해하게 해준다 - 목표, 범위, 제품 도메인
  • 개발팀에 있는 방해 요소를 제거한다
  • 효과적은 제품 백로그 관리를 위한 기술을 습득한다
  • 경험적 환경에서 하는 제품 계획을 이해한다
  • 프로덕트 오너가 가치를 극대화하기 위해 백로그를 정렬하는지를 확인한다

유저 스토리

  • 제품을 통해 고객에게 특정한 가치를 제공하는 방법을 명확하게 표현한다
  • As a [type of user], I want [some goal], so that [some reason]

스프린트

  • 스프린트 회의에 시간을 제한한다
    • 1주 스프린트 - 2시간
    • 2주 스프린트 - 4시간
    • 1개월 스프린트 - 8시간
  • 명확하고 측정 가능한 결과를 사용자 스토리에 추가
  • 스토리는 에스티메이션 포인트 1-3
  • 3이 넘으면 에픽으로 빼고 에픽에 여러 스토리를 담아준다
  • 새로운 스프린트는 이전 스프린트가 종료된 직후에 시작한다
  • 스프린트 중 품질 목표는 감소하지 않고, 스프린트 목표를 위태롭게 하는 변경은 하지않는다.
  • 스프린트 중 목표가 필요없어진다면 스프린트를 중간에 끝낼 수 있다.

스프린트 계획

  • PO가 스프린트 목표와 백로그를 설명한다
  • ...
  • 개발팀은 작업을 계획한다
  • 백로그가 생긴다

스탠드 업 미팅

개발팀 또는 PO를 포함해서만 참석하고 스프린트 기간 동안 매일 진행하고 15분으로 시간제한을 두고 일어서서 진행한다.

다음 세 가지에 대해서만 이야기한다.

  • 어제 할 일
  • 오늘 할 일
  • (뭐였지?)

스프린트 리뷰

  • 이해관계자가 참석한다
  • PO는 백로그에서 완료한 항목, 안 완료한 항목을 설명한다
  • 개발팀은 기간 동안 잘된 점, 뭐뭐 등에 대해서 논의한다

스프린트 회고

  • 개선할 수 있는 기회
  • 개선점에 대해서는 액션 아이템을 정하고 어사인까지 한다

제품 백로그

스프린트 백로그

인크리먼트

지라에서 쓸 수 있는 리포팅 차트

번다운 차트

[장애요소가 있는 스프린트의 차트]

[이상적인 번다운 차트]

칸반

애자일에 대한 오해

포괄적인 문서를 만들지 않아도 된다

→ 문서는 개발 중에 완성한다

변화에 대응해야 하고 스프린트 목표가 바뀔 수 없다

→ 스프린트 목표를 변화를 반영해서 만들고 스프린트 기간 안에 목표를 바꾸지 않는다

계획한 기능만 잘 작동하면 된다

→ 고객이 사용하는 관점에서 한 스토리가 잘 작동하도록 목표를 세운다

개발 중인 SW 진행상황을 고객에게 통보한다

→ 문서로 보고하는것보다 작동하는 SW를 전달한다; 이유는 피드백을 받아서 요구사항을 수정하기 위함이다

질답

redacted

redacted

redacted

redacted

redacted

redacted

redacted

redacted

profile
프론트엔드 엔지니어

0개의 댓글