안녕하세요. 일루넥스 개발팀 박윤민입니다.
이번에 새롭게 Jetbrains Space를 도입하게 되면서 협업 도구와 스크럼 프로젝트에대해 설명해보고자 합니다.
1. 협업 도구를 도입하게 된 배경
- 업무 진행상황 및 히스토리를 알 수 없다.
- 서로 공유한 자료 보관이 힘들다.
- 프로젝트관리가 힘들다.
- 커뮤니케이션이 힘들다.
- 일정공유가 안된다.
2. Jetbrains Space를 도입한 이유
현재 Beta버전으로 Organiztion 요금제로 기능을 사용 해볼 수 있는 점입니다.
아직 저희에게 필요한 기능들이나 자주 쓰는 기능들을 잘 모르는 상태에서 무턱대고 좋다는 도구를 사용해보기 보다는
무료로 여러 가지 기능들을 한번 사용해보고 저희에게 맞는 요금제를 선택할 수 있는 기회였습니다.
또한 Intellij IDE를 사용하고 있고 그것과 호환성이 좋을 것을 판단했으며
무료 요금제 역시 사용자 수에 제한이 없어 사용자 수에 따른 비용 부담이 없다고 볼 수 있습니다.
프로젝트 대시보드
채팅창에서의 코드리뷰
가격 정책
3. 스크럼 프로젝트란?
3.1 주요용어
3.1.1 스크럼
스크럼은 프로젝트 관리를 위한 상호, 점진적 개발방법론이며, 애자일 소프트웨어 공학 중의 하나입니다.
그리고 소프트웨어 개발 프로젝트를 위하여 고안되었지만, 소프트웨어 유지보수 팀이나 일반적인 프로젝트/프로그램 관리에서도 적용될 수 있습니다.
3.1.2 유저 스토리
사용자의 입장에서 무엇이 필요하고, 그것이 왜 필요한지를 설명합니다.
3.1.3 백로그
개발대상에 대한 요구사항 리스트 및 이슈목록 입니다.
3.1.4 스프린트
4.1.4 스프린트
3.2 장점
- 반복 주기마다 생산되는 실행 가능한 제품을 통해 사용자와 충분히 의견을 나눌 수 있다.
- 일일 회의를 함으로써 팀원들 간에 신속한 협조와 조율이 가능하다.
- 일일 회의 시 직접 자신의 일정을 발표함으로써 업무에 집중할 수 있는 환경이 조성된다.
- 다른 개발 방법론들에 비해 단순하고 실천 지향적이다.
- 스크럼 마스터는 개발 팀원들이 목표 달성에 집중할 수 있도록 팀의 문제를 해결한다.
- 프로젝트의 진행 현황을 볼 수 있어, 신속하게 목표와 결과 추정이 가능하다.
- 프로젝트의 진행 현황을 볼 수 있어, 목표에 맞게 변화를 시도할 수 있다.
3.2 단점
- 추가 작업 시간 필요 : 반복 주기가 끝날 때마다 실행 가능하거나 테스트할 수 있는 제품을 만들어야 한다.
이 작업이 많아지면 그만큼의 작업 시간이 더 필요하다. - 일일 스크럼 회의를 15분 안에 마쳐야 함 : 스크럼 방식에서는 일일 스크럼 회의를 15분 정도로 정해놓았다.
그러나 정확히 15분의 약속이 지켜질까? 일일 스크럼 회의의 특성은 꼭 필요한 것만 매우 짧은 시간에 간략히 회의하는 것이다.
그러나 때로는 회의가 길어져 작업 시작 시간이 늦어지고 그로 인해 작업하는 데 상당히 방해를 받을 수 있다. - 투입 공수 불측정에 따른 효율성 평가 불가 : 투입 공수를 측정하지 않기 때문에 얼마나 효율적으로 수행되었는지는 알기 어렵다.
- 프로세스 품질 평가 불가 : 스크럼은 프로젝트프로젝트 관리에 무게 중심을 많이 둔 방법이다.
따라서 스프린트 수행 후 검토 회의를 하지만 프로세스 품질을 평가하지 않기 때문에
품질 관련 활동이 미약하고 따라서 품질의 정도를 알 수 없다.
마치며
개인적으로 협업도구를 도입하게 되면서 기존에 바쁘다는 이유로 하지 않았던 것들은 하나씩 해나갔으면 좋겠습니다.
그리고 협업도구가 불필요해지거나 쓸모없어지지 않고 좀더 팀원들에게 도움이 되도록 서로가 노력해서 사용했으면 좋겠습니다.
