Empfohlen
Weitere ähnliche Inhalte
Ähnlich wie 서비스를 성공적으로 만드는 방법
Ähnlich wie 서비스를 성공적으로 만드는 방법 (20)
Mehr von 우영 주
Mehr von 우영 주 (17)
Kürzlich hochgeladen
Kürzlich hochgeladen (8)
서비스를 성공적으로 만드는 방법
- 2. 제품을 올바르게 만드는 것과 올바른 제품을 만드는 것은 다른 문제다. 성공을 위해서는 둘 다 필요하다. 고코 아지치 영국 애자일 테스팅 사용자 그룹 “
- 3. 좋은 제품은 모든 기초 중의 기초다. 제품의 품질이 1이라면, 브랜드 마케팅은 그 뒤에 따라 붙는 0과 같다. 앞에 1이 없다면, 뒤에 아무리 많은 0이 붙어도 소용없다. 리완창 “ 샤오미 공동창립자
- 4. 기능적, 비기능적 요구사항을 올바르게 구현한 동작하는 소프트웨어 기능적 요구사항(functional requirement) 사용자가 직접적으로 이용하는 개별적인 기능에 대한 요구사항 비기능적 요구사항(non-functional requirement) 성능, 신뢰성, 가용성 등과 관련된 요구사항
- 5. 우리는 소프트웨어를 잘 만들고 운영하고 있을까?
- 6. 대부분의 프로젝트에서 겪고 있는 문제
- 7. 테스트 자동화, 자주 검증하는 시스템을 구축하기 힘들다. QA에 많은 책임이 몰리고, 오류가 잦다. 커뮤니테이션 미스가 많고, 변경이 잦다. 누구도 원하지 않는 기능을 개발할 때가 있다.
- 8. 문제의 진짜 원인을 짚어보자
- 9. 눈에 보이는 기능이 완성을 의미하지 않는다. 당장 코드 한 줄을 더 빨리 작성하고 그게 무엇이 됐든 동작하는 기능을 빨리 보길 바란다.
- 10. 역사상 가장 성공한 전투기 F-16 팰콘 1970년대 제트 전투기의 가장 중요한 요소는 속도 하지만 F-16을 성공을 이끈 것은 항속거리와 기동성
- 11. F-16의 초기 요구사항은 마하 2~2.5 F-16의 수석 설계자 해리 힐레이커는 그기능이왜필요한지물었다 미공군은 전투 회피 능력 때문이라 답했고 해리 힐레이커는 전투기의 민첩성을 높이는데 집중했다.
- 12. 문제를 이해하는 과정 구현에만 신경 쓰지 않고 문제 자체를 더 정확히 이해하는 과정 필요 F-16 사례를 통해 알 수 있는 것
- 13. 시스템이 어떤 일을 해야하는지 알기 위해서는 어떤 문제를 해결해야 하는지 알아야 한다 “ ”
- 14. 이것만 하면 될까?
- 15. 문제와 기능을 이해하는 과정에서 얻은 지식을 정리하는 방법도 필요
- 16. 변화가 자주 생기는 현대엔 부적합한 경우가 많다. 상세한 명세와 계획을 최신 상태로 유지하는데 비용이 큼
- 17. 유스케이스 하나 이상의 행위자(actor) 사이의 상호작용을 기술 분석된 시나리오는 구체적이고 범위가 넓다.
- 18. 최소한의 유지 비용으로 문서를 적절하고 신뢰할 수 있게 유지할수있는 방법 필요
- 19. 스토리와 함께하는 서비스 개발 문제 해결 아이디어
- 20. 사용자의 관점에서 사용자에게 가치를 줄 수 있는 기능을 서술한 것“ ” 사용자 스토리란?
- 21. 사용자가 내서재에서 삭제하고 싶은 작품을 선택한 후 숨기기 버튼을 클릭하면 시스템은 HTTP API를 통해 서버에 해당 작품을 삭제하도록 요청한다. 시스템 관점 HTTP API? 서버에 요청한다는 말은 또 뭐지?
- 22. 사용자는 삭제하고 싶은 작품을 1개 이상 선택할 수 있다. 사용자는 확인을 선택해 삭제 작업을 완료할 수 있다. 사용자 관점 아하! 사용자는 삭제하고 싶은 작품을 선택해 삭제할 수 있구나!
- 23. “ ” 「시스템이 어떻게 동작 하느냐」가 아닌 「사용자가 어떤 목적으로 시스템을 사용하느냐」라는 관점에서 사용자 요구사항을 정리
- 24. 내서재 개발 사례 아이디어 실천법
- 25. 내 서재의 작품을 삭제할 수 있게 해주세요!“ ”
- 26. 코딩은 잠시 멈추고 스토리를 분석해 봅시다. 해결해야 할 문제와 만들어야 할 기능을 이해하는 시간이 필요합니다.
- 27. 분석 회의는 누가 주도하나요?
- 28. 누구나 가능합니다~! 분석 회의는 누가 주도하나요?
- 29. 만약 모두가 리더인 조직이라면 스스로 하나의 조직 처럼 사고하고 행동해야 함 자기조직화(Self Organization)
- 30. 누가 언제 리딩해주지, 왜 아무말이 없을까?
- 31. 보스없는 조직에서 적응 못할 사람은 떠나라! 모두가 자기의 주장을 내세울 수 있고 누구든지 리더가 될 수 있으며 스스로가 일할 명분을 선택해야 한다. http://news.mk.co.kr/newsRead.php?year=2015&no=342351 기사에서 발췌
- 32. 스스로 일정을 결정하고 이해관계자를 찾고 사용자 스토리 분석을 주도한다.
- 33. 프로젝트 구성원은 한 배를 탄 루피 해적단 같은 팀, 누가 주도하든 적극적인 참여!
- 34. 또 질문! 누가 참석하나요?
- 35. 또 질문! 누가 참석하나요? 관계자라면 누구나 가능합니다~!
- 36. 아무리 검토 과정이 있더라도 혼자 명세를 작성하는 책임을 지는 것은 바람직하지 않다. “ ” 성격에 따라 CR, 비즈니스 담당자 등도 참석 이상적인 구성원은 4명 이상 (기획자, 디자이너, 개발자 그리고 QA)
- 37. 어쩌고저쩌고 이렇고저렇고
- 38. 어쩌고저쩌고 이렇고저렇고 나랑 상관 없는 이야기인데... 어쩌지?
- 39. 노노노~! 잠깐만요! 어쩌고저쩌고 이렇고저렇고 나랑 상관 없는 이야기인데... 어쩌지?
- 41. 문제를 창의적이고 효율적으로 해결하기 위해 함께 분석하고 평가해야 한다.
- 42. 이제 내서재 삭제 기능을 분석해봅시다.
- 43. 내서재에서 작품을 삭제할 수 있게 해주세요!
- 44. 그 기능이 왜 필요한 거에요? 내서재에서 작품을 삭제할 수 있게 해주세요!
- 45. 사람들이 서재에서 보고 싶지 않은 작품을 삭제하고 싶어 합니다. 그 기능이 왜 필요한 거에요? 내서재에서 작품을 삭제할 수 있게 해주세요!
- 46. 사람들이 서재에서 보고 싶지 않은 작품을 삭제하고 싶어 합니다. 그 기능이 왜 필요한 거에요? 내서재에서 작품을 삭제할 수 있게 해주세요! 그렇군요, 문제를 해결할 또 다른 방법이 떠오르진 않네요. 알겠습니다.
- 47. 문제를 공유하면 그렇군요, 문제를 해결할 또 다른 방법이 떠오르진 않네요. 알겠습니다. 사람들이 서재에서 보고 싶지 않은 작품을 삭제하고 싶어 합니다. 그 기능이 왜 필요한 거에요? 내서재에서 작품을 삭제할 수 있게 해주세요!
- 48. 사람들이 서재에서 보고 싶지 않은 작품을 삭제하고 싶어 합니다. 그 기능이 왜 필요한 거에요? 내서재에서 작품을 삭제할 수 있게 해주세요! 문제를 해결할 더 좋은 방법을 함께 고민해 볼 수 있어요. 그렇군요, 문제를 해결할 또 다른 방법이 떠오르진 않네요. 알겠습니다.
- 49. 스토리는 「주체 / 목적 / 행위」로 정리할께요.
- 50. 「사용자는 / 보고 싶지 않은 작품을 제거하기 위해 / 내서재를 삭제할 수 있다」 스토리는 「주체 / 목적 / 행위」로 정리할께요.
- 51. 잠깐만요. 내서재를 삭제한다는 말은 오해할 수 있겠어요. 내서재의 작품을 삭제할 수 있다가 어때요? 스토리는 「주체 / 목적 / 행위」로 정리할께요. 「사용자는 / 보고 싶지 않은 작품을 제거하기 위해 / 내서재를 삭제할 수 있다」
- 52. 「사용자는 / 보고 싶지 않은 작품을 제거하기 위해 / 내서재의 작품을 삭제할 수 있다」 잠깐만요. 내서재를 삭제한다는 말은 오해할 수 있겠어요. 내서재의 작품을 삭제할 수 있다가 어때요? 스토리는 「주체 / 목적 / 행위」로 정리할께요. 「사용자는 / 보고 싶지 않은 작품을 제거하기 위해 / 내서재를 삭제할 수 있다」
- 53. 「사용자는 / 보고 싶지 않은 작품을 제거하기 위해 / 내서재의 작품을 삭제할 수 있다」 잠깐만요. 내서재를 삭제한다는 말은 오해할 수 있겠어요. 내서재의 작품을 삭제할 수 있다가 어때요? 스토리는 「주체 / 목적 / 행위」로 정리할께요. 「사용자는 / 보고 싶지 않은 작품을 제거하기 위해 / 내서재를 삭제할 수 있다」 목적은 어떤 기능을 왜 제공해야하는지 행위의 목적성을 나타내요.
- 54. 오우! 정확히 짚어주셨네요! 음... 현재 내서재 페이지에서 삭제를 바로 제공하긴 힘들 것 같고 편집 모드로 전환해야 할 거 같아요. 어떤가요?
- 55. 오우! 정확히 짚어주셨네요! 음... 현재 내서재 페이지에서 삭제를 바로 제공하긴 힘들 것 같고 편집 모드로 전환해야 할 거 같아요. 어떤가요? 크게 상관없어요. 추후 다양한 편집 기능이 추가될 수도 있으니 그편이 좋은 거 같습니다.
- 56. 「사용자는 / 작품을 제거하기 위해 / 내서재에서 편집 버튼을 선택해 편집 모드로 전환할 수 있다」 크게 상관없어요. 추후 다양한 편집 기능이 추가될 수도 있으니 그편이 좋은 거 같습니다. 오우! 정확히 짚어주셨네요! 음... 현재 내서재 페이지에서 삭제를 바로 제공하긴 힘들 것 같고 편집 모드로 전환해야 할 거 같아요. 어떤가요?
- 57. 아직 단순한 버튼으로 할지, 라디오 버튼으로 할지 결정하지 않았어요. 지금 UI에 관한 요소가 결정 돼야 하나요?
- 58. 앗! 제가 너무 구체적인 내용까지 서술했네요. UI에 관한 부분은 추후 다시 논의하는 게 맞는 거 같네요. 아직 단순한 버튼으로 할지, 라디오 버튼으로 할지 결정하지 않았어요. 지금 UI에 관한 요소가 결정 돼야 하나요?
- 59. 「사용자는 / 작품을 제거하기 위해 / 내서재에서 편집 모드로 전환할 수 있다」 앗! 제가 너무 구체적인 내용까지 서술했네요. UI에 관한 부분은 추후 다시 논의하는 게 맞는 거 같네요. 아직 단순한 버튼으로 할지, 라디오 버튼으로 할지 결정하지 않았어요. 지금 UI에 관한 요소가 결정 돼야 하나요?
- 60. 앗! 제가 너무 구체적인 내용까지 서술했네요. UI에 관한 부분은 추후 다시 논의하는 게 맞는 거 같네요. 「사용자는 / 작품을 제거하기 위해 / 내서재에서 편집 모드로 전환할 수 있다」 전문 용어(예: 개발 용어)나 구체적인 UI 구현 고민 없이 짧고 간결하게 스토리 작성 아직 단순한 버튼으로 할지, 라디오 버튼으로 할지 결정하지 않았어요. 지금 UI에 관한 요소가 결정 돼야 하나요?
- 61. 혹시 삭제 시 작품을 여러 개 선택하여 일괄 삭제 할 필요가 있을까요?
- 62. 혹시 삭제 시 작품을 여러 개 선택하여 일괄 삭제 할 필요가 있을까요? 많은 작품을 가지고 있는 기존 사용자는 여러 작품을 한 번에 삭제하고싶어 할 거 같네요!
- 63. 「사용자는 / 1개 이상의 작품을 제거하기 위해 / 삭제하고 싶은 작품을 여러 개 선택할 수 있다」 많은 작품을 가지고 있는 기존 사용자는 여러 작품을 한 번에 삭제하고싶어 할 거 같네요! 혹시 삭제 시 작품을 여러 개 선택하여 일괄 삭제 할 필요가 있을까요?
- 64. 자, 사용자가 내서재의 작품을 삭제하기 위해 편집 모드로 전환하고, 삭제하고 싶은 작품을 여러 개 선택했습니다. 그다음은 어떻게 이뤄지는 게 좋을까요?
- 65. 자, 사용자가 내서재의 작품을 삭제하기 위해 편집 모드로 전환하고, 삭제하고 싶은 작품을 여러 개 선택했습니다. 그다음은 어떻게 이뤄지는 게 좋을까요? 음... 확인 버튼을 두고 그 버튼을 선택하면 최종적으로 삭제할 수 있도록 하죠?
- 66. 「사용자는 / 선택한 작품을 제거하기 위해 / 확인 버튼을 선택해 삭제 작업을 완료할 수 있다」 음... 확인 버튼을 두고 그 버튼을 선택하면 최종적으로 삭제할 수 있도록 하죠? 자, 사용자가 내서재의 작품을 삭제하기 위해 편집 모드로 전환하고, 삭제하고 싶은 작품을 여러 개 선택했습니다. 그다음은 어떻게 이뤄지는 게 좋을까요?
- 67. 음... 확인 버튼을 두고 그 버튼을 선택하면 최종적으로 삭제할 수 있도록 하죠? 자, 사용자가 내서재의 작품을 삭제하기 위해 편집 모드로 전환하고, 삭제하고 싶은 작품을 여러 개 선택했습니다. 그다음은 어떻게 이뤄지는 게 좋을까요? 이 말 속에는 어떠한 기술 용어도, 구체적인 UI 상태도 담고 있지 않아요. 「사용자는 / 선택한 작품을 제거하기 위해 / 확인 버튼을 선택해 삭제 작업을 완료할 수 있다」
- 68. 음... 확인 버튼을 두고 그 버튼을 선택하면 최종적으로 삭제할 수 있도록 하죠? 자, 사용자가 내서재의 작품을 삭제하기 위해 편집 모드로 전환하고, 삭제하고 싶은 작품을 여러 개 선택했습니다. 그다음은 어떻게 이뤄지는 게 좋을까요? 관례적, 패턴적으로 나타나는 UI 요소는 스토리에 담아도 큰 문제 없어요. 「사용자는 / 선택한 작품을 제거하기 위해 / 확인 버튼을 선택해 삭제 작업을 완료할 수 있다」
- 69. 음, 사용자가 실수로 삭제할 수도 있지 않을까요?
- 70. 음, 사용자가 실수로 삭제할 수도 있지 않을까요? 아! 그렇네요. 삭제 전에 확인받는 절차를 둬야 할 거 같습니다.
- 71. 「사용자는 / 잘못된 삭제를 피하기 위해 / 작품이 삭제 되기 전 확인 받을 수 있다」 아! 그렇네요. 삭제 전에 확인받는 절차를 둬야 할 거 같습니다. 음, 사용자가 실수로 삭제할 수도 있지 않을까요?
- 72. 「사용자는 / 잘못된 삭제를 피하기 위해 / 작품이 삭제 되기 전 확인 받을 수 있다」 음, 사용자가 실수로 삭제할 수도 있지 않을까요? 아! 그렇네요. 삭제 전에 확인받는 절차를 둬야 할 거 같습니다. 시스템 관점이 아닌 사용자 관점에서 요구사항을 분석하면 누락할 수 있는 중요한 행위를 쉽게 발견할 수 있어요.
- 73. 오늘은 여기까지 하시죠? 수고하셨습니다. 감사합니다.
- 74. 사용자는 / 보고 싶지 않은 작품을 제거하기 위해 / 내서재의 작품을 삭제할 수 있다. • 사용자는 / 작품을 제거하기 위해 / 내서재에서 편집 모드로 전환할 수 있다. • 사용자는 / 1개 이상의 작품을 제거하기 위해 / 삭제하고 싶은 작품을 여러개 선택할 수 있다. • 사용자는 / 선택한 작품을 제거하기 위해 / 확인 버튼을 선택해 삭제 작업을 완료할 수 있다. • 사용자는 / 잘못된 삭제를 피하기 위해 / 작품이 삭제 되기 전 확인 받을 수 있다.
- 75. 개발자는 여기에서 많은 정보를 얻을 수 있습니다.
- 76. 사용자는 / 보고 싶지 않은 작품을 삭제하기 위해 / 내서재의 작품을 삭제할 수 있다. • 사용자는 / 작품을 삭제하기 위해 / 내서재에서 편집 모드로 전환할 수 있다. • 사용자는 / 1개 이상의 작품을 삭제하기 위해 / 삭제하고 싶은 작품을 여러개 선택할 수 있다. • 사용자는 / 선택한 작품을 삭제하기 위해 / 확인 버튼을 선택해 삭제 작업을 완료할 수 있다. • 사용자는 / 잘못된 삭제를 피하기 위해 / 작품이 삭제 되기 전 확인 받을 수 있다.내서재의 작품 삭제를 요청하기 위한 API가 필요하네요.
- 77. 사용자는 / 보고 싶지 않은 작품을 삭제하기 위해 / 내서재의 작품을 삭제할 수 있다. • 사용자는 / 작품을 삭제하기 위해 / 내서재에서 편집 모드로 전환할 수 있다. • 사용자는 / 1개 이상의 작품을 삭제하기 위해 / 삭제하고 싶은 작품을 여러개 선택할 수 있다. • 사용자는 / 선택한 작품을 삭제하기 위해 / 확인 버튼을 선택해 삭제 작업을 완료할 수 있다. • 사용자는 / 잘못된 삭제를 피하기 위해 / 작품이 삭제 되기 전 확인 받을 수 있다. 그 API는 복수의 작품을 삭제할 수 있도록 디자인돼야 하는군요.
- 78. 디자인이나 마크업이 나오기 전에 API를 디자인하고 비즈니스 로직을 구현할 수 있습니다.
- 79. 스토리 분석 스토리 분석 스토리 분석 스토리 분석 스토리 분석 기획자 디자이너 백엔드 프론트엔드 마크업 API 디자인 API 디자인 모델 구현 디자인 마크업 개발 UI 개발 API 및 비즈니스 로직 구현 개발 시작 지점 스토리를 기반으로 병렬로 구현을 진행하여 개발 기간을 단축 시킬 수 있어요.
- 80. 스토리가 있으면 테스트와 TDD가 가능하며 결과적으로 테스트 자동화도 가능합니다.
- 81. 기능, “내서재의 작품 삭제 기능” 스토리, “사용자는 / 1개 이상의 작품을 제거하기 위해 / 삭제하고 싶은 작품을 여러개 선택할 수 있다.” • Given : 사용자가 내서재 페이지에 방문한다. • And : 사용자가 내서재 페이지에서 편집 모드로 전환한다. • When : 사용자가 삭제하고 싶은 작품을 선택한다. • Then : 삭제 대상이 되는 작품이 선택된다. 스토리, ...
- 82. 감사합니다.