프로젝트 일정 산출에 대해서
플래닝 포커
개발 단위를 나눔
단위에 대한 다른 사람들과 어느정도 기간이 소요될지 토론
소요기간에 대해 토론하지 않더라도 기능을 잘게 나누는 것은 중요
산정한 일정내에 끝나지 않을 수 있기때문에 버퍼 기간을 둠
개발외적으로 이유로 일정내에 개발이 끝나지 않을 수 있음
일정이 지연되는 원인을 찾았다면 원인을 탓하기보다 해결에 집중해야함
해결할 수 없는 경우 계획을 축소하거나 어쩔 수 없이 일정을 늘려야함
개발자 입장에서 디자인에 대한 QA를 진행하는 경우도 있음
ex) 리소스의 해상도
QA는 전문 인력이 진행하지만, 어쩔수 없이 기획자가 진행하는 경우도 있음
기능적 QA
ex) 모달이 정상적으로 잘 닫히는지
QA를 진행하는 과정에서 일정이 지연되는 경우도 있음
일을 나누는 기준
소스가 충돌하지 않도록
공통 모듈을 다루는 사람을 따로 지정
컨플릭트
굳이 컨플릭트가 일어날 것이 보이는데 부딪히는 것은 좋지 않음
불가피하게 컨플릭트가 발생하는 경우가 있기 때문에 이를 통한 경험으로 충분할 듯
디자이너가 없는 상황, 어떻게 해야할지
모두의 의견 교환이 원활하게 이루어진다면 토의를 통해 결정할 수 있음
그렇지만 결국에는 의견을 정리해야하기 때문에 한 명이 담당하게 되지 않을까
처음부터 완벽하게 셋팅하지 않아도됨
완벽하게 셋팅해 놓으려고하면 오히려 고민하는 시간이 길어져서
프로젝트에 상태 관리 라이브러리를 사용할지, 기본 기능만 사용해볼지
기본기부터 챙기고 다음으로 넘어가는 것이 좋을 듯
누군가 이끌어 나갈 수 있다면 진입 장벽을 낮출 수는 있을 듯
스프린트 기간을 어떻게 나누는것이 좋을지
1주는 너무 짧다고 생각, 2주가 적당하다고 생각
스프린트 단위를 어떻게 나눌지도 생각
컴포넌트를 어떻게 나눌지
아토믹과, 디자인 시스템에 의한 분류도 경험해봤음
아토믹은 어떤 단위에 속하는지 고민하는 시간이 너무 길어져서 비효율적이라고 느꼈음
미리 정리하고 들어가는 것이 좋을 듯
디자인 시스템을 처음부터 염두해두는 것이 좋을 듯
아토믹에 너무 매몰되지 않도록