OKKYCON: 2017 참석 후기
소통, 개발에 숨을 불어넣다. 매우 중요!
컨퍼런스를 다녀와서 후기를 작성한 적은 한 번도 없었는데, 2017년 행사 중 가장 감명 깊고 공감 가는 부분들이 많고 나 자신을 그리고 우리 개발팀을 회사를 되돌아볼 수 있는 뜻깊은 자리가 된 것 같아 내용들을 정리해보고자 한다. 발표자분들의 말씀을 하나하나 다 새겨 기록하기에는 역량이 부족하여 들었던 내용 중 키워드로 메모했던 것들을 간단히 정리해 본다. 부정확한 내용이 들어갈 수 있음을 말씀드립니다. 잘못된 내용 피드백 환영합니다.
1. 정윤진 님 -
XP, 더 나은 소프트웨어 품질을 위한 일의 방법
행사장 도착을 조금 늦게 해서 중간쯤부터 들었지만 발표에서 느껴지는 내공은 첫 세션에서부터 매우 인상적이었다. 개성이 강한 팀원이 모여 팀이 붕괴된 예시부터, 회사가 잘되고 팀은 늘어났는데 조직의 배포 주기는 왜 길어지는가? Pivotal에서 하루 일과와 Pair Programming을 실천하는 방법까지. 기본적으로 개발자가 하는 모든 일련의 작업은 좋은 소프트웨어를 배포하기 위함이라는 목적에서 시작된다고 말씀해주셨다.
가장 와 닿는 키워드
테스트 코드는 기본, 팀과 조직이 커질 때 비로소 힘을 발휘한다.
페어프로그래밍이 주는 장단점 : 생산성은 20% 감소하지만 품질은 80% 올라간다.
코드 작성 즉시 리뷰가 되기 때문에 테스트코드까지 100% 코드리뷰가 가능하다.
코드리뷰에 관한 고찰 : 20 줄의 코드에서는 20개의 코드리뷰 이슈가 발생하지만,
100줄의 코드에서는 '잘 짰네'라는 리뷰를 하게 된다. (매우 공감)
회사는 점진적으로 상향 평준화된다.
서로 다른 전문성을 가진 사람들이 팀을 이루면 어려운 문제를 잘 해결할 수 있다.
Pivotal 이야기 (국내에서 가능한 팀이 있을까?)
Pivotal 의 일과 (칼퇴 가능한 프로세스)
아침식사 - 전체 stand 미팅 - 팀 stand 미팅 - Pair Programming - 퇴근
이슈 트레커에는 1일 단위로 클리어할 수 있는 이슈 단위로 기록되며, 상태는 실시간으로 공유된다.
Pivotal 에는 정해진 자리가 없다?
PC 1대 , 모니터 키보드 마우스 2대로 Pair Programming을 위한 환경.
Pair Partner는 매일 아침 정해진다.
2. 김요한 님 -
디자이너와 개발자와의 협업을 위한 디자인 시스템
발표자분께는 정말 죄송하지만 글쓴이가 React와 웹 개발을 해본 적이 없어 어설프게 정리하기에는 역량이 부족하여 생략하도록 하겠습니다.
https://atlassian.design/ 발표 중 나온 아틀라시안의 디자인 시스템 가이드.
3. 신정호 님 -
애자일은 애자일이라는 단어를 버려야 한다.
애자일 방법론 다들 알지만 프로젝트는 망한다. 누군가 이번 프로젝트는 애자일/스크럼/칸반으로 진행한다고 했을 때 누군가는 이미 망했다고 생각한다. 프로젝트가 망하는 문제 중 하나가 애자일이라고 말한다. 즉, 애자일로 망해본 사람은 애자일 프로젝트에 대한 굉장한 반발이 있다. 형식에 얽매이는 애자일을 망한다. 이슈, 커밋 개수로 성과를 측정하는 방법은 안 좋은 방법이다.
3.1 역할
- 스크럼 마스터, 팀장, PM 등 직책이 중요한 것이 아니라 역할이 중요하다.
- 프로젝트를 파악, 결정, 책임을 가져갈 사람이 필요하다.
파악
- 현재 상황을 파악하지 못하면 앞으로 생길 문제를 예측할 수도 없고 대안도 제시할 수 없다.
- 정책, 요구사항 기록 / 통신 프로토콜 / UI, UX 진행사항/ 테스트 케이스 / 커밋 기록 파악
- 회고시 현재 진행 중이고, 이번 주에 뭐할 것이다(X)
이슈 진행 중인데 이런 리스크 존재/구체적인 부분 잘되고 있다(O)
- 데일리 미팅 기록을 메모한다. (나중 회고에서 사용된다.)
결정
결정에 필요한 Case와 장단점을 나열하고 결정에 대한 답변을 구한다.
(예시)
상사 : 이번 프로젝트 어떻게 했으면 좋겠나?
담당자 : 제 생각엔 대안으로 A, B, C 안이 있고 A, B, C의 장단점은 뭐뭐가 있는데 어떤 것으로 할까요?
상사 : 그래 그럼 B로 하게.
책임
- 퇴사 / 감봉/ 시말서 (X)
- 항시 이슈에 대한 해결방안과 리스크가 파악이 되어있고 최선의 결정을 했다면 책임은 없어진다.
수평적 관계가 중요 하나 핵심은 파트마다 충돌 나는 케이스를 정리하는 것.
3.2 스케줄링
중요한 것은 정략적 파악이다.
워킹데이 / 휴가 / 테스트 일수 / 개발 완료의 기준/ 매일 어디쯤인지 파악할 것.
스프린트 회의 -
회고에 바로 이어서 진행, 정책 및 요구사항 발표 구현 이슈 논의 모호한 상황 명확하게 파악 및 결정
스프린트 어떻게 나눠야 하는가 -
부분 미완성이지만 흐름을 먼저 보일 것인가? / 부분 완성으로 기능을 먼저 보일 것인가?
중요한 파트는 어디인가 -
기획 중심 / 구현 중심 / 테스트 중심
3.3 회고
좋은 점 , 나쁜 점을 지적하지만 달라지는 것은 없다.
회고는 해결된 것과 해결할 것은 명확히 하는 시간이다.
회고 때 결과물을 보는 것은 매우 중요하다.
한일 / 남은일 / 지난 스프린트 이슈사항 / 남은 스프린트 이슈 사항을 정리하는 것.
시연 , 이슈 형황판 , 데일리 미팅 기록.
시연 시 각 파트에서 부족한 부분 리스트 남은 스프린트 중 어느 시점에 넣어야 하는 것인가? 시간이 지나면 남은일을 어디까지 했는지 모른다.
개인 / 파트 / 업무 / 프로세스 작은 것부터 큰 것 까지 모두 이슈사항과 그에 따른 해결방안 명확하게 기입.
애자일은 말이나 형식이 아닌 끈질기게 물고 늘어져서 행동으로 보여줘야 하는 것.
4. 김동수 님 -
협업도구로 제대로 말하기
전화, 메일, 팩스, 메신저, 협업 툴 등 도구의 장단점에 대해 자세히 설명해 주셨다.
여러 가지 협업 툴이 있지만 제대로 쓰기는 어려움, 유행따라 바꾸지 말 것.
구성원들이 변화를 요구해야 한다.
지금의 문제를 해결할 솔루션이 되어야 한다.
변화를 주도하는 사람이 오너가 아니라면 혼자서는 지속적인 발전 / 유지하기는 불가능.
도입 후 지속적인 관심과 요구를 계속 반영해야 함.
무엇이 협업을 더디게 만드는지 식별, 구성원들의 요구사항을 수집, 문화를 잘 정착할 수 있도록 영향력 있는 조력자를 만든다.
개인적인 도구와 업무에 사용하는 도구는 확실하게 구별하며, 일과시간 외에는 스트레스 주지 않는다.
협업 도구를 선택할 때 고려해야 할 사항.
얼마나 사용하기 쉬운가.
검색할 수 있는가.
구성원 간 열려있고 공유가 쉬운가.
다른 도구와 연동이 원활한가.
사용료를 지불할 가치가 충분한가.
5. 최영근 님 -
생산성 지향의 커뮤니케이션과 기업 문화
커뮤니케이션의 목적은 정보전달 - 화자가 아닌 청자 중심의 대화, 의사 결정을 할 수 있는 대화.
메일 보내기 예시
제목 : A 의사 결정에 대한 B안
A, B, C 의 장단점 중 내가 생각하기에는 B가 더 좋은 것 같습니다.
결정을 부탁드립니다.
고객이 원하는데 이거 안돼요? (고객 뒤에 숨에서 쪼는 사람을 이끌어내기)
올바른 대화 예시
기획자 : A 기능 1주일 만에 개발 가능한가요?
개발자: 목적이 뭔가요?
기획자: abcd.. 목적이 있습니다
개발자: 사정상 A는 안될 거 같고 A' 나 A''로 가능할 거 같아요.
기획자: 음 그러면 A'로 진행해주시겠어요?
관성을 극복하기
서비스 명의 변경, 용어 통일, 관습 변경 등 오랫동안 해오던 것에 대한 변화와 제도를 적용시킬 때.
슬로건, 포스터, 등으로 언어 변경 무언의 압박.
회의록 작성 - Agreement / Action Items 기록하기
커뮤니케이션에 임하는 자세 팁
Tip1 - 내가 잘되라는 거냐? / 우리가 잘 되려는 거지.
Tip2 - 마치 이중인격자인 것처럼, 과격한 리액션과 칭찬!
6. 김창준 님 -
협업의 미신 5가지 - 근거 기반 협업으로 가기 위해
6.1 협업과 프로그래밍이랑 구분하지 말 것.(타자가 빠르다고 잘하는 것이 아님)
뛰어난 사람들의 그룹에서는 사회적 요소가 들어간다. (다른 사람과의 대화에 시간을 더 많이 쓴다.)
보통 수준의 프로그래머는 스킬적인 측면만 강조한다. (구글 검색 등 스킬적 측면 강조.)
협력하는 부분도 프로그래밍이다.
자동화할 수 있는 직업일수록 임금이 낮다.
컴퓨터 프로그래머 vs 소프트웨어 개발자 / 48% vs 4% 확률로 자동화할 수 있다.
소프트 스킬은 내 직업을 지키는 기술로서 중요하다.
6.2 팀의 퍼포먼스는 가장 뛰어난 사람이 결정?
CQ - 어떤 작업을 팀에게 줬을 때 잘하는 수치 -
평균 아이큐 , 가장 뛰어난 사람이 속한 팀이 가장 잘하지 않았다.
공감력과 말을 골고루 하는 능력이 가장 CQ 가 높았다.
탁월한 팀의 특징? 개개인의 기술적 전문성이 그렇게 중요하지 않다. 심리적 안정감이 가장 중요.
6.3 전문가들을 모아두면 일을 잘할 것이다?
전문성을 평가할 때 사회적 요소를 빼고 보는 경우가 많다.
오래 했다고 잘하지 않는다.
훈련을 받은 적이 없다. 의식적인 노력이 필요하다.
6.4 인간관계가 좋다고 / 술이나 회식을 자주 한다고 협력을 잘한다?
신혼 때 적게 싸울수록 이혼한다.
볼 거 안 볼 거 다 봐야 한다.
팀 내 그런 사람이라는 것을 서로 인정해야 함.
부정적인 감정을 꺼내는 팀들이 오히려 더 퍼포먼스가 더 좋다.
6.5 분업을 잘하는 것이 협업을 잘하는 것이다?
일 시작 - 너할꺼, 나할꺼, 1달 뒤에 보자. (망함)
팀과 워크 그룹.
팀은 - 트리구조 - 팀이 훨씬 효율이 좋음, 어려운 일일수록 팀이 더 잘함.
Peer coaching 서로 협업하고 물어보고 도와줌.
워크그룹 - 스타형 - 나는 팀장 하고만 얘기하면 돼, 내 담당자랑만 하면 돼. (망함)
Mutal Performance Reporting 이 가능한 팀이 더 효율이 더 좋음.
상대방의 프로젝트가 일이 다르지만 서로 참견하고 의견을 교환하는 팀이 가장 Best.
분업 자체는 팀의 성과를 떨어트림.
서로 간섭하라.
QnA
의견을 내면 내 것이 되니까. 의견을 못 내는 문제에 대해서?
> > 답변
사장이 바뀌어야 한다.
팀 내부에서 해보는 게 제일 좋을 것 같다.
작게나마 시작해보자.
아이디어를 내는 것과 누가 할지를 구분한다.
담당자는 정하지 않는다.
마인드 매핑으로 아이디어를 내고 추후에 팀이 같이 나눠서 하는 것으로 얘기한다.
누군가는 해야 하는데 다들 하기 싫어하는 일?
> > 답변
막내가 하자, 가위바위보 (X)
일을 어떻게 전환하면 재미있어질까요?
회의 기록하는 게 재미없는데 어떻게 즐겁게 할까?
둘이서 같이 기록해볼까?
실수를 만회하는 것에 대해 성과 측정에 도입을 한다면?
>> 답변
많은 조직들은 개인 평가에 초점을 맞춘다.
누군가에게 도움을 주거나 도움이 되는 경우를 평가하는 법은 좋은 듯 하나
지속 기간이 짧을 수 있다.(제도를 통한 변화)
후기
아침 9시 30분부터 오후 5시 40분까지 대략 8시간에 걸친 컨퍼런스였다. 섹션별로 짧게 요약한다고 했는데도 분량이 생각보다 많다. 블로그를 쓰면 보통 최소 2주 이상은 걸리는데 하루 만에 작성한 블로그라서 부족한 면이 많다. 최근 몇 달간 진행했던 프로젝트가 그다지 성공적이지 못해 우울한 상태에 있었는데 어디 가서 조언을 들을만한 돌파구도 없었다. 항상 SNS에는 좋고 성공한 사례만 나오기 때문에 내가 진행하는 프로젝트만 왜 이럴까라는 생각에 빠져있었다. 하지만 오늘 발표하신 분들과 참가자 분들에게서도 많이 느낀 것이 실패 경험은 나쁜 것이 아니고 이런 자리와 경험을 공유하며 성장할 수 있는 밑거름이 된다는 사실과 나만 실패하는 게 아니라 다들 시행착오를 겪으며 배우고 있는 중이라는 생각에 내년을 버틸 수 있는 에너지를 얻고 온 기분이다. 블로그는 키워드로만 정리한 부분이고 기회가 된다면 우리 조직에서 반영할 수 있는 부분을 정리하여 사내 발표와 적용을 해보고 싶다. 발표와 질의응답에서 '우리 조직도 마찬가지인데' 라는 생각을 매우 많이 했기 때문이다. 좋은 행사 만들어주신 분들에게 너무 감사하다.
