스프린트 회고

설계가 완벽할 수 없으니 맞든 안맞든 스팩으로 공유되어야 하고 지금 모습이 좋다 안좋다 피드백이 되어야 함

모든 예외사항과 피드백을 고려하는 제품을 설계할 수는 없다. 이 스팩은 진화되어야 하고 설계자가 빠른 시행착오를 하기 위해 빠른 개발이 필요함. API 스팩 변경이 많다 - 누가 시행착오를 거쳐야 할까?

스팩을 공유할 수 있는 공간이 필요하다

사용자에게 친화적인 의견과 기술자에게 친화적인 의견이 충돌할 때가 있을 수 밖에 없음. 대립된 상황을 수면 위로 올려 논의를 해야 하고 그 공간이 반드시 필요하다

스웨거가 그 공간이 될 수 있을까

README, 스웨거 등으로도 충분하다면 성장이 한쪽으로 쏠릴 수 있으므로 문서화하는 역량을 키울 필요가 있음

1. 서비스를 만드는 기업 입장에서 문서화 하는 도구는 필수적이지만 (컨플루언스) 스웨거는 선택사항이다

   1. 포스트맨을 사용한다면 이것이 좋은 논의 공간이 될 수 있음

   2. 코드가 수정되고 빌드가 되고 배포가 되어 산출물이 생기면 끝? 테스트를 해야 함

   3. 이 때 테스트를 자동화할 수 있는 도구로 포스트맨을 사용할 수도 있음

   4. 포스트맨은 빌드 자동화와 같이 사용해 테스트를 자동화할 수 있는 아주 진보된 도구이다

      1. NEWMAN

   5. 문서화 → 컨플루언스, 포스트맨 → 테스트 자동화

스토리 연결성?

제품 시안이 들어오지 않아서… 와이어프레임까지 만들고 나면 해결될 것

커밋 단위

커밋을 언제하는게 좋을까?

커밋이 많은 이유는 파일이 많아서… 수정 범위가 많기 때문에… 커밋을 작게 만들기 위해서는 결국 두 가지 방법

1. 수정을 조금하고 커밋

2. 기능 단위로 커밋

기능 단위로 커밋을 해야 하지만… 예를 들어, 로그인 기능이 있을 때 프론트와 백엔드를 한 번에 커밋할 수 없고 로그인 페이지에 가입하기 버튼이 추가된다면 가입하기 버튼을 로그인 기능에 커밋해야 함… 너무 작게 만들면 이해할 수 없는 변경사항이 될 수 있음. 이 커밋이 스테이블한지 모르기 때문에… 따라서 커밋은 기능 단위로 스테이블할 때 해야 함

커밋 단위로 어디서 무엇을 어떻게 수정했는지 기록해야 함. 나중에 되돌리기 쉽게 하기 위해

커밋은 기능 단위로 하거나 파일 단위로 하거나. 뒤돌아서 봤을 때 의미있는 커밋이어야 함. 이해할 수 있는 커밋이어야 함. 작업 티켓 하나에서 커밋 하나만 나와도 됨 (브랜치 머지할 때 커밋)

기반작업할 때는 파일 단위로 커밋하기 어렵기 때문에 first commit으로 남겨도 됨. 나중에 변경하게 될 것이기 때문.

리뷰어에 입장에서 코드 리뷰가 부담되는 상황

코드 커버리지가 매우 넓을 때. 나에게 안전한 코드는 코드 커버리지가 작고 조건문이 없는 코드

개발자에 성장 시점에 따라 시점이 달라진다. 리팩토링을 하고 싶을 때가 있지만 코드 커버리지가 매우 넓다. 이는 용인되어야 할 상황.

제품이 릴리즈 되기 전 까지는 코드 커버리지가 넓어도 됨. 하지만 릴리즈 후에는 코드 커버리지가 넓다면 스스로도 불안함에 빠진다. 이미 스테이블한 코드이기 때문. 리뷰어 입장에서도 매우 부담됨

지금은 운영에 대한 시야는 없어도 되고 커버리지가 넓어도 되고 코드퀄리티를 높이는 시간을 갖고 멘토님과 리뷰할 때 한소리 들을 코드가 생길 때까지는 커버리지가 넓어도 된다

번다운 차트

220 → 0 으로 가는 차트. 3주 스프린트에서 모든 이슈가 해결되었다 라는 의미. 쉽지 않은 상황. 계단식으로 떨어지는 현상 → 한 이슈 테스트에 대해 쭉 설명한 것

차트가 올라간다는 것은 남은 시간이 증가했다는 것. 시간 추정을 잘 못 했거나 버그가 생기는 등의 문제가 생긴 것. 이는 팀 수용 가능 시간보다 시간이 늘어났다는 것이고, 목표 달성이 쉽지 않은 상황이 되는 것. 따라서 목표 달성이 중요한가, 버그 수정이 더 중요한가를 결정해야 함. 버그를 우선적으로 고친다면 빼야 할 목표를 설정해야 함. 시작하지 않은 우선순위가 낮은 티켓 삭제하기.

계속 0에 가깝게 수렴해야 하지만 0까지 가기는 어려움. 하지만 남아있는 티켓을 다음 스프린트 높은 우선순위에 가져가야 할까? 회고에서 진행해야 함.

번다운 차트는 회고때 아주 중요한 의미를 가지고 타임 트레킹부터 시작해야 한다. 시간을 데이터화 한다면 시간이 얼마나 중요한지 알게 되고 얼마나 중요한 스프린트였는지도 알 수 있음

에픽

에픽은 시점으로 해야 함. 시점은 우리에게 첫 번째 MVP가 될 수 있음

MVP를 두 번 할 수 있다면 MVP 1.0, 2.0을 달성하기 위해서 달려가는 중

때로는 MVP 1.0에서 MVP 0.1이 생길 수도 있음

그 단위가 바로 에픽!

지금 중요한 것은 MVP를 이용해 의사결정을 할 수 있어야 하고 MVP가 아니더라도 의사결정을 할 일이 생긴다. 스터디, 회의시간 등

그러면 기능 단위로 에픽을 구분하는 순간 스토리의 위치가 애매해지고 백로그를 만드는데 장애가 될 수도 있음

MVP 1.0을 기준으로 더 작은 MVP 0.1을 만들 수도 있다

MVP 내에는 스토리가 들어갈 수 있고 스토리 내에는 작업 티켓이 들어간다. 그럼 그 흐름은 눈에 아주 잘 보이게 됨.

추정시간 내에서 업무를 할 수록 조직에 속해있다는 느낌을 받게 됨

필드에서 업무를 할 때 스프린트를 바라보는 관점과 필드에서 스프린트를 바라보는 관점 간 차이가 보이게 된다. 누가 효율적이고 누가 합리적인지.

포스트맨

어떤 도구를 통해 지속적으로 운영해보는 것은 좋음. 여러 시행착오를 거쳐 어떤 도구가 필요하고 어떤 도구가 불필요한지 판단하는 것은 좋음. 포스트맨을 통해 API를 명세화하고 테스트하는 것은 매우 좋은 결정

테스트 케이스

코드가 테스트의 커버리지를 데이터화할 수 있음. 테스트 코드를 작성한다는 것은 역할 분담을 용이하게 할 수 있음. 하지만 제품으로 봣을 때 우리 제품은 서비스이고 프론트가 있고 백엔드가 있고 요청을 보내는 것들이 있고. 첫 번째로 API가 제품 규격 중 하나가 됨

API를 검증하기 위한 테스트 케이스는 매우 도움이 됨. 테스트 코드 커버리지보다 API 커버리지 데이터가 더 중요함. 백엔드 제품은 API이기 때문.

회원가입에도 여러 시나리오와 테스트 코드가 있음. API 형태로 테스트 코드가 나오고 포스트맨으로 자동화할 수 있는 것이 첫 번째 제품이 될 것이고

JUnit 테스트 커버리지보다 API 커버리지가 더 중요함

프론트엔드 테스트 케이스

1. 화면 상 클릭 자동화를 통해 내가 작성한 화면이 의도한 대로 동작하느지 확인해야 함

   1. SPA는 시간에 따라 다를 수도 있음

2. 위 방법은 시점과 상황을 만들기 어렵기 때문에 외부적으로 의존되는 상황이 많기 때문에 코드 커버리지만을 만족하는게 유리한 상황일 수 있음

코드 커버리지 vs 테스트 커버리지

JUnit 커버리지 vs Postman 커버리지

IA & 기능 워크 플로우

• IA

  • 가지고 있는 쿠폰을 손쉽게 등록할 수 있는 메뉴가 있어야 할 것

  • 우리 서비스에 방문을 해야 하는 이유가 쿠폰을 쓰게 하는 것때문에 서비스를 이용을 하게 할까 리마인드 시켜주기 위해 우리 서비스를 이용하는 걸까?

    • 엔드유저가 우리서비스로 인해서 쿠폰이 잊혀지지 않을 거라는 안심을 느낄 수 있으려면 우리를 통해서 지속적인 알림을 받게끔 해주는게 의도된 경험

    • 여기에서 아이디찾기랑 비밀번호 찾기는 mvp에 안들어가도 됨

    • 쿠폰을 등록하고 등록된 쿠폰이 리마인드 되는 경험이 mvp 내에 들어가야 함

    • 리마인드 내용이 달라 질 수 있음(기간에 따라 리마인드 되는 코멘트가 바뀔 수도 있음)

    • 적정한 시점에 적정한 위치에서 리마인드 경험이 필요함

    • 메세지를 여러가지 시점에 여러가지 내용으로 사용자에게 제공되어야 하는 내용이 IA나 기능 플로우에 나타나야 함

    • 알림 기능이 우리한테는 중요할 수 있겠음

    • 알림이 중요한 기능이기 때문에 페이지라고 생각

    • 알림을 보거나 관리할 수 있는 방안이 있어야 함

    • 로그인의 서브프로세스는 우선순위가 낮음

    • mvp에서 필살기 경험들이 포함되면 좋겠다.(알림, 자동등록)

    • 쿠폰사용완료도 확인할 수 있어야 함(mvp에)

  • 시럽은 마케팅용 쿠폰이고 우리는 재화

    • 기능 상에서는 시럽에서 많이 착안할 수 있을 듯

    • 우리가 플랫폼화되서 사용자가 많아지면 마케팅용 쿠폰을 뿌리는곳은 우리랑 제휴하고 싶을 수도-> 메인의 진화점

  • 기프티콘이 없는 사람들은 우리서비스를 어떻게?

    • 삭제하지 않고도 우리 앱을 유지해야 할 이유는?

      • 다음 대화 주제

  • 알림

    • mvp에서는 앱내에서의 푸쉬알림이라고 생각

• mvp 때 다뤄야 할 항목

  • 초반

• 이후에 다뤄야 할 항목

와이어프레임은 mvp우선, 초반기획때 이후에 다뤄야할 항목도 기획도 들어감

다음때는 빨간 프레임 우선의 와이어프레임이 나와야 하고, 와이어프레임이 나오면 개발 시작해도 됨

기획쪽으로 시간소모가 될 것이라는것을 염두에 두고 진행해야 할 것

이다음에 뭐할거야? 사용자가 여기서 머물러야 할 이유가 있어? 등의 논의가 계속 될 것 스프린트 중간중간 기획하는 시간이 티켓으로 넣는 시간이 필요함 , 이번달에는 일주일 단위로 스프린트를가져가는게 좋겠다.

다음주

• 준비가 가능하면 현재 빨간화면에 대해서 와이어프레임 만드는 것

• 사용자 스토리를 mvp 0.5 정도 해서 에픽을 만들고 거기에 들어갈만한 사용자 스토리와 작업task을 만들면 좋겠다.(티켓으로 확인)

• 와이어프레임확인과 개발적으로도 확인이 가능

• 와이어프레임과 지라 통해서 확인을 할 수 있

• 이슈티켓을 볼면 브랜치가 있고 그러면