프로젝트를 다양하게 시도 하려고 합니다.
프로젝트에 관한 모든 것은 공론화를 한다.
서로에 대한 신뢰와 존중, 마치 하나의 팀, 소통, 수평 적인, 마치 하나의 문화로 접근
일단 기본 문법에 익숙하고 Git 사용에 있어서 무난다하면 참여 가능
AWS 로 배포 하고 있습니다
* 현재 구로디지털단지에서 모여서 개발을 하는데 상황에 따라서 신논현에서도 합니다.
•
1달에 적어도 2번은 모여서 할 수 있어야 함 ( 참여하면 보통 5시간 이상합니다.)
•
Git에 커밋하면 슬랙으로 노티 오기 때문에 1주일에 어느정도 할 수 있는지 평가 할 수 있는 구조
•
기본적으로 개인적인 일이 있기 때문에 무리한 요구는 하지 않지만 매번 발전 없는 모습으로 참여 하여 주변사람들을 힘들게 하면 안됩니다~!!!
•
사업방향, 우선순위, 문제점에 대한 이슈논의 및 비판은 언제든지 환영입니다.
다만 해당 이슈에 대해 대안없는 무작정적인 비판은 불가합니다.
Slack
•
채널 frontend, backend, pull-request, sprint 새로 열 것
•
질문을 올리더라도 thread를 적극적으로 사용할 것
•
개발 질문 할 때 mention을 사용해서 대상자를 참여시킬 것
•
공지에는 봤는지 확인하기 위해 이모지로 리액션 받을 것
•
매일 13시 이전까지 서로 안부&개발진행사항 업데이트 및 이모지 또는 쓰레드로 회신
•
호칭 부를 때 님 빼고 부를 것
•
최대한 dm을 사용하지 말고 개발 채널에서 이야기 할 것
•
링크를 걸때 보는이가 컨텍스트를 이해할 수 있도록 문장단위의 설명 줄 것
◦
메일 제목 네이밍하는 것처럼 패턴화하기 (예: [주제] 설명)
◦
쓰레드는 상관 없고 메인 글만 할 것
Jira
•
시간단위로 스토리 포인트 작성한 후에 추후 스토리 포인트 지표 결정할 것
(하루 단위 최대 5스코어 ex. 반나절 작업을 했을경우 2.5스코어로 기록)
•
기획문서를 풀어서 백로그에 티켓으로 올린 다음, 개발자가 해당 티켓을 가져다가 그룹핑해서 새로운 티켓 작성할 것
•
티켓당 할당은 1명씩만 가능하기 때문에 하위 티켓으로 나눠서 그룹핑할 것
•
스프린트에서 끝내지 못한 티켓은 연장할지, 닫고 새로 만들지 확인할 것
•
에픽 > 백로그 > 상세설명 순서대로 작성할 것
•
스프린트 이름을 기간 명시로 변경할 것
•
지라의 티켓은 본인이 스스로 작성하고 스스로 스코어를 적는다
•
이슈는 작업의 단위를 나눠서 표현한다. 작업의 단위가 큰 순서대로 나열함.
1.에픽(주 기능,개인적으로 스프린트에서 작업의 카테고리 느낌이 듬)-스코어 부여 가능
2.스토리(에픽의 세부 단위 기능,개발자의 경우 실제 작업하는 단위. 하부 단위 작업 생성이 가능(세부 작업 사항 기록))-스코어 부여 가능
3.작업(작업 사항 ,하부 단위 작업 사항 가능)-스코어 불가
4.버그(버그 발생 시 추가)
Sprint
•
Sprint에 대한 기간 및 review 2주에 한번 모임시에 진행
1.
각자 진행할 업무 Task 설정 진행 (2주동안 할 업무)
2.
2주동안 각자 업무 진행
3.
시그널 미팅시에 각자 업무 진행한 task review
4.
다음 2주동안 진행할 업무 JIRA에 기록
•
매일 아침마다 Sprint 모임을 슬랙 온라인 채널에서 진행(13:00전까지)
