�ݺ�ߣ

Editor's Notes

• #2: 안녕하세요 이번 발표할 사람들 입니다. 사실 너무 많이 우려먹은 주제고, 이거 가지고 발표��기엔 양도 적다고 하셔서 저희가 팀프로젝트 진행하면서 했던것들 위주로 팀프로젝트 잘하는 방법에 대해 소개해보려고 합니다. 1,2학년 대상으로 하는것이라서 앞으로 엄청난 팀프로젝트들이 기다리고 있으니 이걸 보고 조금이라도 도움이 됐으면 좋겠습니다.
• #3: 사실 우리가 잘하는 사람들을 따라 잡는건 힘들다. 개인적으로는 프로그래밍은 보고 경험하고 하는 것이 가장 좋은 공부 방법인데 이런 절대적인 시간을 따라 잡을 수가 없다. 그러니까 잘하는 사람들한테 모두 맡기라는게 아니라 버스기사 위주로 하되 보고 열심히 배우라는 뜻 그리고 버스 기사를 못 만나면 그냥 해야한다. 이 뒤에 애기들은 그냥 할 떄의 얘기다 우리의 갓 버스기사님을 만났다면 하라는대로해라 그리고 배워라 그게 싫으면 그냥 하자
• #4: 책에서나 소프트웨어공학 이런대서 배우는 마인드맵, 생선그림 그려놓고 가시치기 이런거 필요 없다 물론 하면 나중에 보고서 쓰고 할때 좋긴 하지만 귀찮으니까 그리고 그런거 할 정도면 알아서 다 잘 하니까 하지 말자 그냥 종이에 뭐라도 쓰자. 생각나는대로 아이디어를 작성한다. 되도록이면 실생활에 관련된 것으로 한다. 예를 들어 유명한 이야기인 버스 노선이 필요해서 버스 어플을 만든 고등학생을 생각해볼 수있다. 이런식으로 정말 필요하거나 생활에 관련된것으로 하는게 재미도 있고 뻥튀기 하는데도 좋다. 이러한 것들은 기본적으로 구현 가능성은 제외한다. 아 그리고 중요한건 모여서 5분, 10분 정도 이렇게 아이디어 배설해놓고 더 이상 생각 안나면 그 날은 끝내는게 중요합니다. 생각 안나는데 붙잡아 봤자 생각도 안나고 그냥 머어엉어어엉ㅇ하니 있다가 집에가서 결국 아 그 시간동안 뭐했지 라는 안타까움만 듭니다.
• #5: 우리가 한것들입니다. 사실 더 많았는데 2번정도 필터링해서 최종적으로 아이디어를 정��기전 7개의 아이디어를 선출했습니다. 앞서 설명했던것처럼 1번 5번은 지금 하래도 못하는 그런 아이디어 들이었고, 3번도 조금 허무맹랑한 이야기 였습니다. 결국 제목에서 보다시피 시각장애인을 위한 하얀 지팡이로 정했습니다.
• #6: 정한 아이디어를 기준으로 기능을 정의해야 하는것이 중요합니다. 이 기능의 퀄리티에 따라 사실 프로젝트의 흥망성쇠가 결정 됩니다. 기능을 정할 때는 먼저 이 주제를 내가 사용한다고 생각해봤을때의 시나리오를 먼저 작성합니다. 저희의 시나리오를 예를 들면 지팡이를 이용해서 길을 찾을 때 스마트 지팡이니까 네비게이션 역할을 가진 지팡이를 생각 해볼 수 있습니다. 이런식으로 자기의 아이디어, 주제를 가지고 장난을 처 보면서 여러가지 시나리오와 기능들을 생각해봅니다. 이때까지도 구현 가능성은 배제하고 되는대로 작성해 봅니다.
• #8: 아이디어를 발전시킬 때 쯔음 되면, 이제 중간보고서 작성 1,2주 전 쯤이 될 것입니다. 왜냐하면 우리는 내일 일은 오늘 하지 않고 오늘 일도 내일 ��기 때문이죠. 따라서 한것도 없는데 중간보고서를 써야하는 불상사가 발생합니다. 이때는 앞서 정한 기능들 중에서 구현 가능한 것들, 쉬운 것들, 핵심적인 기능들만 추린 다음에 한 것 중에 한 3,4개 정도만 보고서에 작성합니다. 쉽게 생각해서 거창하게 시작했다가 조금 구현하고 끝내는 것보다 적당하게 시작해서 하다 보니 좀 더 했다라고 끝내는게 더 깔끔하고 좋기 때문이죠 이 때부터 프로젝트가 엄청난 것을 한 것 처럼 ��기 위한 밑 작업이 들어가야 합니다. 예를 들어 중간 보고서에 3을 작성하고 5를 구현한 다음에 10을 발표 해야 합니다. 그러기 위해선 그 팀이 더 많이 개발 할 수 있어도 일단 최소한만 작성합니다. 이는 우리 팀은 이렇게 했다는 것이므로 다른 분들은 당연히 이렇게 하지 않는다는걸 알아주세요 모두가 이러는거 아닙니다. 또 이런다고해서 절대 대충하라는 뜻도 아닙니다. 대충하면 당연히 좋은 결과를 얻기 힘듭니다. 하지만 내가 노력한 것 이상을 얻고 싶을 때 사용하는 전략 입니다.
• #9: 아이디어를 발전시킬 때 쯔음 되면, 이제 중간보고서 작성 1,2주 전 쯤이 될 것입니다. 왜냐하면 우리는 내일 일은 오늘 하지 않고 오늘 일도 내일 ��기 때문이죠. 따라서 한것도 없는데 중간보고서를 써야하는 불상사가 발생합니다. 이때는 앞서 정한 기능들 중에서 구현 가능한 것들, 쉬운 것들, 핵심적인 기능들만 추린 다음에 한 것 중에 한 3,4개 정도만 보고서에 작성합니다. 쉽게 생각해서 거창하게 시작했다가 조금 구현하고 끝내는 것보다 적당하게 시작해서 하다 보니 좀 더 했다라고 끝내는게 더 깔끔하고 좋기 때문이죠 이 때부터 프로젝트가 엄청난 것을 한 것 처럼 ��기 위한 밑 작업이 들어가야 합니다. 예를 들어 중간 보고서에 3을 작성하고 5를 구현한 다음에 10을 발표 해야 합니다. 그러기 위해선 그 팀이 더 많이 개발 할 수 있어도 일단 최소한만 작성합니다. 이는 우리 팀은 이렇게 했다는 것이므로 다른 분들은 당연히 이렇게 하지 않는다는걸 알아주세요 모두가 이러는거 아닙니다. 또 이런다고해서 절대 대충하라는 뜻도 아닙니다. 대충하면 당연히 좋은 결과를 얻기 힘듭니다. 하지만 내가 노력한 것 이상을 얻고 싶을 때 사용하는 전략 입니다.
• #10: 사실 우리가 개발하려는 최소한의 기능, 기술들은 갓구글에 다 있습니다. 사실 학부수준에서 어떤 프로젝트를 하던 개발을 하다가 막히면 구글에 영어로 검색하면 다 나옵니다. 워낙 많은 양의 프로젝트가 진행되어있고 공개되어있기 때문에, 우리는 그 코드를 찾아서 필요한 부분이 어떻게 작동하는지, 어떻게 구현되어있는지 이해하고 그를 가져와서 조합하면 됩니다. 물론 조합할때 자르고 수정하고 잘 배치해야하는 경우는 있지만, 핵심 코드를 수정할 일은 거의 없습니다. 예를 들어 우리가 개발한 장애물 탐지의 경우에도, 초음파 센서 인식 코드 존재하고 진동모터에 진동주는 코드 존재합니다. 그거 두개 조합하면 초음파 센서를 인식해서, 일정 거리 이내로 들어왔을때 진동모터에 진동을 주면 됩니다. 조금 자세하게 얘기하면 초음파를 쏘고 리턴 받는 메커니즘은 이론적으로 엄청 어렵습니다. 하지만 우리는 그걸 당연히 이해해야하지만 직접 구현할 필요는 없는거죠. 있는데.. 정말 잘하는 몇몇 분들을 빼면 그걸 우리가 개발 한다고해서 있는 것보다 좋을리가 없습니다. 그래서 거리나 방향, 주기에 대해서 우리가 필요한대로 수정해서 적용해서 구현했습니다. 이렇기 때문에 남의 코드를 잘 보고 이해하는 것이 매우 중요합니다. 내가 처음부터 구현하려고하면 막막하지만, 남이 이렇게든, 저렇게든 구현한 것을 보면서 아! 이렇게 할 수 있네, 또 남이 해논거 보면 어 별거 아니네? 라는 생각이 들 정도로 간단하게 구현 할 수 있습니다. 이런식으로 앟ㅍ서 우리가 작성했던 것 보다 더 많이 해야겠다는 생각으로 하면 됩니다. 사실 작성한것만큼만 해도 무방하지만 이왕 하는거 조금 더 하면 더 많이 한것 처럼 보일 수 있기 떄문이죠