OkkyCon 2017

- FullStack 개발자는 현실적으로 어렵다고 생각한다
- NodeJs + Swift + MongoDB 
- Front개발자가 Mockup기반 브레인스토밍으로 사장님과 초기 의사소통을 진행함.(실 구현은 시간이 소요됨을 이야기함)
- FireJune(참조) -> 자세한 프로젝트 관련 정보를 얻을 수 있음
- 팀이 커지게 되면 타팀의 승인을 받기 위해 설명을 하기 위한 시간이 많이 소요됨. N(N-1)/2
- static file 전송 node.js에서는 느리다 -> single thread -> nodejs 앞에 nginx를 도입(파일 업,다운로드 처리와 분기)
- 3개월내 MVP(Minimum Viable Project) 완료
- 오픈소스에 기여하고 있다 -> Pivotal Github(참조)

- 인기 있는 오픈 소스의 경우 빠르게 발전하기 때문에 문서와 소스가 다르기 때문에 실제 서비스와 일치하지 않았다
- 개발 / 스테이징 / 프로덕션 개념이 없었음
- 테스트 단계 없음
- 개성 강한 구성원 간의 충돌 발생
- MongoDB 불탐 -> 베타기간이여서 법적인 문제는 없었음

- 작은 규모의 팀이 매우 효율적
- 스타트업은 제품이 나빠서라기 보다 보통 팀이 깨져서 무너진다
- 문제에 대한 공유가 빠르게 이루어지지 않았다
- 코드 길이가 길어질수록 프로덕션 배포가 길어짐 -> 테스트 코드를 반드시 작성

- 혼자 업무 패턴 -> 피보탈의 업무 패턴(의사소통 및 기업 문화로 해결) -> 식사를 같이 함, 스탠드 업(다같이 모여서 또는 팀 단위로 서있는 상태에서 업무에 대해 토론), Pair 업무, 메일을 사용하지 않음
- Pair 업무 이유 -> 품질이 80% 이상 높아진다는 연구 결과 및 실제 경험(생산성은 20% 감소하지만)
- Architecting, Planning ? -> Scoping, 질답지 등의 회사만의 프로세스로 처리
- PM과 개발자가 같이 업무 진행 
- 한사람이 테스트를 통과하는 코드를 작성, 다른 한사람은 코드 작성 -> 코드가 길어질 경우 판단이 쉽지 않기 때문에 구현 단계에서 미리 코드 리뷰가 가능하다는 장점
- Ginkgo : TDD Open Source
- TDD 기반 개발을 수행하는데 한사람이 하는 것이 아니라 Pair Programming으로 수행한다 -> 이것을 회사의 문화로 만든다 -> 식사시간을 활용했다, google docs, 이메일 사용X(대화가 더 효율적)
- 마이크로서비스는 어떻게,언제 쪼개는 것이 맞나요? -> 속도가 늦어지기 시작할때 고민해야한다
- pairing 업무에 대해 의구심? -> 생산성이 높다고 안정성이 높아지는 것은 아니다, 다양한 문제가 해결된다, 서로 능력이 있는 사람과 같이 일을 하다보면 상향 평준화
- pair 업무시 -> 쓸데없는 질문은 금물 
- 프로젝트 관리 툴 -> Pivotal Tracker(참조)

- 회사로 모신 후 하루동안 이슈를 Pair로 3-4명 정도와 진행 후 판단한다
- 자신이 알고 있는 부분을 공유할 수 있는 인성을 중요시 한다 

- 디자인 가이드 문서 (기존) -> (새로운) Atomic design 방법론
- awesome design -> 디자인 시스템 작성 관련 정보, voice and tone(look and feel)
- Atlassian Design -> React Component
- Component 기반으로 구성되어 있을 경우 애자일 개발 환경에서 이점이 있음
- 디자이너가 작성한 코드를 개발자가 변경 사항에 의해 변경을 할 경우 서로 간의 갭이 발생
- [Design > Style Code > Developer] -> [Style Code > Design > Developer]
- react-sketchapp -> seamless integration with real data
- 디자이너와 개발자 협업에 도움이 되는 소프트웨어 -> ZEPLIN(참조)

- 프로젝트 성공하는 법은 알지만 현실성이 낮기 때문에 그렇게 되지 못한다
- 형식으로 망하는 프로젝트 징후 -> 맹신, 목표없는 작은 주기, 의미없는 회의, 기준없는 추정, 자발적이지 않은 교육, 겉치레적인 시스템 평가
- 세가지 이야기 -> 역할, 스케줄링, 회고
- 애자일은 말이나 형식이 아닌 끈질기게 물고 늘어져서 행동으로 보여줘야 되는 것이다

- 역할(파악/결정/첵임) -> 중요한건 직책이 아님 
- JIRA Issue, Daily Meeting, 현황판을 기준으로 RISK에 대해서만 이야기 한다
- 배경과 케이스 기반 객관식 리스트를 던져 결정을 진행함 -> 결정 이후 빠른 피드백을 받는다
- 매 시점마다 파악이 다 되어 있었고, 최선의 결정을 했다면, 책임은 없어진다
- 현재의 상황을 시연 및 설명하고 일정에 대한 조율을 진행했다
- 파트별 부딪힐 수 있는 부분에 대해서 어떻게 처리할 것인지에 대한 고민이 필요하다 -> 와이어프레임 활용(웹, 앱을 만들기 전 설계도)
- 품질 책임자 -> 테스트 케이스를 통해 기획자와 개발자의 Gap을 해결할 수 있다
- 정책이 수립되지 않으면 프로젝트의 범위를 가늠할 수 없다 -> 데일리 정책 회의를 진행
- 디자이너와 개발자 간의 Gap 부분은 다음 스프린트로 남기면서 해결 -> 디자이너 이렇게 하면 안되는데, 개발자 아는데 시간이 많이 걸려
- JIRA Issue Base 의사결정자와 협의
- 관련된 팀에 항상 문제가 없을지에 대해서 의논해봐야 한다
- 중요한건 수평적 관계가 아니라 부딪칠 수 있는 케이스를 정리하는 것이다

- 워킹데이, 휴가, 테스트 일수를 세알려라 
- 개발 완료 기준을 세워라
- 늘 어디쯤인지 파악
- 스프린트 회의 어떻게? -> 회고에 이어 바로 하루 동안 진행(수일을 사용하기엔 부담스럽기에)
- 스프린트 어떻게 나눠서? -> 부분 미완성이지만 흐름을 먼저 볼 것인가(주로 이렇게), 부분 완성으로 기능을 먼저 볼 것인가(50%이상 진행 완료시)
- 스프린트의 중요한 파트는 어디인가? -> 1)기획 중심 2)구현 중심 3)테스트 중심
- 스프린트 예시 : 총 8 스프린트, 5회 1cycle, 3회 1cycle

- 서로 감정을 다치지 않고 보다 나은 스프린트를 위한 준비
- Bad Case -> 포스트잇에 좋은점, 나쁜점을 적는다 -> 해결되는 부분이 명확하지 않다
- 회고는 해결된 것과 해결할 것을 명확히 하는 시간이다(중요)
- 명확한 내용을 Slide로 작성하여 회고 시간을 가졌음
- 프로젝트의 결과는 중요하지만 구성원이 프로젝트에 의해서 힘들어 한다면 그점을 회고시에 어필을 하였다
- Output 시연회를 가지면서 부족한 점을 도출해내었다
- 한 일, 남은 일, 지난 and 이번 스프린트 이슈 사항 

- 회사소개 -> 샛별배송 밤11시까지 주문시 새벽 문앞 배송

- 협업도구 : Asana, Wrike Yammer Ms Office Communicator Google GSuite
- 현재 -> 휴대폰, Google GSuite(메인계정저장소), Git, Jira, Confluence, Slack
- 협업도구는 현재의 문제를 해결할 솔루션이 되는 경우 변경해야 제대로 정착할 가능성이 높아짐
- 도입 후 지속적인 관심 및 요구를 계속 반영해 나가야함
- 무엇이 원활한 협업을 더디게 만드는지 식별
- 영향력있는 조력자를 만든다
- 얼마나 사용하기 쉬운가
- 검색할 수 있는가
- 구성원간 열려있고 공유가 쉬운가
- 다른 도구와 연동이 원활한가
- 사용료 대비 가치가 충분한가
- 통합, 사용성, 공유
- 사용 용어 일치시키기
- 날짜를 명확하게 -> 전날(X) 어제(X) -> 2017-12-18 오전 06시경(O)
- 아무리 급하더라도 필요한 내용을 기입
- Slack -> 앱스 도구로 알림의 메인 창구화(배포, 모니터링, AWS, 전자결제 등)

- Soft Skill의 시대 -> Communication / Passive Skill
- 90%(1sprint 2weeks) / 53%
- 7개의 직교 동영상

- Communication의 목적은 정보전달, 화자가 아닌 청자 중심의 대화
1. 의사결정자 -> 의사결정을 할 수 있게 해달라 / 단기적 효과, 숫자의 힘을 무시하지 마라 / Executive Summary(집행 요약)
    - 조사결과 기반 막연한 어떤 것으로 할까요란 물음보다는 -> 목적, 배경, 가능안(장단), 적합한 안을 지정해서 판단하도록 하는 것이 효과적 
2. 세일즈 -> '고객이 원하잖아요'에 숨어있게 하지 말라
    - 무조건 안된다는 답변보다는 기능이 필요한 목적 묻기, 다른 대안으로 해당 목적을 달성할 수 있음을 설득하라
3. 자기자신 -> 조직의 성공을 위한 선택인가, 철저한 자기 검열 필요

- 무언의 압박 -> 포스터, Code Deck
- 조직의 비즈니스 목표 달성 / We're a team, not a family We're like a pro sports team - Netflix
- Ubiquitous Language -> 공용으로 사용할 수 있는 용어 Deck을 만들어라
- 회의록을 써야한다 -> Goals, Agreements, Discussion Points, Action Items
- 박터지게 싸우자 -> 초기에 치열해야 추후에 문제가 없다 -> TIP -> "다 내가 잘되자는 거냐? 우리 잘되려고 하는 거지" / 설득되면 과격한 리액션과 칭찬
- 업무 채널 일원화 -> 업무 외 메신저를 사용할 경우 추후 찾을 때 어려움이 있을 수 있다(카톡)
- 조직 문화를 만드는 것은 정원을 가꾸는 것과 같다 

1. 프로그래머를 판단할때 개발과 협업을 다른 영역으로 구분하여 판단한다(X)
    - 성과를 잘 내는 프로그래머 일수록 다른 사람과 대화를 많이 한다
    - 협력(협업)도 프로그래밍의 한 분야로 생각을 해야한다
    - 소프트웨어 개발자가 자동화 될 수 있는 지수는 4%(프로그래머 40%대) -> 협상과 소통을 해야하는 부분이 높다
 
2. 팀의 의사결정은 뛰어난 한 사람에 의해 결정된다(X) 
    - IQ보다는 서로간의 의사소통이 활발한 정도가 중요
    - 팀의 퍼포먼스는 개개인의 구성(기술적 정도)보다는 심리적 안정(사회적 요소)에 의해 결정된다
 
3. 전문가를 모아놓으면 알아서 일이 잘될 것이다(X)
    - 사회적인 요소를 제외하고 전문가라 판단한다
    - 일을 주기전에 혋력하기 위한 방법을 생각해보란 1그룹 / 바로 주어진 1그룹 -> 첫번째 그룹이 더 효율이 높다 -> 의식적으로 고민을 해보는 것이 효율이 높다
 
4. 협력을 잘하는 것은 서로 좋은 관계를 유지하는 것이다(X)
    - 회피적으로 좋은 관계를 유지하는 것이 아닌지 생각해 볼 필요가 있다 (신혼 때 안싸운 부부들이 이혼율이 더 높다)
    - 부정적인 감정을 표현할 수 있는 팀이 퍼포먼스가 더 좋았다
    - 솔직하게 말 할 수 있는 조직이 좋다(합리적인 방법으로)
 
5. 분업을 잘하는 것이 협업을 잘하는 것이다(X)
    - 막상 협업을 하려고 했을 때 단순히 분업하려는 방안만 생각하기 쉽다 -> 단순히 분업화 한다는 것이 협업을 의미하는 것은 아니다
    - 일이 불확실 할 수록(변경이 자주 일어날 때) 팀 단위로 일할 때 퍼포먼스가 좋다 -> 피력 코칭이 이루어졌을 때 -> 대화가 중요하다
    - 복잡할 수록 초기에 분업화하려고 하는데 이렇게 될 경우 서로간의 대화가 없어져 결과적으로 좋지 않은 결과가 나올 수 있다
    - 서로간의 모니터링이 되는 구조일 수록 성과가 좋다
    - 상호 작용이 중요하다

- 분업을 전혀하지 않는 것보다는 어느 정도는 하는 것이 맞지 않을까요? -> 분업을 하지 말자는 것이 아니라 팀 단위에서 고민을 해야 한다는 것이다
- 지속적이지 않은 팀단위 업무를 수행할 때 좋은 조언이 있는지? -> 지속적인 팀단위 업무보다 더 많이 노력해야한다. -> 70%는 프로젝트가 시작하기 전부터 이미 정해져 있다, 20%는 초기에 결정
  처음에 생각해 둔 또는 설계해 둔 방식에 의해 이미 결정이 난다 -> 이미 시작된 경우 바꾸기란 쉽지 않다는 말이다 -> 시작하기 전에 미리 계획을 잘 생각하는 것이 중요하다(협업에 대한 필요가 있을 경우 미리미리 준비)
- 의견을 낼 경우 일의 주체가 의견을 낸 사람이 되는 경우 주도적으로 일하기가 쉽지 않은데? -> 팀내에서 우선적으로 좋은 시도를 한번 해보는 것을 추천한다 -> 아이디어, 일의 수행 주체를 나누어 생각해본다
  -> 일이 5개가 있을 경우 나누어서 각자 하나씩 주는 것보다 2개를 먼저주고 나누어 주어지는 것이 더 효과적이다 
  -> 누구나 하기 싫은 일을 다룰때 효과적으로 처리하는 방법 -> 회의를 통해 이러한 이슈가 있는데 어떻게 하면 좋은 방법(재밌는 방법)으로 바꿀 수 있을가요란 방식으로 처리하는 것이 효율적
- 실수에 대한 두려움이 있기 때문에(성과 측정의 아이러니) 협업시 주저하는 부분이 있는데 어떻게 생각하시는지? -> 조직들이 개인평가에 맞추어줘 있는데 최근에는 동료와의 협업 능력을 측정하는것으로 바꾸고 있는 추세인데
  앞으로 많이 바뀌어야 할 것 같다. / 성과평가가 있기는 한데 그것이 얼마나 효과적인지를 연구한 결과가 있는데 그것이 1,2개월 정도 밖에 지속되지 않는다
  평가체계가 사람에게 미치는 영향은 단기적이다 따라서, 회사의 문화를 어떻게 느끼는지를 고민하는것이 더 좋은 방향이지 않을까 생각해본다
  단순히 평가만으로 조직이 효율적으로 유지되는 것은 아니다.