주요글: 도커 시작하기
반응형


"OKKYCON 2017 소통, 개발에 숨을 불어넣다"에서 집중해서 들은 세션 내용 요약:


개인적 소감은 "가길 잘했다"!


XP 더 나은 소프트웨어 품질을 위한 일의 방법 (정윤진)


프로젝트를 통해 배운 것

  • 작은 규모 팀이 효율적
  • 다른 전문성이 모여 어려운 문제 해결
  • 문제를 즉각 공유해야 빠른 해결 가능
  • 팀 구성원의 성향이 다르면 감정적 문제가 커지는 경향
  • 스타트업은 제품보다는 보통 팀이 깨져서 무너짐
작은 팀은 소통에 도움이 됨
  • 소통 횟수가 줄어듬
  • 팀이 커지면 소통 비용 증가(허락을 구하기 위한 미팅 시간 증가)
  • 팀이 작으면 쉽게 공유
밸런스팀
  • 매니저, 사용자, 엔지니어, 데이터 사이언스 등으로 구성된 팀
  • 가치: 신뢰, 경험 공유(배움), (작은) 실패를 환영하는 문화, 다양한 목소리
  • 적은 스트레로 더 대단한 걸 더 빠르게 이룸
XP/TDD
  • 결국 모든 것은 빠르고 안전하게 제품을 내보내기 위함
  • 예: TDD - 여러 이유로 테스트 작성을 포기하지만, 지속적으로 빠르게 가려면 테스트 필수
  • 예: 페어 - 돈이 아까울 수 있으나, 2명이 같이 일하면 생산성은 20% 떨어지나 품질은 80% 향상
피보탈 업무 패턴
  • 8:30 아침 식사 (대화)
  • 9:00 스탠드업 (5분 진행)
  • 9:05 팀 스탠드업 (페어 결정), 해결할 스토리는 트래커에 존재, 늦어도 9:30분을 넘기지 않음
  • 9:20 페어 업무 시작
  • 11:30 점심 식사
  • 13:00 오후 시작
  • 18:00 아무도 없음

채용시 하루 동안 페어를 하고 결정한다는 것이 인상적



애자일은 애자일이란 단어를 버려야 한다. (신정호)


애자일의 형식적인 부분을 버려야 함. 형식으로 망하는 프로젝트 징후:

  • 애자일에 대한 맹신
  • 목표 없는 작은 주기
  • 의미 없는 회의
  • 기준 없는 추정
  • 자발적이지 않은 교육
  • 겉치레 시스템 평가
역할

직책보단 역할에 집중

  • 스크럼 마스터니 PO니 하는 직책보다는 "파악, 결정, 책임" 역할을 수행해야 함
파악
  • 파악을 하지 못하면 결과적으로 결정할 수 없음
  • 파악하기 위한 도구: 정책, 요구사항 기록, 통신 프로토콜, UI/UX, 진행사항, 테스트 케이스, 커밋기록, 현황판 중심 데일리 미팅, 리스트 목록 등
  • 팀내/팀외적으로 놓치는 일이 없는지 계속 확인 필요
결정
  • 결정에 필요한 배경, 결정할 케이스를 객관식으로 제공
책임
  • 파악 -> 좋은 결정 -> 책임은 작아짐(없어짐)
구성원(내부/외부 포함) 간 협업, 부딪칠 수 있는 경우를 정리
  • 기획자 vs 디자이너
    • 기획자는 와이엎프레임 없이 요구사항 위주 정리, 디자이너는 사용자에 맞는 디자인
  • 기획자 vs 개발자 vs 품질 책임자
    • 테스트케이스 중심 개발(상호 간 인식 차이 줄임), 테스트케이스 공유 시간
  • 기획자 vs 품질 책임자
    • 정책이 정해지지 않은 경우 데일리 정책 회의
  • 디자이너 vs 개발자
    • TODO 목록
  • 최고의사결정자 vs 팀/TFT
    • 일정 관련 정량적인 수치 기반 상황 공유
  • 팀 vs 팀

스케줄링


중요한 건 결국 정량적 파악. 다음을 고려:

  • 근무일수, 휴가, 테스트 일수
  • 개발 완료 기준
  • 늘 어디쯤인지 파악할 수 있어야 함

스트린트 회의

  • 정책과 요구사항 발표
  • 구현 이슈 논의
  • 모호한 상황을 명확하게 파악하고 결정
  • 회고를 했다면 이어서 진행
스트린트
  • 기획 중심 기간, 구현 중심 기간, 테스트 기간 중심에 따라 알맞게 진행
    • 예, 기획 중심 기간에는 부문 미완성이지만 흐름을 먼저 보임
    • 예, 구현 중심 기간에는 부문 완성으로 기능을 먼저 보임

회고


회고는 해결한 것과 해결할 것을 명확히 하는 시간

  • 진행 상황 공유
    • 목표로 했는데 한 것 못 한 것 공유
    • 결과 보기(가장 중요)
    • 이슈 현황판, 데일리 미팅 기록
    • 남은 일(테스트케이스로 관리)
  • 리스크 확인
  • 마지막 스트린트에 좋은 점, 나쁜 점(감정 고려)


애자일은 말이나 형식이 아닌 행동으로 보여주는 것



협업도구로 제대로 말하기 (김동수)


협업 도구를 제대로 쓰게 하는 것이 어려웠음

  • 구성원들의 변화 필요성이 있거나 확실히 지금 문제를 해결할 솔루션이 되는 경우, 정착할 가능성이 높아짐

협업 도구를 변경하고 싶다면

  • 협업을 더디게 만드는 것을 식별
  • 구성원의 요구사항 수집
  • 영향력있는 조력자(대표, staff 부서) 필요
  • 비용 발생시, 최종 결정권자를 설득

협업 도구 평가 기준

  • 사용이 쉬운가
  • 검색할 수 있는가
  • 공유가 쉬운가
  • 다른 도구와 연동
  • 사용료 대비 가치가 충분한가

마켓컬리 적용

  • 도구에 대한 교육 진행
  • 도구에 대한 계정 관리를 관리팀에 맡김
  • 프로필 사진은 소통에 도움
도구로서의 말
  • 상대방이 이해할 수 있는 단어
  • 단어가 정확해야 함
  • 날짜가 정확
  • 검색 가능하게
  • 에티켓


생산성 지향의 커뮤니케이션과 기업 문화(최영근)


커뮤니케이션

  • 소프트 스킬 > 하드 스킬 (소프트 스킬이 18% 더 높음)
  • 소통 == passive skill
    • 소통에서 90% 전달은(10% 손실) 매우 낮은 완성도임, 6회 쌓이면 53%
  • 소통은 정보 전달 목적 -> 청자 중심

소통법

  • 경영진에게
    • 신속한 의사 결정 목적 -> 단기적 효과, 숫자 사용
    • 집행 요약(executive summary) 사용
  • 세일즈
    • '고객이 원하잖아요'에 숨어있게 하지 말라
    • 요구를 끌어내는 대화 (목적, 대안 등을 끌어낼 필요)
  • 자기 자신
    • 철저한 자기 검열 필요 (나를 위한 결정은 아닌지)
    • 성과를 위한 결정인가?

관성, 조직

  • 규칙화, 문서화(성문화), 선언 --> 무언의 압박
  • 넥플릭스 사례: 스포츠팀처럼
    • 계약 관계, 전문가, 조직의 비즈니스 목표 달성
  • 유비쿼터스 언어
  • 회의록 작성
    • goal, discussion point, agreement, action item을 담음
  • 박터지게 싸우자
    • 팁1, 우리 잘되려고 하는 거지 --> 나 자신도 흥분을 가라 앉히는 효과
    • 팁2, 설득되면 확실하게 리액션
  • 메신저 : 정원사 필요
    • 정원사는 검열을 하지 않는다는 것을 느끼게 해야 함

협업의 미신 5가지 - 근거 기반 협업으로 가기 위해 (김창준)


미신1 : 프로그래밍은 잘 하는데 협업은 잘 못 해? 또는 반대 협업은 잘 하는데 프로그래밍은 딸려?


프로그램과 협업은 별개라는 사고!


뿌리:

  • 잘못된 연구 방식 (1960년대)
    • 뛰어난 프로그래밍을 측정한 기준이 잘못 됨(예, 문제를 잘 푼 사람이 뛰어난 프로그래머라 가정하는 식)
    • 한 명으로 실험실에서 혼자두고 측정

1990년대부터 여러 명을 두고 측정해 보니,

  • 뛰어난 프로그래머 그룹의 조언 : 사회적 조언 포함 (70%)
  • 평균적인 그룹의 조언 : 사회적 조언이 적음 (20%)
  • 실제로 성과를 잘 내는 프로그래머일수록 대화에 많은 시간 투입
  • 프로그래밍을 재정의해야 하는 순간이 옴
협력도 프로그래밍의 한 부분으로 인지하기 시작


협업은 프로그래밍을 잘 하는데 있어 필수적인 요소



미신2 : 팀의 퍼포먼스는 가장 뛰어난 사람이 결정


MIT의 연구:

  • CQ(집단 지성) - 어떤 팀은 어떤 일을 줘도 잘 하고, 어떤 팀은 어떨 일을 줘도 못함
    • 가장 잘 하는 사람, 평균 IQ도 팀의 성과에 영향을 주지 못함
  • CQ 성과에 영향을 주는 지표 
    • 공감력
    • 말을 골고루 함(여러 명이 골고루 할 때)
구글 연구: 탁월한 팀의 특정 찾기
  • 팀의 성과는 개기인의 기술적 전문성이 중요하지 않음,
  • 심리적 안정감이 높을수록 성과가 좋음

일이 복잡할수록 더 그러함


미신3 : 전문가를 모아두면 협력을 잘 할 것이다


  • 전문성에서 사회적인 요소를 빼고 봄
  • 오래 본다고 협력이 늘지 않음 (예, 양치질), 협력 훈련을 받은 적이 거의 없음
  • 협력할지 논의한 뒤에 일을 진행하면 성과가 좋아질 수 있음

의식적인 협력의 중요성 : 어떻게 협력할까를 먼저 고민



미신4 : 협력을 잘 하는 것은 서로 좋은 관계를 유지하는 것이다


  • 미신: 협력 잘 하는 것 = 인간 관계 좋은 것 = 술 자주 마시는 것
  • 회피적으로 좋은 관계인지 고민 필요 -> 갈등을 처리하는데 능숙하지 못함
  • (건설적으로) 부정적인 감정을 얘기할 수 있는 팀이 성과가 좋음, 솔직하게 불만을 얘기할 수 있어야 좋은 관계

미신5 : 분업을 잘 하는 것이 협업을 잘 하는 것이다

  • 분업 외에는 협업에 대한 아이디어가 없음
  • 리차드 행만: 
    • 팀과 워크 그룹 구분
      • 팀 : 구성원 사이에 네트워크로 연결
      • 워크 그룹 : 구성원 사이에 트리/스타 구조로 연결
    • 팀의 성과가 압도적으로 높음
    • 일이 불확실할수록 팀의 성과가 높음
  • 왜 잘하게 되느냐?
    • 기본적으로 피어 코칭 때문(동료 간 소통)
  • 공통점, 팀의 효과성을 예측하는 변수 : 상호 간 모니터랑하는 팀 -> 성과가 높음
    • 서로 의견 제시하는 팀

70 20 10

    • 성과의 70%는 팀원이 만나기 전에 이미 결정
    • 20%는 시작하는 시점에 결정
    • 10%는 일을 하는 과정에서 결정
  • 미리 사전에 어떻게 일할 지를 미리 정하고, 초반에 굉장히 신경 써야 함
분업을 너무 많이 해서 문제가 된 에피소드: "131번 서버 누구 담당입니까?"


상호 작용이 중요함


QA에 나온 이야기

  • 조직의 미션: 개인의 일을 한다는 느낌을 없애야 함!
    • 우리 팀의 최고 우선순위가 뭡니까?
  • 사람이 계속 바뀌는 환경에서는 더더욱 사회적인 요소에 신경을 많이 써야 함
  • 의견 내기가 무섭다 --> 일단 우리 안에서 해보는 것!
    • 예: 단계를 구분 - 아이디어를 내는 것과 누가/어떻게 할 지를 정하는 것을 구분
      • 누가 할지 고를 때 팀이 함: 독박이 아니고 팀원이 협력하게 유도
      • 누군가 해야 하는데 하기 싫은 일 -> 팀이 회의를 해서, 어떻게 전환을 하면 재미있어질 것인지 논의
  • 문화 -> 작은 상호작용이 쌓이면서 주변에 영향을 미침


+ Recent posts