그누보드 - Getting Real 이라는 방법론의 요약입니다.

Getting Real 이라는 방법론의 요약입니다. > 토크

토크

개발과 관련된 어떤 얘기도 괜찮습니다.

Getting Real 이라는 방법론의 요약입니다. 정보

Getting Real 이라는 방법론의 요약입니다.

본문

아래 내용을 읽고 숙지하세요

Getting Real 이라는 방법론의 요약입니다

모르는 용어는 직접 찾아보세요

검색을 생활화하세요.

1. 소개 getting real이란 : Getting Real은 보다 작고, 빠르고, 좋은 소프트웨어 구축을 위한 방법입니다.

2. 출발점 build less(적은구현) : 적은구현은 유연함을 의미합니다 가려운 곳을 직접 긁어라 : 스스로 직면한 문제를 스스로 해결할때 더 나은 제품이 나오는 것입니다 일정과 예산은 고정시키고, 범위를 유연하게 하세요 : 일정과 예산을 맞추려면 범위를 줄여야 한다, 모든것을 다 갖추려고 하면 일정과 예산을 맞추기 어렵다. 적은구현으로 일정과 예산을 맞추고 범위는 추후 늘려나가면 된다.

3. 가볍게 유지하기 가벼울수록 변화하기가 쉬워집니다 : 작은규모는 방향변경을 쉽고 신속하게 할 수 있습니다 변화에 따른 비용을 적게하세요 : 변화에 유연해야한다 버전1.0은 3명의 팀으로 개발하라 : 사람이 많다고 잘되는것은 아닌듯.

4. 우선순위 초기에는 시시콜콜한 것들은 무시하세요 : detail한것보다는 큰그림을 먼저그려야 아직 발생하지 않은 문제를 위해 시간을 낭비하지 마세요 : 나중에 생각하고 고치면 됨 핵심고객에게 집중하세요 : 모두를 만족시키려하다보면 산으로 간다 확장은 나중에 : 작게 시작해서 조금씩 살을 붙이는 방식으로.

5. 기능고르기 반은 엉망인 제품을 만들지 말고 반만 만들어도 제대로 만드세요 : 그러려면 작고 적게 시작해야 핵심적인 것만... : 핵심에 집중해야 기능들이 쉽게 구현되지 않게 하세요 : 기능을 더하기 보다 뺀다는 생각으로 소프트웨어를 범용적으로 만들어서 사람들이 그들만의 방식으로 사용할 수 있게 하세요 : 너무 많은 기능으로 사람들을 가두려 하지 말아야.. 기능추가 요구는 잊어버리세요 : 필요한 기능은 요구사항이 많을것이고 그것은 나중에 구현하면 된다.

6. 프로세스 실제로 실행가능 한 것을 빨리 만드세요 : 빠른 구현과 잦은 iteration 반복작업 : 빠른 구현과 잦은 iteration 브레인스토밍 > 종이스케치 > HTML 페이지 만들기 > 코드작성 : 코드는 제일 나중에 사용자 설정을 피하세요 : 사용자 설정이 필요없는 게 최선 실제로 사용되는 방식을 통해서 어플리케이션을 테스트하세요 : 실제의 시나리오대로 테스트하세요 일을 쪼개세요 : 기능도 쪼개고 일도 쪼개고 나눌수록 유연해집니다.

7. 조직 여러부서로 나누지 마세요 : 커뮤니케이션이 가장중요 사람이 일을 해내기 위해서는 방해받지 않을 시간이 필요합니다 : 몰입의 시간... 회의를 하지 마세요 : 꼭 필요한 회의만 오늘 당장 무엇이든 릴리즈하세요 : 작은 반복으로 잦은 릴리즈를..

8. 채용 속도를 내려면 투입의 속도를 늦추세요 : 사람을 당장 투입하지 마세요 먼저 지원자와 함께 일하는 시험기간을 가지세요 : 페이퍼만 보고 채용하지 마세요 오픈소스에 기여한 내용을 보고 대상자를 판단하세요 : 오픈소스기여자는 검증된 사람 딱 한가지만 할수 있는 사람보다는 빨리 배우며 여러가지를 잘 할 수 있는 사람을 선택하세요 : 멀티플레이어가 되어야.. 열정적인 사람을 찾으세요 : 열정앞에 장사없다 글잘 쓰는 사람을 채용하세요 : 엔지니어에게 찾기 힘들지만 글잘쓰는 사람이 유리하긴 하죠.

9. 인터페이스 디자인 프로그래밍을 시작하기 전에 인터페이스부터 디자인하세요 : 코딩은 나중에 페이지의 가장 중요한 부분부터 시작하세요 : more important first, less important last 일관성보다는 문맥 : 무조건적인 일관성보다는 문맥에 맞는 유연함이 필요할때도 있다 카피라이팅도 인터페이스 디자인 : 네이밍 등도 신중히..

10. 코드 최대한 코드를 심플하게 유지하세요 : 작은것이 최고다 여러분의 팀에 흥미와 자극을 줄 수 있는 개발환경을 선택하세요 RSS, API 등을 통해서 데이터를 세상으로 보내세요 : 외부와 소통하세요

11. 문서와 글 기능명세서를 작성하지 마십시오 : 보지 않을 문서는 만들지말자 불필요한 문서작업을 줄이세요 : 역시나 스토리를 작성하세요 : 사용자 경험에 집중하세요 현실의 단어를 사용하세요 : 현실을 담아야.. 기술은 뒤편에 있어야지 무대로 나오면 안되죠 제품에 인성을 담으세요 : identity를 가져야.. 농구도 하고 육상도 하고 이러면 안되요

12. 사용자 가입 및 서비스요금 무료로 무언가를 제공하십시오 : 무료안좋아할 사람 없지요 가입과 해지과정을 고통없이 만드십시오 : 갈때까지 배웅해주는게 미덕이죠? 나쁜소식은 미리 공지하여 충격을 완화시키세요 : 정직은 어디서나 최우선

13. 홍보 티저광고에서 미리보기 그리고 런칭 : 조금씩 흥미를 끌면서.. 블로깅은 광고보다 더 효과적입니다 : 정말입니다 미리 붐을 조성하고 서비스 가입을 받으세요 : 그냥 오라하면 안오겠죠? 지식을 세상과 공유하세요 : 공유하는 미덕 사용자들은 새로운 기능에 굶주려 있습니다 : 당연하겠죠? 로그를 분석해서 동향을 파악하세요 : 고객을 알아야겠죠? 기억하기 쉬운 이름을 정하세요 : 동사형, 합성어가 좋고, 해설적인것은 별로

14. 지원 지원부서와 개발부서의 벽을 허무세요 : 벽은 허물수록 도움이 되죠 별도로 매뉴얼이나 교육이 필요없도록 문맥내에서 도움말과 FAQ를 제공하세요 : 이런건 없는게 최선 지원요청에서는 빠른 응답 시간이 매우 중요합니다 : 정직과 정성이죠 사용자에게 기꺼이 "No"라고 말할 수 있어야 합니다 : 고객이 항상 옳지는 않습니다 포럼이나 채팅을 사용해서 사용자들이 서로를 도울 수 있도록 하세요 : 소통의 장을 만들어주어야 나쁜소식은 빨리 알리세요 : 정직. 항상 최우선해야할 가치

15. 서비스 개시 이후 서비스 개시 한달 후에 주요 업데이트를 하세요 : 계속 진행중이라는 인상을 주세요 서비스 개시후에 지속적인 블로깅을 통해 서비스 개발이 진행중임을 보여주세요 : 이것도 역시 '베타'를 희생양으로 사용하지 마세요 : 베타를 오래지속하지 마세요. 완벽한것은 없죠 버그들의 우선순위를 정하세요 : 중요한것순으로 고치세요 경쟁자들의 RSS를 구독하세요 : 적을 알아야.. 더 완전해지는 것이 반드시 더 복잡해지는 것을 의미하지는 않습니다 : 항상 방향성을 유지하는 게 중요 방향 변화에 개방적인 자세를 가지세요 : 세상이 어떻게 변할지는 아무도 모르는 법

16. 결론 성공은 모두 위대한 '실행'에서 비롯됩니다 사람이 가장 중요합니다.