오늘 나눌 이야기
프로젝트에 대한 사실과 오해
프로젝트에 대한 경험 돌아보기 (~9:35)
이전에 프로젝트를 진행하며 나에게 생긴 통찰이나 교훈은 몇점인가요? 점수와 그 이유에 대해 돌아보는 시간을 가져볼게요.
1.
전혀 없었다
2.
별로 없었다
3.
애매하다
4.
크진 않더라도 있었다
5.
중요한 통찰이 확실히 있었다.
이름 | 프로젝트를 진행하며 나에게 생긴 통찰이나 교훈에 대해 점수를 매겨보고 그 이유를 함께 작성해보기 |
#점수
#이유 | |
#점수
#이유 | |
#점수
#이유 | |
#점수:
#이유: | |
#점수
#이유 |
프로젝트에서 가장 문제가 많이 발생하는 부분은 어디일까?
요구 사항 분석 화면 스케치 디자인 백엔드 개발 프론트엔드 개발 테스트바로 역할의 경계선
요구 사항 분석 화면 스케치 디자인 백엔드 개발 프론트엔드 개발 테스트편지지 봉투 접기의 요구 사항 - 100장의 봉투 접기
•
편지를 접는다
•
봉투에 넣는다
•
풀로 봉투를 봉인한다
•
주소를 적는다
•
도장을 찍는다
과연 어느 방법이 더 좋을까?
첫번째 방법•
모든 편지지를 접는다
•
모든 편지를 봉투에 넣는다
•
모든 봉투를 풀로 봉인한다
•
모든 봉투에 주소를 쓴다
•
모든 봉투에 도장을 찍는다
두번째 방법•
한 개의 편지지를 접는다
•
봉투에 넣는다
•
풀로 봉인한다
•
주소를 쓴다
•
도장을 찍는다
•
이 과정을 100번 반복한다
과연 그 이유는?
실험해보자 세분화, 분업화에 따른 비용이 증가하는 원인
•
다른 파트에 정보를 전달하기 위한 과정에서 커뮤니케이션 비용
•
다른 파트에서 정보가 넘어오기를 기다리면서 소용되는 비용
•
정보에 대한 잘못된 이해로 인한 엉뚱한 결과물이 발생하는 비용
•
다른 파트의 작업을 이어하고 있는데 요구사항이 변경되어 다시 처음부터 하는 비용
동작 가능한 가장 작은 버전으로 빠르게 배포해보는 경험
•
페어 프로그래밍
•
데일리 미팅
•
회고
프로젝트에 대한 오해와 사실
걱정되는 부분, 고민, 궁금한 점, 질문
바보 같은 질문일수록 더욱 환영합니다~!
•
프로젝트를 애자일하게 하는게 현업에서 잘 진행되시나요?
◦
애자일하게 하지 않으면 진행을 할 수가 없어요
◦
폭포수 모델과 비교하는 모델로 애자일을 보게 되잖아요
◦
결과물에 대해서 사용자가 반드시 좋아할 거다, 사용할거다, 완성된 모습이 불확실성이 적을 때 가능한 모델
◦
생존을 위해 더더욱 애자일하게 하지 않으면 프로젝트를 진행하기 어려움
◦
3D 치킨집,Solution기반의 요구사하이 변동이 거의 없고, 의뢰가 온 소프트웨어를 그대로 만들기 때문에 폭포수 모델로 진행하는게 가능했는지
•
애자일하게 시작하다가 폭포수로 점점 변한다는 k-애자일 방식이 나타난다는 현상이 있다고 농담처럼 들은게 있었습니다. ㅎㅎ
◦
초반에는 사용자들이 원하는지 모르기 때문에 애자일하게 진행하다가
◦
사용자들이 많이 사용해. 네이버 포털 웹 서비스, 카카오톡
▪
카카오 주로 메신저 기능만 이용하지만 … 들어가면 생각보다 정말 많은 기능과 서비스들이 또 있잖아요.
•
프로젝트 시작할때 제일 먼저 무엇을 하나요?
◦
일단은 사용자에게 어떤 가치를 전달할 것이냐, 사용자의 어떤 문제를 해결해줄 것이냐
◦
소프트웨어 본질은 ‘문제 해결’
◦
사람들이 전화로 배달 주문을 하는데 여기서 오는 불편함 이 문제를 어떻게 해결할 수 있을까
◦
SMS문자를 보내면서 겪는 문제들을 어떻게 해결할 수 있을까
◦
그 문제를 해결하기 위한 가장 작은 모델을 만든다면 어떤 모습일까?
•
학습 목적의 프로젝트를
◦
사용자가 있으면 훨씬 더 의미있는 학습과 소프트웨어 엔지니어로서의 성장 경험을 많이 만들 수 있음
◦
‘나’라는 사용자
◦
‘타인’이라는 사용자
◦
‘타인들’이라는 사용자 (소그룹, 대그룹)
최종 프로젝트 기간동안 성장을 위해 강사님이 추천하는 시도해봤으면 하는 것들이 있을까요 ?
•
사용자를 두는거, 나, 우리 팀원들
◦
사용자가 없으면 기술 덩어리를 만들게 되지, 서비스를 만드는게 아니게 되기 때문에
◦
회원가입 기능, 로그인 기능, 메인 페이지 기능, 게시판 기능
◦
회원가입이나 로그인 mock 로그인으로 진행하고, 메인 페이지의 OO 기능이 어떤 플로우로 동작하는지 보여줘야겠다
•
페어 프로그래밍
•
중간 회고, 최종 회고
프론트엔드와 백엔드가 서로 어떤식으로 소통을 하나요?
•
우리가 해결해야 하는 문제가 있다 ⇒ 문제 정의는 다같이 확인을 하고요
◦
여기서 필요한 백엔드 작업, 프론트 작업 개발 회의에서 같이 이야기를 나눔
◦
프론트엔드 개발자끼리 협업, 백엔드 개발자끼리 협업, 서로간의 작업한 싱크를 맞추기 위해서 따로 회의를 잡거나, 개발 회의시간때 진행 과정 자체를 많이 공유를 해요
◦
잘 되고 있는 것도 공유를 하는게 필요하더라고요
강사님이 일을하며 가장 어려운 점은 어떤 것인가요?
개발, 교육
개발을 하면서의 어려운 점 - 개발을 했는데, 사용자가 쓰지 않을 때
프로젝트마다 다르겠지만 보통 기획 시간을 얼만큼 가지는게 좋을까요?
기획을 한다 | 개발을 한다
하나로 생각해주시면 더 좋을것 같음
우리가 만들려는 서비스는 무슨 문제를 해결하기 위한 것인가
이 문제를 해결하기 위해 동작 가능한 가장 작은 버전은 무엇일까
1차로 기획하고 개발하고 사용해보고 피드백 받고
2차로 기획하고 개발하고 사용해보고 피드백 받고
우리가 무슨 문제를 해결하려고 하는 것인지
회의실 관리 애플리케이션
시각적으로 보여주면 더 좋잖아요
개발로 바로 들어가려면 어려우니깐
스프레드시트로 먼저 만듦
최소한의 기획인데 가장 핵심적인 기능을 먼저 구현해보고 피드백 받고
확장해나가면서 또 기획하고, 구현하고 피드백 받고
프로젝트 진행중에 방향성의 선택의 순간에 합의가 잘 안될 때 어떤식으로 진행해보는게 좋을까요 ?
•
가치 판단
•
스타일의 차이에 따른 판단
•
팀마다 이런 순간에 우리가 어떤 식으로 선택을 하면 좋을지에 대한 합의를 보는게 필요
◦
1시간 동안 회의를 진행하고서 결정을 내리기 어려운 부분은 다수결로 결정하고 진행을 한다. 문제가 생기면 누군가를 탓하기 보다는 같이 그걸 해결한다
◦
팀 문화나 원칙으로써 만들어 나가는 거죠
◦
그래서 어떤걸 선택해야 사용자에게 더 좋을까?
◦
팀의 선택 결정권자를 매주 돌아가면서 하는거에요. 회의 MC를 매주 돌아가면서 진행하는데 결정이 안날 때는 MC가 정해주는 대로 가는거에요. 그리고 그 결정에 다같이 따르기.
개발을 하면서 겪은 트러블 슈팅을 어떻게 기록하는게 좋을까욥
•
개인적인 차원
◦
트러블 슈팅, 나만의 실수 데이터 베이스를 만듦
◦
1번 겪으면 그거에 대한 키워드 정도만 먼저 노션에 적음
◦
같은 이슈, 같은 트러블 슈팅 +1 겪게 되면 그때는 그 과정 어떻게 문제 해결했는지를 적었어요
•
팀 차원
◦
같이 트러블 슈팅을 공유할 수 있는 노션 페이지든, 위키 페이지든 같이 하나 관리하는게 좋거든요.
◦
페어 프로그래밍, 페어로 같이 하는데 우리 둘다 같이 문제 해결하는데 시간이 오래걸린거야. 그러면 그걸 같이 위키나 노션 페이지에 함꼐 문제를 해결하고 나서 직후에 회고하면서 기억이 생생할 때 적어 놓는식으로
아까 그 최소한의 기획 구현 피드백 이 과정에 평균 어느정도 시간을 가져가야할지 궁금합니다.
하루만에 하는경우도 있는데, 1주일을 넘기지 않는 형태.
2주가 넘어가면 텀이 너무 길어지는 경우가 많음
동기부여를 지속적으로 가져 갈 수 있는 방법은 무엇이 있을까요?
써먹을 맥락을 만드는 거
파워포인트를 공부하려고 하면 지치지만, 1주일 뒤에 내가 발표할 일이 있어서 파워포인트를 공부한다라고 하면 써먹을 맥락속에서 우선순위를 두고, 학습해나갈 수 있기 때문에 더 잘 할 수 있는 것처럼 써먹을 맥락을 고민해보기
자전거를 공부하려면
자전거를 타는 써먹을 맥락 자전거로 내가 한강을 달리고 싶은지, 산을 타고 싶은지
노션을 공부하려면
노션으로 우리 팀 회고록을 작성하려면 어떤 기능을 쓰면 좋을지
