Successfully reported this slideshow.
Your SlideShare is downloading. ×

테크스펙으로 모두가 함께 성장하기.pdf

Ad
Ad
Ad
Ad
Ad
Ad
Ad
Ad
Ad
Ad
Ad
Loading in …3
×

Check these out next

1 of 34 Ad
Advertisement

More Related Content

Recently uploaded (20)

Advertisement

테크스펙으로 모두가 함께 성장하기.pdf

  1. 1. 류성두 테크스펙으로 모두가 함께 성장하기 뱅크샐러드
  2. 2. 목차 • TechSpec으로 • 모두가 함께 • 성장하기
  3. 3. 테크스펙으로
  4. 4. 테크스펙이란
  5. 5. 스펙이란
  6. 6. 스펙과 테크스펙 - 자산 화면에서 편집버튼을 누르면 편집화면이 나옵니다. (스펙) - AssetsViewController는 editButton에 touchUpInside 입력을 받으면 EditViewController의 push 이벤트를 출력합니다. (테크스펙) - 은행계좌 셀에는 금융사 로고, 상품이름, 잔액을 표시합니다 (스펙) - BankAccountCell 로 UserBankAccount 모델의 다음 속성을 표시합니다. - organization.logoURL - accountDisplayName - balance.displayText
  7. 7. 왜?
  8. 8. 모든 스펙은 "생각보다" 복잡하다 - 은행계좌 셀에는 금융사 로고, 상품이름, 잔액을 표시합니다 (스펙) - 은행 계좌의 정보는 어디서 가져오고 어떤 모델로 정의되어 있지? 새로 정의해야 하나? - 이미 있나? 이미 있는 UserBankAccount를 쓰면 되는건가? - 금융사 로고: circle버전? small버전? large버전? - 상품이름: 원본 상품? 닉네임? 닉네임이 없을 때는? 이름이 길 때는? - 잔액: 평가금? 원금? 출금가능금액? 소수점은?
  9. 9. 스펙만 보고 일정산정을 하면 - "로고랑, 상품명이랑, 잔액만 보여줘"란 스펙만 듣고 일정산정을 하면 - 무리한 일정을 말하게 되고 - 야근을 하고 - 버그를 만들고 - 버그 때문에 야근을 하고 - 일정이 밀리고 - 번아웃에 빠지고
  10. 10. 기획서에 구멍이 있다? • 기획서에 모든 경우의 수가 담기지 않는 것은 당연하다 • 기획서에 구멍이 없다면, 충분히 복잡하지 않은 제품을 만드는 것이다 • 충분히 복잡한 문제를 해결해 줘야 의미있는 IT 제품이다 • 완벽한 기획서 만들려다가 세월 다 간다 • 기획자는 제품을 기획하고, 완성은 모두가 함께 한다
  11. 11. 테크스펙의 목차 - 배경 - 목표 - 목표가 아닌 것 - 설계 - 보안 - 테스트 계획 - 일정
  12. 12. Agile선언은?
  13. 13. 모두가 함께
  14. 14. 테크스펙 = 문서로 하는 코딩 • 문서로 코딩을 하면, 모두가 참여 할 수 있다 • 맥북을 쓸 필요도 • Xcode를 설치할 필요도 • 빌드 환경 구성을 위해 특정 버전의 루비를 설치할 필요도 없다
  15. 15. 테크스펙을 작성하고 나면 • 창의력이 필요한 문제는 함께 해결 한 상태 • 특히 변수명,인터페이스 • 이 때서야 비로소 확실한 "릴리즈 일정"을 약속 할 수 있다. • 그렇다고 수정이 안 생기는 것은 아니다
  16. 16. "비록 개발의 후반부일지라도, 
 요구사항 변경을 환영하라"
  17. 17. 개발 중 스펙 변경 • 모두가 인지해야 • 개발자는 구현하고 • QA는 테스트케이스를 업데이트하고 • 디자이너는 시안을 업데이트하고 • 데이터분석가는 가설을 다시 세우고 • 이 문제를 해결하는 것이 Git등의 버전관리 • 한글,구글 오피스,피그마에도 버전관리 기능들이 있다
  18. 18. 개발 중 스펙 변경 • 모두가 인지해야 • 개발자는 구현하고 • QA는 테스트케이스를 업데이트하고 • 디자이너는 시안을 업데이트하고 • 데이터분석가는 가설을 다시 세우고 • 이 문제를 해결하는 것이 Git등의 버전관리 • 한글,구글 오피스,피그마에도 버전관리 기능들이 있다
  19. 19. 개발 중 스펙 변경 • 모두가 인지해야 • 개발자는 구현하고 • QA는 테스트케이스를 업데이트하고 • 디자이너는 시안을 업데이트하고 • 데이터분석가는 가설을 다시 세우고 • 이 문제를 해결하는 것이 Git등의 버전관리 • 한글,구글 오피스,피그마에도 버전관리 기능들이 있다
  20. 20. 자라기
  21. 21. 토마스 홉스 “개인의 능력은 다 
 고만고만하다”
  22. 22. 성장∝피드백 • 얼마나 • 더 이른 시점에 • 더 자주 • 더 많은 사람들로부터 • 더 다양한 관점을 가진 사람들로부터 • 피드백을 받을 수 있는가의 문제
  23. 23. 정리 - 문서를 통해 받을 수 있는 피드백이 많다 - 변수명, 인터페이스, 컨벤션 - 테스트코드 - 문서를 통해 변경 사항을 잘 관리 할 수 있다 - 문서도 git 처럼 관리 할 수 있다 - 문서를 통해 지식이 전파 될 수 있다

×