허니몬(Honeymon)의 달콤한 비행

• 일시 : 2012년 09월 01일 10시
• 장소 : 삼성동 포스코센터 5층 마이크로소프트 컨퍼런스실
• 주최 : Agile Community Network in Korea

  애자일(Agile)이란 무엇일까? 아니 어떠한 것일까? 

   ‘애자일은 실체가 없다.’ 라고 생각하는게 지금까지 내가 가지고 있다.

   빠르고 유연하게 변화에 대응할 수 있도록 짧은 개발주기를 가지고 커뮤니케이션의 효율을 높이면서 생산성을 높이려고 하는 시도를 ’애자일’이라고 생각 하고 있다. 개발을 하다보면 ‘조금 더 빠르게, 조금 더 쉽게, 조금 더 효율성 높게’ 개발하고 싶은 욕심을 품게 된다. 애자일을 이야기하면 상반되는 개념으로 자주 나오는 ‘폭포수 모델’. 거대한 폭포수가 떨어져 내리듯이 어떤 목표를 달성하기 위해 정해진 절차를 따라 진행하는 형태를 지칭한다. 처음으로 참가하는 애자일 컨퍼런스에서 ’애자일이란 무엇인가?’에 대한 해답을 얻을 수 있을까 기대감을 안고 컨퍼런스에 참가했다.

• 발표자 : 황상철
• Agile Korea가 뭔가요?
• 애자일 관련 커뮤니티, 기업, 개인들이 함께 발전하기 위한 연합체(Alliance)
• Agile Korea Conference is Open Source
• 커미터, 컨트리뷰터 -> 자원활동가, 연사
• 집단지성에 의해 컨퍼런스 동안의 내용들도 함께 공유가 된다.
• 무선 와이파이가 제공되었다면 더욱 활발하게 되지 않았을까? +_+)
• Agile Korea Conference 2011 회고
• Agile Korea Conference 의 의미
• 국내에서 애자일에 대한 열기가 많이 사글어들었다고 생각한다. 대기업들은 자신들이 애자일을 통해 효율적이고 가격대비 높은 성과를 거두어오고 있다고 말한다. 그런데 그 기업들이 하는 일들은 ‘과연 신속하고 유연할까?’ 라는 생각에는 긍정적인 대답을 얻기는 어렵다. 여전히 그들은, 그리고 나는 과거의 방법들을 답습하고 있을 뿐이니까. 오히려 대기업들보다 어려운 상황 속에서 성장을 시도하는 작은 벤처, 중소기업에서 이런 시도와 성과가 더욱 분명하게 드러나고 있다고 생각한다. 이렇게 성과를 얻은 분들의 이야기가 많이 들렸으면 좋겠다는 생각은 분명히 든다.

• 발표자 : 최승준
• 알게 되고 준비하기
• 컨퍼런스, 사람들과 나
• 경청하고, 기민하게 반응하고 실천하고
• 애자일의 기본은 '커뮤니케이션(대화와 경청)'에서 시작한다. 그런데 나는 다른 사람의 이야기를 차근차근 들어주는 습관이 없다!!
• 주의사항
• 생경한 경험
• 당황선서
• 나는 혹시 당황하게 되더라도 일단 믿고 참여하고 즐겨본다.
• 제대로 즐기지 못했구나. 잇힝. 낯설은 행사에에서 낯선 사람들과 함께 무엇인가를 한다는 것이 내게는 당황스러웠다. 컨퍼런스나 세미나에서 나는 철저하게 ’그림자인간’이었는데…
• 필요한 것
• 움직일 필요
• 필기도구 필요
• 용기 필요
• 태도 필요
• 위의 것들은 애자일을 시도할 때 필요한 것이라 생각한다.
• 낯선 경험.
• 책걸상을 모두 뒤로 밀어내고 컨퍼런스에 참가한 사람들이 불규칙한 원자가 되어 발표장을 오가면서 작은 실험들이 진행되었다. 원자들은 불규칙하게 운동하면서 서로 부딪치기도 하고 경우에 따라서 서로 결합하기도 한다. ‘사람들이 아무말 없이 서로 모여들고 암묵적인 동의를 나누면서 어떤 결과를 얻어낼 수 있다.’ 이 발표에서 보여주고 싶은 것이 아니었을까? ^^; 하지만 나를 포함한 대부분의 사람들이 익숙치가 않고, 장소의 구조가 좌우로 길게 되어 있는 형태였기에 사람들이 자유롭게 움직이기보다는 방의 구조를 따라 회전을 하듯 돌아갈 수밖에 없는 상황에서는, 의도했던 바와는 전혀 다른, 상황들이 벌어질 수밖에 없었다. 천천히 돌고 있는 사람들 틈에서 멈춰서기란 쉽지가 않았으니까. 무엇인가 느낌이 통해 모이는 사람들은 흐름의 바깥으로 벗어나야 했다. 그것은 생각보다 많은 용기를 요한다. 애자일도 그렇다. 기존의 방식을 바꾸기 위해 그것을 벗어나려고 하는 순간을 결정하고 실행하기 위한 ’용기’가 필요하다. 새로운 것을 배우고 익히고 내 것으로 만드는 과정은 생각보다 힘들고 고되다. 그 힘들고 고된 순간을 견디고 한발한발 앞으로 나아갈 용기가 필요한 것이다.

• 발표자 : 경기원(LG CNS 전문기술교육팀)
• LG CNS Agile History
• 발전단계
• 적용현황
• 적용건수
• 실천기법 적용
• XP < Scrum
• Agile 재적용 희망
• 야근 및 특근
• 정성적 효과
• 품질 : 90%
• 내부 품질 강화
• Feedback을 통한 검증
• 생산성 : 83%
• 의사소통 -> 리스크 조기 식별/해결
• 참여 & 책임감
• 적용사례
• 모바일 교보문고
• 이걸 보면서, LG CNS에서 성공한 애자일 적용사례는 ‘모바일 교보문고’ 뿐인가 하는 생각이 들었다.
• 애자일 교육
• 협력사를 위한
• 개발자를 위한
• 실무자를 위한
• 변화인식을 위한
• 개발예정
• 애자일 프로젝트 관리
• 애자일 테스팅
• 애자일 모델링
• 게임으로 플어가는 애자일
• 애자일 코치(Agile Coach) 육성 프로그램
• 회사 내 공감대
• 공감대가 커지고 있다.
• 애자일에 대한 오해
• 스크럼미팅이 전부인 것처럼 이야기
• SI : 소규모에 적합하지, 대규모는 맞지 않다.
• 분석/설계는 거의 없이(?) 바로 코딩
• 기존 방법론을 대체하는 것?
• 애자일은 국내 하도급법과 상충?
• 고객과 계약사가 한곳에서 있으면 안되는거야?
• 외부 감리 대응이 어려울 것이다?
  
• 
• 
  
• Traditional vs. Agile
• 목표는 같다.
• 틀리고 맞고가 아님
• 해오던 방식과 크게 다르지 않다.
• SDLC??
• TDD
• Saligo 원칙 : 5분 원칙
• TLP -> TFP -> TDD
• Agile Practices 그대로 따라하면 되지 않나요?
• Agile Best Practices를 그대로 따라하기 보다는 insight를 가지고 우리팀만의 것으로…
• 우리가 애자일을 하고 있는지 어떻게 알 수 있나요?
• 심리학, 인문학도 중요
• 똑똑한 사람보다 노력하는 사람이 더 많이 배우고 가르칠 수 있다.
• 애자일은 빨리 실수를 경험해야 하는 게 아닐까?
• 들어가며
• “30년간 변하지 않은 SW공학 30가지 이슈”
• 참고사이트 : http://dientra.egloos.com/m/5283534
• 초기 유구사항의 50% 이상이 완전하지 못하다.
• 문서를 작성하는 것은 두 번째로 비싼 소프트웨어 활동이다.
• LG CNS 는 2008년 부터 애자일을 도입했다?
• 그런데 왜 회사의 직원들은 그것을 체득하지 못했을까?
• LG CNS는 직원들이 애자일을 체득할 수 있도록 지원하고 있는가?
• Agile 코칭 육성
• 애자일을 지도할 사람이 아니라, 팀단위로 교육을 진행하여 팀원들에게 ’애자일을 해야하는 이유’에 대한 공감을 이끌어내고 애자일을 지속할 수 있도록 지원하는 것이 되어야 할텐데…
• 애자일 코치는 몇일의 교육으로 육성될 수 있을까?

‘모바일 교보문고’ 참여 개발자로서

• LG CNS의 애자일 적용 성공사례는 ’모바일 교보문고’가 유일한가?
• 다른 성공사례는 없는가?
• 난 ’애자일인 척 한 프로젝트’였다고 생각한다. 내가 '애자일'했다는 생각이 안드니까...
  오히려 개발진보다 고객 측에서 조금 더 적극적으로 임했다고 생각한다. 어쨌든 고객 측에서는 성공을 해야하는 절실함이 있었으니까 그러했을거라 생각한다. 개발하는 동안, 관련한 업무에 대한 현업 담당자들과의 회의를 주선하고 지원하려고 노력한 고객은 흔치 않으니까. 
  
    ‘고객의 적극적인 참여’ 이건 어느 SI프로젝트에서도 성공을 좌우할 수 있는 중요한 기준이라고 생각한다.
    소극적이거나 고압적이고 일방적인 자세를 가진 고객을 대상으로 하는 프로젝트는 쉽게 성공할 수 없다. 고객 탓을 하려는 건 아니다. 손바닥도 마주쳐야 소리가 나는 법이다. 고객이 계약자들과 최대한 많이 만나고 이야기를 하면서 점점 프로젝트의 완성도가 높아진다고 생각한다. ‘고객은 자신이 원하는 것을 모른다.’ ‘개발자도 고객이 원하는 것을 모른다.’ 서로 무엇을 원하는지 모르는 상태가 길어지면 길어질수록 결과물은 서로가 상상하던 모습과는 점점 다른 모습으로 변모해간다. 그러다가, ‘니탓내탓’ 하면서 싸운다. ‘만들고 싶은 모습을 서로가 상세하게 알 수 있도록 상세히 기술하고 이야기하자.’ 내가 이런 생각을 가지고 연애를 했으면… 이미 장가를 가서 애를 낳아도 셋은 낳았겠지. Orz.

• 발표자 : 클럽베닛 CEO 정지웅(jwchung@clubvenit.com)
• 삼성전자, NC 소프트 오픈마루 스튜디오
• (주) 플라이팬 창업
  
• 
• 
  
• 애자일 프로세스가 창업에 적용이 된다면 어떨까?
• 애자일이 다른 분야에 적용이 된다면 어떨까?
• Startup
• 극도로 불확실한 상황속에서도 세상에 존재하는 문제를 해결하여 사업화하려는 목적을 가진 조직
• 특수목적 조직
• 불명확한 문제들을 명확하게 하여 해결책을 내놓는 조직?
• 특성
• 문제, 해답, 시장상황, 자원의 변화 모든 것이 불확실
• 스타트업 == 불확실성
• 90% 이상의 스타트업이 실패한다.
• 스타트업의 실패이유
• 고객이 원하는 진짜 문제를 찾아내지 못함
• 진짜 문제를 찾았더라도 그에 맞는 해답을 찾아내지 못함
• 진짜 해답을 찾았더라도 그 해답을 증명하기 위해 너무 많은 비용을 소모
• 많은 비용이 뒷받침되더라도 많은 시간을 소요해 시장의 상황이 달라지면 문제와 해답은 무효가 됨
• 대부분의 스타트업이 문제-해결-비용-타이밍의 4가지 요소에서 확실성을 확보하기 전에 모든 자원(사람, 기회)를 잃고 소멸됨
• 프레드릭 윈슬럿 테일러
• 예측 가능한 문제들을 통제하면 프로세스 확립이 가능하다.
• Paypal
• Pivot : 방향전환
• 빠른 Pivot을 통해 그 실패의 간격을 줄여나간다면 성고으이 확률을 조금씩 올릴 수 있음(우리에게 주어진 자원과 금전이 모두 떨어지기 전에)….

• 린 스타트업 이론(Lean Startup Princple)
• Eric Ries
• 더 적은 비용으로 자주 실험해서, 시장의 요구를 해결하는 신규 사업, 신규 서비스의 성공확률을 높이는 경영/프로덕트 개발 방법
• 스타트업 예 - Platform Business
• 1forMe
• Etsy Copycat
• Sellers Market
• But Where’s the customer?
• Didn’t Focusing on Real Problem
• Torsto
• 카페, 블로거들과 공동구매에 대한 관리
• Innovative BM on Existing Problem
• Demands from Two sided Market
• But Market Timing is Bad(Or Out solution is too outdated)
• Didn’t Focusing on Real solution : 진짜 해결책!!
• It’s not a scalable Solution
• 고객의 문제가 명확할 때, 그 문제를 파악해 해결책을 제시
• Lean Startup (고객의 요구사항에 따라서 변혀됨)
• 고객이 있는지
• 고객이 좋아하는지
• 고객이 비용을 제공하는지
• 요구사항이 바뀔 때 마다 변화
• 스타트업 예 - Before CV is born
• CV : Private 쇼핑 클럽 = 명품을 온라인에서 싸게 판다.
• 많은 문제를 해결할 수 있는가?
• 고객이 원하는 것 
• Minimize the total time through the loop
• IDEAS
• BUILD
• CODE
• MEASURE
• DATA
• LEARN : learn for
• Experince(3)
• IDEAS : It’s all about Uncertainity
• 1 What’s Problem?
• BUILD : Minimum viable Product
• 피드백이 없으면 성공확률이 떨어진다.
• 빨리 줄이고, 빨리 코딩하고, 빨리 내놓아라.
• Measure : Actionable Metrics
• Actionable
• Accessible
• Auditable
• Data : What matters MOST?
• Metrics… Metrics… Metrics…
• 정답
• 어떤 것이 답이 될지 모르는 상황
• 우리에게 가장 중요한 지표가 있는가?
• Real problem
• 업체가 가장 원하는것? 인프라, 퀄리티, 프로ㅔ스, 브랜드
• 고객이 가장 원하는 것? 서비스, 신뢰, 가격, 상품…
• 우리가 가장 잘 할 수 있는 것?
• 한정된 자원으로 우리가 해낼 수 있는 것?
• 결국 가장 중요한 것에 집중하고, 그 중요한 것이 맞는지 빠르게 확인하는 과정의 연속
• 가장 중요한 것 하나에 집중하고 나머지를 버리는 과정

• Lean Startup Principle can be adopt anywhere

• 답을 알기 힘든 큰 변화를 추구하는 개인
• 신규 서비스를 추진하는 대규모 조직
• 신규 사업을 추진하는 내부 조직
• 스타트업과 같은 신규 사업을 목적으로 하는 기업형태
• 불확실성, 불확정성의 시대, 100%의 해답은 없지만
• 빠르게 실패하는 방법 :
• 단, Pivot 앞에 용기를 낼 수 있을 때만 실천 가능한 방법

• Club Venit : Past, Present and Future
• Past : Lean Principle 로 빠르게 다양한 가설을 검증
• Present : 가장 적은 비용으로 시장에 안착
• Future : 아직 남겨진 더 큰 숙제
• Take a risk, Enjoy a uncertainity!!
• 온갖 불확실성이 주는 변화에 기민하게 대응할 수 있다면, 그 위험을 감수할 수 있는 굳은 신념이 있다면, 무한한 기회는 여러분의 것입니다.
• 내가 원하는 것은 무엇인가? 그것을 감내할 수 있는가? 결정의 순간 Pivot할 수 있는 용기가 있는가?
• 새로운 변화를 시도해볼 수 있는가?
• Lean Startup에 접근하는 Role 의 역할을 수행하는가?

• 들으면서 든 생각은, ’정말 발표를 잘하신다.’라는 생각을 가졌다. 
• 성공과 실패.
• 스타트업을 하게 되었을 때, 성공과 실패는 ’필연’적으로 따라오는 녀석인 듯 하다. 이 녀석에 대해서 예민하게 반응하고 대비할 수 있을 때 ‘스타트업에서 살아남을 수 있겠다’ 라는 나름의 자신감을 가질 수 있겠다.
• 중요한 것은, ’고객’이 해결하길 바라는 ’진짜 문제’를 빠르게 찾아서 시기적절하게, ’고객’이 바라는 ’해결책’과 함꼐 내놓는 것.

• 발표자 : 황상철
• 스펙을 한번만이라도 제대로 작성해 본적이 있는가?
• http://allofsoftware. / 251
• 스펙(Specification)
• 문서, 다이어그램
• 언제, 얼만큼의 스펙을 작성해야 하는가?
• 스펙은 개발할 수 없을 때 작성하는 것이다.
• 개발자가 UML을 잘 모르는게 잘못인가?
• notification 이다?
• 스펙과 코드가 일치하지 않는게 정말 문제인가요?
• 문제다?
• Living Document
• Specification By Example
• Spect == Code, System
• Specflow, Pragmatics BDD for .net
• 문제가 아니다
• 스펙은 스냅샷!
• 코드를 봐라!
• 스펙은 개발을 위한 스펙이다.
• Markdown
• 작성하기 쉬워야 한다.
• 완료조건
• 완료조건
• 개발 완료조건을 구체적으로 서술
• 개발이 완료되었는지 확인한다.
• Tesing
• ATDD : Acceptance Test Driven Develpement
• BDD : Behavior Driven Developement - 행위에 대한 테스트
• Spec by Example
  작성한 스펙과 개발내용이 일치하지 않을수도 있다.
• 그러나 변화하는 개발 내용에 맞춰서 스펙도 변화할 수 있고, 이를 기록해두는 것이 좋다.
• 기록하기 쉬운 방법을 사용해라.

• 발표자 : 김창준

• 내가 배워가서… 조직에 애자일을 적용할 수 있을 것인가?
• 질문에 대한 답변을 듣는다?
• 뻔한 이야기
• TDD 실천법
• 회사 사장이 아닌 내가 조직에 TDD를 적용하려고 한다면?
• RISK
• 단순한 상황(Simple)
• RISK가 있는 상황
• 위험이 발생할 경우들이 존재하고 확률이 존재할 떄
• 도박의 경우에는 RISK가 잘 맞는다.
• 불확실한 상황
• 각각의 확률, 경우를 알 수 없을 때
• 불확실할 때의 적절한 대처방법 == MBA 졸업자들과 성공한 사업가들
• 대기업은 불확실성이 낮다.
• 개인이 조직에 변화를 가져오는 방법은 불확실한 상황
• 회사를 잘 키우는 매니저들 == 성공한 사업가들의 전략을 사용
• 성공한 사업가들의 전략(5가지 전략)
• 포츈 매니저와 MBA 갓졸업자들
• 실패하고 있다면 5가지 전략을 위배한 것이다.
• 손 안의 새(손 밖의 새보다 낫다).
• 방법 중심인가? 목표 중심인가?
• MBA 갓 졸업자들은 목표를 먼저 정하고 가용가능한 수단들에서 선택
• 성공한 사업가들은 자신이 가지고 있는 방법들을 먼저 생각하고 그 방법들에서 달성하려고 하는 목표를 생각한다.
• TDD 도입은 실패할 가능성이 높다. 골을 대상으로 하고 있기 때문에…
• 내가 누구인가?
• 내가 아는게 뭐냐?
• 내가 모르는게 뭐냐?
• 내가 할 수 있는게 뭐냐?
• 상황이 불안할수록 사람들을 끌어모아 경쟁을 유도해라?
• TDD 성공전략
• TDD 스터디를 함께한다.
• 혼자 스터디를 해서 알게되면 불리한 입장에 놓이게 된다.
• 
  
• 감당할 수 있는 조건
• 성공한 사업가들 : 잃어도 되는 돈의 양을 고려
• MBA 갓 졸업자들 : ROI를 먼저 작성한다. 잃지 않으려는 방법들을 강구
• Pilot in plays
• 대응할 수 있다고 믿을 수 있는 컨트롤
• 컨트롤할 수 있을만큼은 예상 안해도 된다.
• 레모네이드 컨텍스트
• 너에게 레몬을 주면 레모네이드를 만들어 팔아라.
• 주어진 것을 이용할 것인가? 팔 것인가?
• 변화를 도입할 때, 도입을 시도하는 사람이 변화를 막고 있을지도 모른다.
• 작은 성공들을 만들면서 진행해라.
• 변화를 시도하려 할 때, 누군가가 먼저 배워서 이를 Top-Bottom 형식으로 전달하려고 하지 말아라.
• 먼저 배운 사람에게 숙제가 주어지는 것이다.
• 변화를 시도할 때는 함께 시작한다.

• 발표자 : 정기원

이전다음

0123456789101112131415161718

• 유니콘이라 불리는 인재
• 스타트업 이노베이션에서 살아남기 위해 필요한 인재
• 인재를 구하면서 느낀 낙심함
• 비난, 정정과 도전!!
• 유니콘형 인재
• 인력풀 : 스타트업에서는 유니콘형 인재가 필요하다!
• 유니콘형 인재를 추구하게된 배경
• 중세적인 때에는 수직적으로 자신의 직업에 묵혀 있었다.
• 중세이후에는 수평적으로 되었다.
• 산업혁명 이후 수직적인 재편이 이루어짐
• 19세기 말부터 산업디자인
• 요즘은 수평적으로 활동하는 사람들이 나타났다. 수평, 수직적인 혼재가 발생
• 제너럴리스트는 유니콘 인재가 아니다.
• 제너럴리스트와 유니콘은 다르다. 서로가 활동하는 영역도 활동하는 모습도 전혀 다르다.
• 여러개의 전문적인 역할을 수행하고, 기업이나 스타트업에서 발생하는 여러가지 문제를 해결할 수 있는 사람.
• T자형 인재 : 참고  http://blog.joinsmsn.com/media/folderListSlide.asp?uid=jealivre&folder=17&list_id=8472759
• 한분야에 정통하면서 다양한 분야와 협력해서 일할 수 있는 사람.
• 다른사람과 협업할 수 있는 사람들은 ’공감(Empathy)’할 수 있는 사람들이다.
• 왜 실리콘 벨리에서는 유니콘형 인재를 찾는가?
• 디자인
• 개발
• 마케팅
• 잘 나가려면?
• 최근의 추세 : 37 signals, 53(ipad app paper)
• 8가지
• Love your problem. 너의 문제를 사랑해라. 
• 가려운 곳을 긁어라.
• 세상에 대한 의견, 가치관, 관점이 있다는 것을
• Love Your Customers. 사용자들을 사랑해라. 
• 사용자를 행복하게 하라.
• Make Opinionated Product. 입장이 분명한 제품을 생산하라.
• MS 타블렛 PC와 애플 iPad!
• Cross Function!새로운 것을 시도하라!!
• 안해본 것을 해야 새로운 것을 해볼 수 가 있다.
• 안해본 것에 대한 도전을 통해 새로운 생각을 할 수 있게 된다.
• Learn Quickly! 함께, 빨리 만들어봐라!! 
• Momentum-Sensitive
• 성공에 대한 경험을 가지고서, 그 경험 속에서 결과물을 얻어낸다.
• Quick Decisions! 빠른 결정
• 자신의 가치관을 가지고 빠르게 결정하고 빠르게 활동하는 것
• 사용자를 위해 제품을 더욱 심플하게 만들어라
• Good Communication! 좋은 대화자이다! 
• 가치관을 가지고, 모르는 것을 물어보고, 사람들과 대화를 나누고…
• 글 잘쓰고, 말 잘하는 사람을 찾는다.
• 가치관에 관한 것, 세상을 개선하겠다는 의지, 열정을 가지고 있는 사람
• 태도의 문제다! Resume, Skill의 무제가 아니다.
• 수요는 높으나, 공급이 적다.
• 유니콘은 갑자기 나타나지 않는다.
• 기업이나 스타트업에서 필요로 하는 역량들을 이미 습관으로 가진 채로 성장한다.
• 그런 역량을 가진 직원을 유니콘으로 키우기 어렵다.
• 이야기만 들어서는, 유니콘을 키우기 위한 노력은 했는지에 대해서는 의문이 든다. 이들이 말하는 유니콘은 짧은 시간에 불쑥 나타나지도, 성장하지도 않는 그런 인재였는데 말이다.
• T형 인재 이상을 찾아야 한다.
• 유니콘 목장은 뭔가?
• 유니콘형 인재를 육성할 수 있는 곳…
• LAB80 : http://lab80.co/
• 인턴을 통한 8주
• 미국의 투자자들이 자신들의 가치에 맞춰서 한국에 투자할 수 있도록 해주는 기업
• 서울에서 얼마 안되는 유니콘들을 육성하는 곳이다.
• Set up an environment
• 공통의 목표를 가진 환경을 구축
• 공통의 언어
• 기본적인 구조와 프로세스를 구축
• 어느 방향을 향해 달려나갈 것인지에 대한 공감대를 형성하고 공유
• We all run as fast as we can
• 각자 최선을 향해 달려간다.
• see who keeps up
• 달려가는 상황을 보면서, 누가 달려가는 것인가
• LAB 80 실험
• Weekly release
• Weekly user tests
• customer feedback 등을 얻음
• 8주 결과
• 5개 프로토타입, 11개 릴리즈
• 와중에 20명의 인터뷰
• 잘 달리는 사람들
• 자기에 대한 ’욕심’을 가지고 있는가?
• 제너럴리스트는 유지하지 못한다.
• 보여줄 거리…
• 위급한 상황에 보여줄 꺼리(스페셜티)를 보여줄 수 있어야 한다.
• 문화적으로 맞는 사람인가?
• 관점이 맞는가?
• 한달에 한번 정도 실리콘 밸리 사람들과 뛴다.
• 유니콘 목장은 어떻게 만들 수 있을까?
• 유니콘이 되고 싶다면, 유니콘과 일하고 내가 성장할 수 있는 것을 봐라
• Work with unicorns and see if you can grow into one.
• 대중이 없다. 깨울 수 없다.
• Either you are unicorn material or you arent’.
• 사람들을 계속 고용하고 방출한다.
• We have to be rigorous and selective in the beginning.
• 한국에서 유니콘 목장 만들 수 있을까?
• 서울에서 7개월 동안 20명과 인터뷰를 해보고 1명을 만났다.
• 한국에서 인터뷰를 하면서 듣기 싫은 3가지 대답
• 스타트업에서 일한 후에 삼성이나 구글에서 좋은 일을 찾고 있다.
• 스타트업을 하는 것은 특권이다?
• 새로운 기술을 배워야 한다면? 책을 사고 공부를 시작해야지.
• 교과서를 본다고? 엿먹어! 하면서 배워!
• 실패할 줄을 모른다. 실패를 해야할 때는 실패해야한다.
• 올바른 답을 떠올릴 때까지 대답하지 않는다.
• 알고 있는 지식에는 관심없다. 문제를 풀어라(해결하라!).
• 알고 있는 것을 하고 있다면 돈 못벌어.
• 모를 때는 질문하고, 그에 대한 반응을 얻고, 해결책을 찾고 나아가자.
• 한국에서 인력풀에 대한 회의적인 생각…
• 연락처 @keywonc lab80.co
• 비난하기 어렵다.
• 지금 우리나라 교육체계를 보면, 그런 유니콘형 인재가 자라나기 어려워보인다는 것은 누구나 공감할만하다.
• 순간 ‘욱’ 해서 ’그렇지 않아! 우리나라는 자원이 부족하지만 뛰어난 인력으로 지금의 경제성장을 달성 했…’다고 말할 수 있겠지만, 그건 경제호황기에 ’기업이 바라는 인재를 원활하게 공급하기 위한 교육체제’가 확고히 된 시점에서, ’다음을 위한 도약의 성장’을 위한 발판을 잃어버렸다는 것을 뜻하기도 한다.
    지금 대학생들은 ’토익’과 해외어학연수 등에 목숨을 걸고 있다. 대기업에 들어갈 수 있을 법한 ’스펙’을 구축하는 데에 혈안이 되었다. 기업은 ’우리가 그런 스펙을 쌓고 오라고 한 적 없다.’라고 이야기 하지만, 기업에 들어가는 인재를 보면 ’그런 스펙’을 쌓은 사람들만 들어간다. 그러니 기업에 들어가기 위해서 더욱 혈안이 되어 ’그런 스펙’을 쌓으려고 하는 것이다.
    이런 현실 속에서 ’유니콘형 인재’가 태어날 수 있을까? 어려서부터 ’대학에 들어가고, 졸업해서 대기업에 취직’하기 위한 교육체제가 확고해진 우리나라에서, ’자신만의 뚜렷한 가치관을 가지고, 자신의 능력을 믿고, 다른 사람에게 인정받는 자’가 성장할 수 있을까? 그런 ’인재’는 ’사회적인 부적응자’로 분류되어 도태시켜버리는 시스템을 가지게 된 우리나라에서 말이다.
• 난 ’유니콘형 인재’가 아니다. 나는 ‘제너럴리스트(Generalist, http://ihoney.pe.kr/notice/241)’다.
  lab80가 필요한 인재는 ’유니콘형 인재’이고, 나는 ’제너럴리스트’를 지향하고 있는 사람으로서 나와는 맞지 않는다. 거기엔 못간다. 안갈 수도 있다. 하지만, 약간의~ ’도전심’을 불러 일으킨 것은 사실이다. 난 아직도 ’내가 할 수 있는 일’들이 뭐가 있을까 하고 찾아다니고 있는 상황이니까.
• 새로운 도전을 하고 싶은 욕심이 다시 생겼다.
• 많은 이들의 '반발심'을 불러 일으켰지만, 누구도 '내가 유니콘이다' 라고 주장할 수 있는 사람은 몇 없었다.

  이번 '코리아 애자일 컨퍼런스 2012'는 처음 참가하였다.

  내가 기대했던 '애자일이란 무엇인가?'에 대한 답은 얻었는지 모르겠다.

  중간에 있던 쉬는 시간 중에, '애자일이란 무엇인가?' 에 대한 대답으로 '변화와 반응'이라고 적어냈다.

  ['애자일'은 요구사항 변화에 대한 '신속한 대응'이 가능한 태도]

  라고 생각하니까.

    해답보다는 '더 많은 숙제'를 안게 되었다. Orz...

  컨퍼런스에 참가하면 '해결' 보다는 '숙제'를 더 많이 받아오는 신세라니...

• 스타트업
• 이번 컨퍼런스에서 사람들은 ‘애자일’ 보다는 ’스타트업(Start-up)’에 대해서 더 많은 이야기를 듣지 않았을까?
• 실패할지도 모르는 상황 속에서 ’도전’할 수 있는 용기를 나는 가지고 있는가?
• 이런 생각을 적었더니, ’지금 있는 곳에서 변화를 일으키는 것도 능력입니다.’라는 대답을 들었다.
• 틀린 말은 아니다. 그런데, ’내게 그 능력이 있는가?’에 대해서는 의문이다. ’낯선 곳에 빠르게 적응하고 내 할 일을 찾고 ’일 못한다는 소리’는 듣지 않도록 열심히 하는 능력’은 가지고 있다. 이건 지금까지 내가 ’해봤던 일’이니까.
• ’지금 있는 곳에서 변화를 일으키는 것도 능력’을 가지고 있다는 생각은 들지 않는다.
• 그건 내 성향과도 맞지 않는다.
• 자의던 타의던 ’변화화는 환경’에 적응하는 능력을 키우는 데 중점해온 나로서는 ’환경을 변화시키는 능력’에 대해서는 전무하다는 판단을 한지 오래니까.
• 시도는 해봐야겠지.
• 기회가 찾아오면 잡아라.
• 요즘 들어 드는 생각
• ’기회의 여신은 뒷머리가 없다’라는 이야기를 아는가? 기회의 여신을 보고 ‘아차’ 싶어서 손을 뻗지만 그녀의 머리카락도 잡을 수 없다는 뜻으로, 찾아오는 기회를 단번에 낚아챌 ’만반의 준비’를 항시 하고 있으란 이야기다.
• ‘하고 싶은 일을 할 수 있는 스타트업 기업을 찾아볼까 합니다’ 라는 내 이야기에
• ‘그건 나중에 해요. 지금은 큰 기업으로 갈 수 있다면, 큰 기업으로 가요.’ 라는 ’인생 선배’의 답변
• 뜨끔.
• 지금 나는, ’해보지 않고, 그건 별거 없어 보여서 안했어.’라고, 허세를 부리고 있는 건 아닐까?
• 조금더 구차하고, 속없어 보이고, 처절하게 올라가보는 것이 좋지 않을까?
• 내가 ’무언가를 시도’할 수 있는 시간(기회)는 점점 줄어들고 있다. 할 수 있을 때라면 해야한다.

• 컨퍼런스 중에 사람들이 남긴 글들이 모여있다. 참가한 사람들의 그 때 마음을 엿볼 수 있는 기록이다.

전체 문서 내용은 아래 링크에서 확인이 가능합니다. 

http://goo.gl/bl3Hw

“30년간 변하지 않은 SW공학 30가지 이슈”

• 출처 : http://dientra.egloos.com/m/5283534
• 원문 : http://senet.egloos.com/2573475
• 내용 :

30년간 지속된 30가지 SW공학 이슈

by Capers Jones ("Estimating Software Costs")

1. 초기 요구사항의 50% 이상이 완전하지 못하다.

2. 요구사항은 개발 중에 한달 평균 약 2% 정도 씩 증가한다.

3. 초기 요구사항의 약 20%는 두 번째 이후 명확해진다.

4. 버그를 발견하고 조치하는 것이 가장 비싼 소프트웨어 활동이다.

5. 문서를 작성하는 것은 두 번째로 비싼 소프트웨어 활동이다.

6. 코딩은 세 번째로 비싼 소프트웨어 활동이다.

7. 회의와 논의가 네 번째로 비싼 활동이다.

8. 대부분의 테스팅 형식은 버그를 발견하는데 30% 미만의 효율성을 보인다.

9. 대부분의 테스팅 형식은 테스트될 코드의 50% 미만을 터치한다.

10. 소스코드보다는 요구사항과 설계에 더 많은 결함이 존재한다.

11. 소프트웨어 자체보다는 테스트 케이스에 더 많은 결함이 존재한다.

12. 요구사항, 설계 및 코드에 FP당 평균 5개의 결함이 존재한다.

13. 배포전 전체 결함 제거 효율성은 평균적으로 약 85% 수준이다.

14. 소프트웨어 결함의 약 15%는 고객에게 전달된다.

15. 고객에게 전달된 결함은 조치 비용이 비싸고 고객 불만을 야기시킨다.

16. 약 5%의 응용프로그램이 전체 결함의 50%를 내포한다.

17. 모든 결함 조치 중 약 7%에 새로운 결함이 내포된다.

18. 소프트웨어 재사용이 결함율 0에 접근할 수 있는 유일한 효과적인 방법이다. 

19. 소프트웨어 아웃소싱 계약의 약 5%가 법정 다툼까지 간다.

20. 1만FP 이상 프로젝트의 약 35%가 취소된다.

21. 1만FP 이상 프로젝트의 약 50%가 1년 정도 지연된다.

22. 대부분의 비용 견적 실패는 지나치게 낙관적인 것에 기인한다.

23. 미국에서 생산성은 1MM당 약 10FP 이다.

24. 개발 할당 범위는 1인당 약 150FP이다.

25. 유지보수 할당 범위는 1인당 약 750FP이다.

26. 미국에서 FP당 개발비용은 약 1200불이다.

27. 미국에서 FP당 연 유지보수 비용은 약 150불이다.

28. 응용시스템을 전달한 이후 사용하면서 1년에 약 7%정도 증가한다.

29. 평균 결함제거율은 1개월에 약 10개정도이다.

30. 프로그래머는 현재를 유지하기 위하여 연평균 약 10일의 교육이 필요하다.