스프린트 회고 🏃‍♀️🕐

부런클 1주차 스프린트 회고 📝 (2020.11.20)

쉬워 .. 아쉬워..

프로젝트 진행에 필요한 중요한 이슈거리에 대한 고민이 충분하지 못했다.
- 주제에 대해서 충분히 생각하고 정리할 시간을 가지고 정하도록 하자
프로젝트에 대해서 너무 아키텍처에만 집중해 생각한 것이 아닌지..
- 오히려 결정된게 없다.. 스켈레톤 코드? 템플릿을 만들어 보자.
규칙들을 너무 많이 정한거 같기도?? (잘한점)
- 스타일 가이드 같이 본거는 너무 잘한 거 같아요!
프로젝트 아키텍쳐 선정시 피드백을 구할 때 좀더 의미있는 피드백을 주지 못한 점
- 더 열심히 공부하고 적용시켜보자!
오늘 발표할때 저희 많이 한 것들에 대한 전달이 조금 덜 되서 아쉬워요 ㅎ
- 다음 발표때 간단한 리허설해보기!

잘한 점

동료의 의견을 경청하고 적극적으로 프로젝트에 임한 점.
오랜만에 나가서 뛰어본 점.

이번 주 이런 점 잘하셨어요!

To MR Cho

어떤 결정에 있어서든 모두 다 좋다고 해주시고 정리를 해주셔서 감사합니다. 수요일 오프때 친근한 인상이 너무 좋았습니다.
제가 의견을 좀 강하게 내는 타입인데 한번 더 생각해 볼 수 있게 질문해주셔서 좋았어요

To MR Kim

차분하게 잘 설명해주시는 모습이 너무 감사합니다.. 그리고 매번 좋은 학습거리와 주제들을 가져오시는데 그것 또한 너무 좋습니다.
코드 스타일에 대한 선례를 검색해서 공유하는 등, 여러 고민거리를 생각하고 직접 찾아봐서 함께 생각할 수 있는 시간을 만들어 주셨어요.
문서 작업에 힘써 주신 점

To MR Jang

github 프로젝트 관련해서 많은 꿀팁들을 알려주셔서 좋았습니다.
슬랙, 깃헙 활용과 같은 많은 팁들을 공유해 준 것
문서 작업에 힘써 주신 점

다음주 시작 하기 전까지 준비할 것들

공통사항: ** 이력서 작성 및 제출 **

MR Cho

Combine, KickStarter 코드 보고 학습

MR Kim

IssueTracker Combine으로 바꿔보기, Core Location, Core Data

MR Jang

MVVM, Combine, 스토리보드 없이 뷰 만들기, core location, core data, github actions 설정 (빌드 & 테스트)

부런클 2주차 스프린트 회고 📝 (2020.11.27)

쉽다 쉬워 아 쉬워

프로그램 자체는 신경을 많이 기울이고 있기 때문에 체계적이지만 프로젝트 진행 자체를 봤을때는 체계적인 면이 조금 부족한 것 같다. 예를 들어 오전에는 오늘 목표를 명확히하고 목표를 달성한다던지 이런 시작과 끝맺음이 있어야 체계적으로 프로젝트를 진행하는 느낌을 받을 수 있을 것 같다는 생각이다.
- 페어프로그래밍인걸 감안해 목표를 세워야 할 것 같다.
- 오전에 그날의 체크리스트를 만들고 달성하도록 해보자
- 그날 그날 회고를 하자
- 만약 목표한 바가 달라졌다면 목표 수정을 자주하자
- 하나를 달성한 후 다음을 생각하자.

논의점은 적당히 얘기한 후에 Issue로 정리해놓으면 좋을 것 같다. 그리고 나중에 각자 조사하고 해당 논의점에 댓글로 달거나 얘기해보면 더욱 좋을 것 같다. 얘기를 나누며 생각의 교류를 한다는 건 분명 좋은 현상이지만 필요 이상으로 길어지기도 하는 부분이 적잖이 있기 때문이다.
하나의 주제를 두고, 각자의 다른 생각을 공유하며, 서로의 생각을 좀 더 올바른 방향으로 인도한 활동들이 생산적이었다.
- 좁혀지지않는 의견차이가 생기는 일이 줄어들 것이다.
- 기록을 작성해두면 내 생각과 내가 이해하고 있는지 좀 더 명확하게 정리가 된다는 장점이 있다.
- 얘기를 나눠본 후에 조사해보고 다시 봤을 때 입장 차이나 사용법에 관해 더 이해가 잘 될 수 있다.
- 한 주제가 15분 이상 지속되면서 의견이 좁혀지지 않을 것 같으면 이슈에 옮기자고 제안하고 이슈를 통해 대화를 나누고 의견을 정리한다.
- 하루에서 이틀의 기한을 두고 의견을 정리한다.

그림을 그려서 서로의 생각을 일치시키는 것은 매우 좋은 방법인것같다. 특히 프로젝트 구조라던가 하는 부분에서 더욱 큰 효과를 발휘하는 듯 하다 👍

다이어그램 루시드 차트 👍 💯 그림판 👍 💯

페어프로그래밍을 할 때, 드라이버 역할을 맡아 네비게이터의 생각을 코드로 옮겨 적는다. 그때, 네비게이터의 생각을 파악하지 못하고 불러주는대로 코드를 적는 느낌을 받았는데, 생각을 공유한 이후에 코드 작성에 돌입했으면 좋을 것 같다. 🎱
PR, 커밋 단위가 점점 애매해 지는 것 같다. 페어프로그래밍 중에도 틈틈히 PR은 아니더라도 커밋은 나눠야할 필요가 있을 것 같다.

주기? 드라이버 네비게이터 교체 주기. 이름하여 드'네'교' 주기 드네교 주기를 짧게 가져가자. 5분이여? 5부우우우운? 함수하나? 하나아아아?

주기 : (30분) 두번 교체 후 5분 휴식 커밋 템플릿은 prefix로 (#1) feat: (P10) <--- 커밋 메시지 --->

한번 작성했던 코드에 대해 다시 되돌리기 힘들었던 것 같다. 작성하는 그때에 바로바로 풀어야 할 것 같다.
"일단은 이렇게 해놓고~" 하면서 넘어갔던 순간이 많았던 것 같다.
눈 앞의 급한 것만 해결하고, 각각의 요소에 대한 원리를 파악하고 이해하는 시간을 갖지 않은 점
- 이슈로 등록하여 공부하고 내용 정리를 해서 댓글로 남기고, 다른 사람도 댓글을 추가할 수 있도록하여 학습공간으로 사용하면 좋을 것 같다.
- 개발은 7시에 스탑하고 밥먹고 코드 회고 <이름하야 코'회'> (10시)-> 뜀박질
- 뜀박질 후 개인 시간 --

디자인 패턴에 대해 많은 얘기를 나눌수 있어서 신선했다. 디자인 패턴을 대해 좀더 자세히 알게 된 부분도 있지만, 정님이 말하셨던 것처럼 이론적으로는 그럴싸하지만 직접 구현할 때에 생기는 문제점들을 겪어보면서 너무 또 디자인패턴에 운운하거나 기대지말아야겠단 생각이 들기도 한다.
여러가지 디자인 패턴에 대한 추상적인 생각들이 머리속에서 정리되고 있다. 언제, 왜 사용하며, 단점은 어떤 것이 있는지 하나씩 알게 되었다.
- 222 : 디자인패턴이 일상생활에서 보이기 시작했습니다 (일상생활 불가능해짐)
디자인 패턴에 대해 많은 얘기를 나눌수 있어서 신선했다. 디자인 패턴을 대해 좀더 자세히 알게 된 부분도 있지만, 정님이 말하셨던 것처럼 이론적으로는 그럴싸하지만 직접 구현할 때에 생기는 문제점들을 겪어보면서 너무 또 디자인패턴에 운운하거나 기대지말아야겠단 생각이 들기도 한다.
- 패턴에 프로젝트를 맞추기 보다는 프로젝트에 패턴을 맞추자
너무 "~패턴" 에 집중하는 경향이 생긴 것 같다.
- 우리 프로젝트에 맞는 커스텀 패턴을 생성해보자

컴바인을 사용하는 방법
- 222 : 따로 더 공부를 해야 할 필요성을 느낍니다. ㅠ
- 저도....

팀 활동을 하면서, 팀원의 사소한 말이라도 반응과 공감을 해줄 것이다. 온라인으로 진행하는 만큼 더더욱...
- 온라인 리액션 혜자가 되자
- "그만!" 이 필요합니다.
중간중간 너무 멀리나간다,
스프린트 리뷰중에 생각났던말 🅰️ - 🅱️ A - B "오늘 하루에 엄청난 것 그리고 내일을 걱정해서 미리 대비책을 만들지 말자. 오늘은 오늘 할 수 있는 가장 간단하고 가장 고품질 작업을 행하자" 그럴듯 하면서도 지키기 너무 어려운 말 같다. -> 이어지는 생각
- 끝없이 개선하는 태도 버려(애자일??)

부런클 3주차 스프린트 회고 📝 (2020.12.04)

CoreLocation, CoreMotion을 사용하긴 했지만 예제 수준에서 벗어나지 못한 것 같다. 세부적인 기능이나 어떻게 얼마나 가능한지, 정확도가 어떤지에 대한 이해가 부족했던 것 같다.
- 프로젝트에 필요한 부분만 학습하고 적용해도 충분하다.
- 추후에 필요한 동작에 한해서 품질을 높이면 좋을 것 같다.

이제야 Combine을 이해하고 사용하게 된 것 같다.
구현하고 있는 프로젝트의 틀이 머리속에 확실히 잡혀가는 듯하다.
의문이 생기면 바로 질문을 하고 의논을 통해 답을 구하면서, 궁금증을 바로 해결해 나갔다.
이번주부터는 당일의 목표를 설정하고 진행하게 되면서, 어느 한 부분에서 머무르지 않고 바로 다음 단계로 진행할 수 있었다.
이번주에는 스프린트 때 세워두었던 구현 목표를 대부분 충족해서 만족스럽다.
저번주에 회고때 정했던 페어프로그래밍 규칙들을 적용하니 좀 더 수월하고 피로도도 적어진 것 같다.
야식은 아예 먹지 말아야겠다..
안경을 일찍맞췄더라면...
1주차때 정했던 이슈 활용 계획과 좀 틀어져 아쉬웠던 것 같고 조정할 필요가 있을 것 같다.
지난주와 비교해보면 프로젝트 진행 방식의 많은 점들이 개선되었다
- 드.네.교. 주기를 50분에서 1시간으로하고 바뀔때마다 5분에서 10분정도 쉬는데 한 문제에 봉착하거나 늘어지지 않고 탄력있게 개발을 진행하는 느낌을 받았다.
- 그리고 돌아가면서 진행해보니 느낀 또 다른 이점은 각각 짠 코드를 넘겨 받음으로써 해당 코드에 대한 이해도가 화면 공유를 통해 보고 네비게이터를 하고 있을 때에 비해 더 높다는 점이다.
- 한시간 넘게, 어쩔때는 두시간이나 교체가 이뤄지지 않은 경우도 있었다. 그때는 조금 늘어지긴 했어서 누군가가 나서서 교체 의사를 표하면 될 것 같다.
25키로 달리기 혹은 걷기를 병행하면서 프로젝트를 병행하는게 쉽지만은 않다. 더군다나 날씨가 추워져서 밖에 나갈때에는 단단한 각오를 해야한다. 그럼에도 다들 잘 유지하고 있고 나름대로 방법을 찾는 중인데, 이 그라운드 룰이 덕에 활동량이 많아서 개인적으로 크게 만족하고 있다.

부런클 4주차 스프린트 회고 📝 (2020.12.11)

View 구현시 예상하지 못한 문제에서 시간을 많이 보냈다

계획을 여유를 두고 세워야할 필요가 느껴진다.
습관적으로 코드컨벤션을 지키지 못하는 부분이 있었다.

의식적으로 PR전에 코드를 다시 꼼꼼히 되돌아봐야 할 것 같다.
마지막 주에 생각보다 준비할 게 많다. 좀더 시간을 투자해 기능을 마무리하고 완성도를 높여야할 필요성이 느껴진다.

늦어도 월요일까지는 기능을 마무리하고 완성도에 집중하자 일요일 노션 프로젝트 명세 제출도 명심하자
실기기에 대한 테스트를 너무 늦게 시작한게 아닌가 싶다.

다음주에는 실기기에 대한 테스트를 꼼꼼히 수행하자 Acitivity Classifier 민감도 조절을 해보자.
테스트 코드를 그동안 너무 방치해왔다. 테스트 용이한 구조로 설계하기가 목표였지만 정작 테스트가 빠져있어 아쉽다.

Service, ViewModel은 최대한 테스트를 작성하자
이번주는 mvvm 패턴으로 테이블 뷰를 구현해봤다. location provider에서 값을 받아 저장하고 있는 뷰모델이 있고, 이 뷰모델을 테이블 뷰의 셀에 인자로 넣어서 구현해봤다. mvc 구조로만 구현해 봤던 table viewe를 mvvm으로 구현하고 나니 구조가 더 잘 이해되었다.
애니매이션을 구현하고 있다. 스크롤 뷰에서 드래깅을 할 때 다른 뷰의 크기를 변화시켜야한다. scroll view의 delegate를 통해 호출되는 함수에서 content offset을 받고 그에 따라서 버튼의 scale을 변경한다. 스크롤 뷰의 delegate 함수의 처리와 동시에 드래깅 중에 처리할 로직을 분리하는 것이 상당히 어렵다.

주말 시간을 이용해 해결할 것이다.
이전에 페어프로그래밍을 진행하면서 코드를 작성할때 네비게이터가 불러주는 대로만 작성했었던 감이 있었는데 개별작업을 진행하니 그동안 써왔던 MVVM-C 및 컴바인을 직접 사용해볼 수 있어서 즐거웠다.
그리고 코드리뷰를 통해 내가 작성한 코드에 대해 부족한 점을 알수 있었다. 이제서야 코드리뷰를 진행한다는 것이 조금은 아쉽다.
기술 세미나가 갑작스럽게 닥쳐와서 컴바인에 대해 약간 조사를 하게 되었는데, 무엇이든지 막상 닥쳐와야 열심히 하는 것 같다.

앞으로 무엇을 하던간에 스스로 기한을 정해놓고 진행하는 방법론/접근법을 도입해봐야겠다.
아직 구현해야할 사항이 어느정도 남아있고, 또 그 외에도 안정화, 네트워킹 데이 등의 할일들이 많아서 완전한 그림은 그려지지 않는다. 빠르게 쳐나가면서 진행할 필요성을 느끼고 있다.