스프린트 관리 도구 구상 & 개발하기

0. 인트로

개인적으로 프로젝트를 정하고 진행하면서 계속 찝찝한 마음이 한켠에 있었는데...!

얼마 전 휴일이 있어 혼자 곰곰히 생각해보니, 이 찝찝한 마음은 조직에서 진행하는 애자일 프로젝트 처럼 체계적이지가 못하다는 점에서 오는 거였다!


1. 흥미롭고 재미있어보이는 주제는 많은데 어디 한곳에 정리가 되지 못하니 자꾸 잊혀지고,
정리를 해두더라도 우선순위 없이 뒤죽박죽이라 금새 다른 주제에 한눈이 팔려 일만 벌려두고 마무리를 못하기 일수였다 ㅠㅠ

토이프로젝트들도 흐지부지돼서 1~2년 지나서 블로그 훑어보다가 우연히 발견하게 되고 ㅋㅋㅋㅋ ㅠㅠ

2. 마음만 먹으면 하루이틀만에 뚝딱 완성할 수 있을 것 같았던 내용들이 실제로 파보면 복잡하고 생각보다 깊이가 있어서 

원래의 주제는 점점 멀어질때가 많았다. 계속 한 곳을 목표로 달려야하는데 가지가 가지를 치다보면 그것도 못끝내고 원래 목표도 못끝내고.. 끙

3. 내가 얼마나 시간을 들였고, 효율이 나지 않는 부분은 어디였는지 개인적으로 확인해보고 싶다는 생각이 항상 있었는데
 이걸 위해서 또 글을 쓰고 기록을 추가로 하자니 뭔가 내키지 않는 기분(for loop으로 풀면 쉽게 풀리는 로직이지만 for는 그래두 쓰기 싫어~~~하는 심보🤪)이라서 미루고 있었는데 요걸 뭔가 효율적으로 알아서 기록해주면 좋겠는데...

등등

그래서!!! 개인 스프린트 진행 내용을 기록할 수 있는게 있으면 좋겠다~ 싶어졌다 ㅎㅎ

+) 요즘 소셜 광고에 UI/UX교육 관련된게 엄청 올라와서 (당신도 이것만 보면 뚝딱 만들수 있답니다~),, 나두 예쁘게 페이지 하나 만들어보고 싶은 욕구도 뿜뿜했음

1. 필요한 기능 정리

내가 고객이 되어서 설계 해보자!! 하는 마음으로 요구사항을 정리해봤다
- 이전 / 현재 스프린트에 대한 정보를 칸반보드 형태로 한눈에 볼 수 있었으면 좋겠어요

- 항목 간의 우선순위를 지정할 수 있으면 좋겠어요

- 스프린트 기여도를 눈으로 확인할 수 있으면 좋겠어요
- 관심이 생긴 주제들을 백로그에 바로바로 넣을 수 있으면 좋겠어요

- 항목 간의 blocked by를 확인할 수 있으면 좋겠어요

21.05.02 추가)

- Sprint > Step > Task/Question 로 관리하되, Task/Question은 Step간 이동이 자유로우면 좋겠어요

- 전체 Backlog에서 Sprint 로 바로바로 옮길 수 있으면 좋겠어요

 

2. 아키텍쳐 설계

각 잡고 하려니까 뭐 하나를 고르면 다른 곳에서 불편한점/불합리한점이 생겨서 ㅠㅠ 계속해서 구조를 수정하고있다
이래서 실제 업무에서는 각자 그 분야 전문가들을 불러서 설계하는건가보다........ 
새벽에 눈에 불켜고 이 방법 저 방법 구상해보는데, 입사 교육 받을 때 한번쯤 해보는 파스타면 + 마시멜로 탑 만들기같다는 생각이 들었다
FE BE DB 세 다리중 어느 것도 튼튼하지가 않아서 좀 만 흔들려도 바로 뽀각 부서지는 파스타면 ㅠㅠㅠㅠ 😭

2-1. 20210420 

구조_최종) 이 땐 엄청나게 자신감이 넘쳤지... 지금보니까 요 사진 색감 보정도 했네 ㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋ

이렇게 설계한 이유 : 
    돈들이기 싫음, Front에만 집중하고 싶음 등등 여러가지 이유를 들며 그냥 DB와 BE를 사용하지 않고 싶었음 ㅎㅎ (나자신.. 왜그랬어?)

떠오른 문제점 :
    1. 데이터 관리 주체를 Front에게 넘길건가? 찝-찝🤨

    2. 위의 구조는 나만 쓰고 나만 보면 상관 없는데, 외부에서 다른 사람도 내용을 확인하려면 데이터를 어디엔가 올려두긴 해야함

    --> 위의 1번에서 고민한대로 끙.. 찝찝하긴 해도, 별 수가 없으니 Front 소스 내에 data를 JSON으로 말아둔다 치면.
          내가 로컬에서 수정한 내용을 Front 소스에 반영하여 다시 deploy하는 절차가 과연 합리적인지 확신이 서지 않음

2-2. 20210424

구조_최최종) 점점 "이래서 유명한 아키텍쳐는 다 유명한 이유가 있는거야.... 내가 뭐라고... 훌쩍..." 하게 되었던 시기

 이렇게 설계한 이유:

    1. 스스로 CURD를 완벽히 설명할 수 있었음... 일단 마음이 편안함
    2. graphQL을 써보고 싶었는데, 이번 기회에 해볼까?! 하는 덤 심리 
    3. recoil을 async와 함께 써보고 싶었는데, 이번 기회에 해볼까?! 하는 덤 심리 22..

떠오른 문제점:
    1. GCP 사용 시 보안/인프라에 대한 생각을 안할 수가 없음
    --> Cloud Function으로 들어오는 호출을 제안하는 방법이 무엇무엇이 있는지, 내 케이스에는 어떤 방법이 좋은지 스스로 판단하고 선택하기 어려웠음. SDK? API_KEY? OAuth2.0? 알쏭달쏭한 용어들,.,.
    2.  이 때까지 내가 들고있던 data구조는 Firestore에 저장하기 적합하지 않음
   

 

2-3. 20210501

구조_최최종_진짜) 이러다가 뭣도 안되겠길래 이전 구조에서 cloud funtion 날려버림 

 이렇게 설계한 이유:
    1. 인프라 지식이 거의 0에 수렴하는 ㅠㅠ 나에게 Cloud Function의 호출에 보안 요소를 적용하는 것은 꽤 많은 공부가 필요한 일이었음

    2. 하루 정도 써보니 이게 그냥 GCP 문서만 읽고 따라해서는 내 영역이 될 것 같지 않았고, 관련된 책을 교보문고 장바구니에 담기 시작.....
    3. 그치만 이 프로젝트를 진행하게 된 이유를 돌이켜 봤을 때, 베타 버전이라도 완성해서 내가 사용하면서 고쳐나가는게 맞다고 판단함 (다행히 아직 책 안시킴 ㅋㅋㅋㅋㅋㅋㅋ )
    4. 그래서 제일 많은 시간이 들 것 같은 클라우드 인프라 공부를 포기하고 firestore에 바로 붙여서 데이터를 들고오기로 함 ( 이 부분은 전에 한 번 해본적이 있어서 금방 할 수 있었기 때문 ㅎㅎ )
떠오른 문제점:
   react PROCESS.env에 firestore용 key를 들고 있게 하려는데, 보안적으로 완전히 안전한 것인지 확인이 필요함. git에 안올리기만 하면  안전하다는 글을 더 많이 보긴 했는데, 요청이 나갈 때 깔 수 있지않을까 싶어서

3. UI/UX 구상

ovenapp.io/

OvenApp.io

학생 때 수업에서 개인 프로젝트 할 때 (까마득한 2015년...) 프로토타이핑을 ppt로 했는데, 진짜 ㅋㅋㅋ 극혐이라서 좀 서치해봤었음

프로 UI/UX 디자이너를 위한 툴 말고 요 ovenApp을 찾았는데 진짜 편하고, 이쁘고, 가볍고 다 해서 그떄부터 가끔 화면 설계할때마다 썼음

나의 첫 오븐 프로젝트... 2015년 뭐지 진짜 언제적이야 ㅠㅠ 

아직도 건재하신 openApp님을 보니 마음이 벅차올랐음.... 기능 추가도 좀 있는 것 같고 asset도 먼가 추가된 느낌임 ㅠㅠ 감동

 

내가 머릿 속으로 상상하던 화면을 실제로 그려내는 작업은 정말 재밌는 것 같음
그리고 그 결과 👇🏻👇🏻👇🏻

오랜만에 만지작하니까 재미있었음

4. 개발

신기한게, 위에서 내가 안해보던 것을 할 때는 버겁고 어려운 느낌이 있었는데, 프로토타입 UI 화면을 딱 전달받고 나니까 ( 예 그래요 제가 저한테 전달했습니다 ^^ ) 손이 알아서 움직였음 ㅋㅋㅋㅋㅋㅋㅋ 물 만난 물고기 느낌?! 팔딱팔딱

 

이렇게 귀엽고 뽀작한 페이지가 만들어졌음 👇🏻👇🏻👇🏻

ga0hyeon.github.io/

React App

릴리즈(?) 노트

20210421

휑..

 

20210430

디자인만 입힌 componet들. 기능 없음

 

20210501

- 칸반 Step 간 Task 드래그 & 드롭 이동 기능 추가
- 드롭 시 priority 순으로 내림차순 정렬됨

- webfont 적용 ( spoqa.github.io/spoqa-han-sans/ )

20210502

- 반응형 대응

- Task 더블 클릭 시 수정 모달이 보이고, 수정 가능
- 좌측 backlog 에서 현재 Sprint로 Task 드래그 & 드롭 이동 기능 추가

- 좌측 Sprint History에서 앞서 진행한 Sprint 이력 확인 가능
- firebase 연동