두 번째 수업의 학습 목표는 프로젝트에서 사용할 개발 프로세스를 정하는 것이었다. 다른 목표도 있지만 개발 프로세스를 결정하는 것이 가장 컸다. 개발 프로세스를 이해하려면 소프트웨어 개발에 대한 다양한 관점을 이해할 필요가 있었기 때문에 지난 시간에 과제로 소프트웨어 크리에이티비티 2.0의 일부 내용을 읽고 리포트를 제출하도록 했다.
소프트웨어 크리에이티비티 2.0 책을 선정한 이유는 소프트웨어 개발에 대한 다양한 관점을 중립적인 관점에서 다루고 있기 때문이다. 학생들이 소프트웨어 개발을 한가지 관점으로만 바라보지 않고 다양한 시각들을 이해했으면 하는 바람 때문이다. 이 책의 주제 중 "규율 대 유연성", "정형 기법 대 경험 기법" 내용을 읽고 토론하는 시간을 가졌다. 이 내용 이외에도 다른 내용들이 많으니 시간을 가지고 반드시 읽어 봤으면 좋겠다.
아직 사회 경험이 많지 않음, 소프트웨어 개발 경험이 많지 않음, 젊음 등의 이유로 한 가지 방향으로 치우칠 것이라 생각했는데 예상보다는 쏠림 현상이 심하지는 않았다. 특히 소프트웨어 개발 프로세스 자체를 거부할 수도 있을텐데 팀 협업을 하려면 프로젝트를 진행할 때의 기본적인 프로세스는 필요하다는 것에 모두들 공감했다.
토론 중에 나온 이야기를 취합해 보면 다음과 같다.
- 소프트웨어 개발은 창의적인 활동이라 생각한다.
- 소프트웨어 개발의 모든 활동이 창의적인 활동은 아니다.
- 설계는 지극히 창의적인 활동이다. 설계를 해나가는 과정은 창의적인 활동이 맞다. 하지만 이 설계 작업을 문서화하는 작업은 창의적인 활동은 아니다.
- 설계가 끝나고 구현 과정은 창의적인 활동이 아니지 않느냐? 아니다. 구현 과정에서도 어떤 메소드(함수)에 구현할 것인지, 어느 클래스에 구현하는지를 고민해야 하기 때문에 창의적인 활동이다. 그런데 그 메소드와 클래스를 고민하는 그 과정 자체는 설계 과정이지 않느냐? 그렇다면 구현과 설계를 구분할 수 있느냐?
- 설계와 구현을 명확하게 분리한다면 구현을 담당하는 프로그래머는 설계자의 문서를 이해하고 파악한 구현을 해야하는데 여기서 낭비가 발생하지 않느냐?
- 우리가 진행하는 프로젝트에는 애자일 프로세스가 적합하다는 생각이 든다. 그런데 애자일 프로세스는 문서화를 중요하지 않게 생각하는 듯하다. 애자일 프로세스 + 문서화에 집중하는 방식으로 진행하면 좋겠다.
- Waterfall과 애자일의 차이점이 뭐라고 생각하느냐?
위와 같은 논의들이 오고 갔다. 토론하는 과정을 통해 그 동안 자신들이 잘못 이해하고 있던 부분도 이야기 나눌 수 있었으면 자연스럽게 다음에 해결해야할 이슈도 나왔다.
다음으로 논의할 주제는 소프트웨어 개발에서 문서화에 대한 부분이다.
한 친구가 이야기했다. 애자일 프로세스는 문서 보다는 소스 코드에 집중하는 것으로 알고 있다. 하지만 본인은 문서화도 중요하다고 생각한다. 이 같은 이야기가 나오면서 자연스럽게 문서화를 어느 정도 수준으로 하는 것이 좋을지와 이를 위한 도구로 어느 것이 유용할 것인지에 대해 다음 시간에 결정하기로 했다. 오늘 토론을 통해서 경험 기법이 항상 맞는 것은 아니며, 어떤 상황에서는 정형 기법이 맞다는 것을 느꼈으면 한다. 또한 유연성이 정말 좋은 상황도 있지만 어떤 상황에서는 규율이 필요한 경우도 있다는 것을 느꼈으면 좋겠다.
이 같은 논의를 통해 이번 프로젝트는 애자일 프로세스를 진행하기로 결정했다. 애자일 프로세스 중 스크럼을 활용해 프로세스를 최소화하고 프로젝트를 진행하면서 부족한 부분이 있으면 하나씩 추가해 나가기로 결정했다.
수업 중에 모든 내용을 결정할 수 없기 때문에 수업 없을 때는 trello를 통해 소통하고 있다. 그 사이 온라인 상 논의를 통해 프로젝트명은 humhum으로 진행하기로 결정했다. humhum 프로젝트에 대한 핵심 가치를 공유한 후에 이 핵심 가치에서 우리가 가정하고 있는 부분인지를 논의하고 이를 어떻게 검증해 나갈 것인지에 대해 다음 시간에 논의해 보기로 했다. 핵심 가치가 맞는 것인지를 검증하는 부분은 린 스타트업 책을 참고했으면 좋겠다. 나 또한 이와 관련한 경험이 많지 않기 때문에 이번에 학생들과 실험을 통해 이와 관련한 경험을 쌓았으면 좋겠다.
현재 진행하는 SW 공학 수업은 SW 공학에 대한 이론적인 내용보다는 프로젝트를 진행하면서 SW 공학에 대한 경험을 몸으로 느껴보는 것을 더 중요하게 생각하고 있다. 따라서 이슈가 되는 주제들을 수업 시간에 하나씩 결정해 나가려고 한다. 오늘 수업 중에도 나왔지만 자연스럽게 문서화에 대한 이슈가 등장하면 이와 관련한 자신들의 생각을 정리해서 다음 시간에 논의를 통해 방법을 찾아나가는 접근 방법을 취하려고 한다.
이렇게 이론적인 부분과 프로젝트를 병행하다보니 수업 시간에 모든 부분을 소화할 수 없어 기술적인 부분은 자발적으로 학습한 후에 일주일에 한시간씩 모여서 스터디를 하는 방식으로 결정했다. 프로젝트를 Ruby On Rails로 진행하기로 결정했고 스터디할 책도 결정했다. 모두들 애인도 없고, 주말에 할 일도 없다면서 한 번에 많이 나가도 된단다. 나는 가정도 있고, 주말에 할 일도 많은데... 그래도 학생들 주도로 하고 나는 옆에서 코칭하는 역할이니 따르기로 결정했다.
한 주 밖에 되지 않았는데 정말 많은 결정과 작업들을 했다. 한 번에 모든 일을 한 것이 아니라 작업들을 쪼개 시간 나는 틈틈이 진행했기 때문에 이 같은 작업을 했다고 생각한다. 이 수업을 통해 자신들의 작업을 작게 관리하고 해결해 나가는 습관도 익혔으면 좋겠다.
수업이 끝난 후 자리로 돌아와 trello를 정리하다보니 자신들이 다음 주까지 해야할 일들을 수업 중에 trello에 올려 놓은 모습을 보면서 기특하다는 생각이 들었다. 앞으로도 이런 마음 가짐으로 한 학기를 마무리할 수 있으면 좋겠다.