1월 18일_agile 개발과 넥스터즈에서의 agile 응용
TRANSCRIPT
애자일 (+ 하고 싶은 말)
애자일• 애자일 소개 슬라이드 (http://www.slideshare.net/AstinChoi/agile-7663749)
• 애자일 위키피디아 (http://ko.wikipedia.org/wiki/%EC%95%A0%EC%9E%90%EC%9D%BC_%EC%86%8C%ED%94%84%ED%8A%B8%EC%9B%A8%EC%96%B4_%EA%B0%9C%EB%B0%9C)
• 스크럼 위키피디아 (http://ko.wikipedia.org/wiki/%EC%8A%A4%ED%81%AC%EB%9F%BC_(%EC%95%A0%EC%9E%90%EC%9D%BC_%EA%B0%9C%EB%B0%9C_%ED%94%84%EB%A1%9C%EC%84%B8%EC%8A%A4))
애자일
• “신속한”, “재빠르고”, “약삭빠른”
애자일
• 작고 반복적인 주기 (iterations)을 통해 제품을 개발하는 기법
• 각각의 주기들은 하나의 짧은 프로젝트와 같음
• “시험하고 적용하기”의 반복
기존 vs 애자일
• 기존 (Waterfall)
• 계획, 정형, 문서화
• 애자일
• 반 계획, 경험, 프로토타입
스크럼??
• 애자일 철학을 적용하기 위한 구체적인 방법론 중 하나
스크럼 (용어)
• 스프린트 (Sprint)
• 제품 백로그 (Product Backlog)
• 스프린트 백로그 (Sprint Backlog)
스크럼 (실행 예)• 한 달의 반복적인 개발 주기 (스프린트)
• 제품을 사용하는 ‘사용자 시나리오’를 정리함
• 제품에 필요한 기능을 ‘제품 백로그’에 쌓아 놓음
• 이번 스프린트에서 구현할 기능을 ‘제품 백로그’에서 ‘스프린트 백로그’로 이동
• 스프린트 중에도 매일 (또는 가능하면 자주) 현황을 체크
• 스프린트 기간 동안 해당 기능을 구현하고 스프린트의 마지막에 회고 및 다음 스프린트에 적용
스크럼 - 그림
스크럼 (현황판)
트렐로??
• 애자일 스크럼의 사용패턴을 그대로 온라인으로 옮겨놓은 툴
트렐로 (사용)
• 트렐로 팀이 트렐로를 사용해서 트렐로를 개발하는 모습
• https://trello.com/b/nC8QJJoZ/trello-development
애자일 단점 (주의할 점)
• 프로세스에만 집착하면 팀 모두가 힘들어짐 (특히 개발자는 스프린트마다 밤샘을 하는 경우가..)
• 작은 폭포수(Waterfall)가 되지 않도록 주의
꼭 기억해야 할 사항
• 프로세스에 너무 집착하면 안 됨
• ‘일’ -> ‘사람’
• 소통!! 상호협력!!
애자일의 장점
• 상식적인 판단을 가능하게 함
• ‘우리가 무엇을 해왔는지’, ‘무엇을 하고 있는지’, ‘무엇을 해야 하는지’를 모두가 공유.
• 저비용 고효율의 관리
무엇보다!!
• 재미!!
• 그것이 실제 사용자에게 가치를 줄 수 있는 제품을 함께 만들어 나간다는 주인의식
넥스터즈에서는?
• 애자일의 철학과 정신만..?
구체적으로
• 2월 8일 (3주 후) 에 중간 점검
• 프로토타입
프로토타입?
• 사용 가능한,
• 우리 제품이 무엇을 하려는지 확인할 수 있는,
• 검증하고자 하는 것을 검증할 수 있을 만한,
어떻게?
• 단순화
• 오늘 발표한 수많은 기능 중
• 가장 핵심적인 사용자 시나리오 하나만 정해서
• 오로지 그것만을 위한 기능 몇 가지만 추려내자
단순화를 힘들게 하는 것
• 기능이 많아야 더 좋은 어플 아닌가?
• 너무 간단한 어플을 누가 쓰겠는가?
• 단순하다는 것은 아마추어스럽다.
• 미완성??
반증
• 한 여자가 있습니다.
• 매일 밤마다.. 고뇌.. 슬픔.. 외로움.. 절망.. 세상엔 나 혼자밖에 없는 듯.. 남자친구도 떠나고..
• 그러던 한 여자에게..
반증
• “힘내.. 기운내.. 세상엔 너 혼자가 아니야..”
이팅!
• 눈물
• 가슴 벅차오름
그랬더니..
• 첫 글이 올라온 후 18시간 동안
• 해당 글은 12000회 이상 조회, 580개의 댓글
• 그 이후로 이팅을 캡쳐해 공유하는 사례 300개의 글
이팅의 기능?
• 일기를 쓰고 -> 답장을 보내고 -> 내 일기의 답장을 기다리고 -> 답장을 확인
• 감성적인 UI
단순함
• 단순함 + 날카로움 -> 쓸만한 제품
• 기능이 많을수록 무뎌질 확률이 높습니다.
정리
• 천 명, 만 명, 십만 명, 백만 명이 엉성하게 쓸 제품보다는
• 단 열 명이라도, 열심히, 재밌게, (눈물을 흘리며) 사용할 수 있는 제품을 만들자!!
기능 쳐내는 팁!
• 가장 날카로운 사용자 시나리오 하나만 정하고
• 어떤 기능이,
• 있으면 좋겠다.. -> 빼버리기
• 없으면 우리 앱의 존재가치를 논할 수 없다 -> 넣기
진짜 마지막.. 무엇보다..• 많이 모이고
• 많이 얘기하고
• 많이 잡담하고
• 많이 밥도 먹고
• 치열하게 고민하고
• 재밌게!!
• 앱이 출시 못해도, 다운로드 수가 낮아도
• 남는 건 팀 (같이 일해본 동료)
끝