1. 분업
본인이 분업을 할 때는 내가 팀원들 실력에 맞게 일거리를 나누어줌.
이 때 중요한게 서로간의 커뮤니케이션에 들어가는 비용을 최소화할 수 있도록기능의 인풋, 아웃풋을 정해놓고함.
즉, 기능의 내부 구현은 알아서 짜되 인풋과 아웃풋은 정확히 하자는 것임.나중에 다시 맞추려면 그 비용이 커서 미리 맞추는 것.
2. 설계
설계는 프로젝트가 어떠냐에 따라 다르겠지만... 최소한 필요한게 무엇인지 파악하고 진행을 하면 됨.
예를 들어 본인은 이번에 비콘을 이용한 출석체크 앱을 진행하는중임.
이 때 최소한 필요한 것들을 나열해보면
1> 비콘 신호를 받을 수 있는 기능(안드 클라이언트)
2> 서버로 메세지 보내고 다시 받는 기능 (안드 클라이언트 & 자바 서버)
3> 서버에서 메세지 처리하고 디비에 반영 ( 자바 서버 & DB)
4> 안드 UI(안드 클라이언트)
저런 식으로 정해 놓고 각각의 시나리오를 짜고 하는거지
이때 중요한 점은 내부 구현을 너무 신경 쓰지 않는게 좋음. 대충 할 수 있다 없다 정도 수준에서만 파악하고 ㅇㅇ
설계 안하고 구현할 수도 있긴한데; 그러면 1에서 말한 커뮤니케이션 비용때문에 프로젝트 터지거나 가장 잘하는 애 한 명이 혼자하게됨
3. 깃허브
흠... 깃허브 쓰는 경우도 있고 안 쓰는 경우도 있는데.. 나는 주로 구글 드라이브 & 메일 교환을 이용함.
깃허브를 쓰려면 팀원 모두가 깃허브를 다룰 수 있어야 하는데 생각보다 그런 경우는 없더라고.
4. 결론
팀플 하면 개 암걸리는 경우도 있긴한데, 위의 설계, 분업이 척척 되면 생각보다 즐거움.
예를 들어, 예전에 독립영화를 소개하는 홈페이지를 파이썬(플라스크)을 이용해서 구현하는 프로젝트를 했었음.
그 때, 분업을 잘 해서 나는 검색 엔진에서 독립영화 정보 파싱한 다음에 그거를 디비에 넣을 수 있도록 메세지를 만들어 주는 역할을 했었음.
예를 들어 (영화 제목 | 영화 상영관 | 시간.. )처럼 만드는거.
이렇게 잘 해놓으니까 나머지 웹 프로그래밍하는 애들이 잘 하드라고. 나름 좋은 경험이었음.
(그런데 내가 파싱만하고 아무것도 안해서 나를 욕했을지도 ㅋ)
일단 끝.
모호하거나 추가할 거있으면 알려주셈 ㅋ
기네요
흠 저는 1번이 설계라 생각했는데 약간 다르네욤
무조건 깃은 다룰 줄 알아야됨 예외없음
예외 많던데 ㅋ
기네요
그런데 위의 내용이 꼭 소프트웨어공학,방법론에 의거한 거는 아니고; 그냥 경험삼아 쓴것임.
경험담이 경험적으로 더 도움이 되더군요
프로젝트 제안서 -> 요구사항 분석서 -> 프로젝트 설계서 순대로 진행하는데 이 부분까지 다 정확하게 하려니까 머리아푸다
제안서에서 목표를 정하고(난이도를 따지면 프로젝트 수준이 매우 낮으므로 할 수 있다와 없다만 결정)
요구사항 분석서에서 이 프로젝트를 하려면 어떤게 필요한지 파악하고
프로젝트 설계서에서 구체적인 기능을 나누고 인풋 아웃풋을 정하고 일거리 분배해서 진행하는듯 ㅇㅇ
재밌겠다... ㅁㄴㅇㄹ
역시 io가 젤 중요해!! 근데 요구사항이 막 괴물처럼 변하는 경우는 없나요? 학교 과제라서 좀 고정되어있나요
고정되어 있는 편임. 고객이 따로 존재하는 건 아니니까 요구사항 자체가 바뀌는 경우는 드뭄. 파악을 제대로 못하는 경우는 있어도
긍까 파악을 제대로 못해서... 엎어지죠 겜만들다 많이 겪어봤는데 막 진짜 미친놈처럼 변함
근데 그런 건 잘 안 하겠죠 아무래도
게임류는 잘 안하거나, 간단한거 하더라. 클릭커 같은 게임들 유저와의 상호작용이 좀 적은 애들? 그런애들 위주로하던데
이글 매우 공감