Advanced Daily Scrum Meeting
이 글은 Daily Scrum Meeting이 무엇이다라고 소개를 하기 위한 글이 아니라, 이미 Daily Scrum Meeting 경험이 있는 분들에게 내가 했던 방식에 대한 경험과 내 생각을 공유하기 위한 글이다.
찐 개발자의 퍼실리테이션 도전기 #4-2 워크샵
찐 개발자의 퍼실리테이션 도전기 #4-1 워크샵 설계 및 준비
오랜만에 적는 찐 개발자의 퍼실리테이션 도전기 #4. 이번에는 워크샵 설계이다. 이전과는 스케일부터가 다르다.
찐 개발자의 퍼실리테이션 도전기 #3
이제는 동료들도 다들 잘 따라주어서 1,2편과 같은 그런 식의 다이나믹함은 없다. 그래서 이 글도 더이상 쓸 거리가 없다. ㅠㅠ 그냥 회의 때 사용하는 소소한 팁들에 대한 썰을 가볍게 풀고자 한다.
찐 개발자의 퍼실리테이션 도전기 #2
회의 전 배경
찐 개발자의 퍼실리테이션 도전기 #1
회의 전 배경
Legacy Code를 Renewal 하기로 결정하여 관련 개발자들을 불러서 이 내용을 알리고 앞으로의 일정에 대해서 논의하는 첫 미팅이었다. 그 동안 나는 PoC로 Ruby on Rails, Nest.JS 두 가지로 프로젝트를 진행했으며, 그 결과를 팀장님과 같이 논의하여 일단 Ruby on Rails로 Renewal 하기로 잠정적으로 결정을 했다. 그 이유는 코드 작업량이 훨씬 적고, 비지니스 로직 구현하는 시간도 적게 들어서이다. Renewal 작업을 하는 동안에도 다른 업무 요청사항들은 계속 있을 것이기 때문에 최대한 짧은 시간에 Renewal을 마치는게 중요하다고 생각했기 때문이다. 최종적으로는 Node로 다시 한번 Renewal을 할 것이다. 왜냐면 채용문제 때문에 어쩔수가 없다. Ruby로 잘 정리된 코드를 Node로 옮기는건 비교적 쉽다고 판단을 했다.
스프린트 회의 관련 간략 개념 정리
Concept 설명
개발팀을 기능단위가 아닌 서비스단위로 개편하고 싶으세요 ? Agile한 팀으로 만들고 싶으세요 ?
개발팀을 운영하는 입장에서 어떻게 하면 좀 더 팀을 효율적으로 변화시킬수 있을까에 대한 고민을 끊임없이 하시는 분들이 많을 것이다. 그러기 위해서는 현재 구조에서는 더 이상 변화가 힘들것 같다고 판단을 하는 경우도 있을 것이다. 그래서 어떻게든 변화를 주기 위해서 현재 팀 구조를 개편하는 것으로 결정을 할 수 있다. 현재는 기능단위 조직 (eg. 개발팀, 기획팀, 디자인팀 // 또는 개발팀 내에서도 서버팀, 웹팀, 모바일팀)이므로, 서비스단위 조직 (eg. 블로그 서비스팀, 쇼핑몰 서비스팀 등…)으로 개편해보면 어떨까 라고 고민을 할 수 있다. 아직은 가보지 않은 길이기에 이 결과에 대해서는 현재 판단이 불가능하다. 일단 해보는거고 안되면 다시 돌아오면 된다고 생각할 수 있겠지만, 그게 돌아오지 못하는 강이 될 수도 있다고 생각된다. 단순히 조직을 바꾸는것이 아니라, 구성원의 회사생활 전반적인 것에 영향을 미칠 것이며, 그 사람의 인사평가에도 영향을 미칠 수 있고, 결과적으로 그 사람의 연봉에도 영향을 미칠 수 있다. 그 과정에서 이것을 견디지 못하고 이탈을 하는 (이직을 하는) 사람도 생길 수 있다.
