[우테코] 레벨3 전반적인 회고
레벨3의 시작은 프로그래밍과 소프트웨어 엔지니어링의 차이를 말하면서 시작되었다.
프로그래밍 vs 소프트웨어 엔지니어링
프로그래밍
프로그래밍은 코드를 작성하는 작업을 뜻한다.
물론 몹 프로그래밍, 페어 프로그래밍을 사용하여 여럿이서 프로그래밍을 할 수 있지만 주로 혼자서 코드를 작성한다.
소프트웨어 엔지니어링
소프트웨어 엔지니어링은 설계, 프로그래밍, 유지 보수 등 요구 사항을 충족하는 하나의 소프트웨어를 여러인원이 같이 만드는 프로세스 그 자체를 뜻한다.
레벨 3동안 우리 팀원들과 같이 고민하고 진행한 모든 것들은 결국 더 좋은 소프트웨어 엔지니어링을 위한 고민들이었던 것이다.
- 어떤 방식으로 팀원들간의 좋은 관계를 유지해야 할까?
- 어떤 방식으로 팀원들이 일적으로 협업해야 할까?
- 어떤 도구를 사용해야 더 좋은 소프트웨어를 만들 수 있을까?
- 어떤 방식으로 코드를 작성해야 유지보수를 원할히 할 수 있을까?
- 어떤 방식으로 코드를 작성해야 팀원들이 빨리 파악할 수 있을까?
- 어떤 방식을 사용하여 사용자의 요구 사항에 충족할 수 있을까?
- ….
그 다음은 팀에 대해서 말하는 내용이였다.
팀
팀의 모습
팀들은 여러 모습과 여러 색깔을 가질 수 있다.
솔직히 처음에는 이상적인 팀의 모습에 대해 고민하고 그런 모습에 점점더 가까워지고 유사해지는 방법이 좋은 팀이 되는 좋은 방법이라고 생각했다.
하지만 레벨 3동안 여러 다른 팀들을 오고가며 보았을 때 정말 여러 색깔의 팀들을 보았다. 또한 우리 팀에서 팀만의 색을 가져가는 과정에서도 느낀 것 들이 참 많았다.
개인적으로 우리 팀에서 느낀 좋은 팀의 모습은 아래와 같다.
- 좋은 팀은 구성원이 생각하는 소프웨어의 방향성이 일치하며 이를 위한 대화를 피하지 않는다.
- 좋은 팀은 구성원들끼리 서로를 파악하고 이해해가며 유동적인 독자적인 색을 가진다.
- 좋은 팀은 할일을 나누는 것보다 같이 해야할 일을 찾는 과정에 집중한다.
우테코 프로젝트 팀
우테코 프로젝트에서는 PM 이 따로 존재하지 않기에 결국 모두가 같이 만들고 같이 책임지는 형태의 팀이였다.
우리 프로젝트의 처음은 레벨3 이전에 코치들에게 채택된 나의 아이디어였다.
하지만 지금 만들어진 S-HOOK 서비스는 내 아이디어가 아닌 우리 팀의 아이디어로 만들어진 서비스이고 이를 적는 내내 단 1초도 의구심이 들지 않았다.
참 좋은 팀원들과 좋은 과정을 겪었다는 것을 다시 한번 느낀다.
그라운드 룰
팀마다 각 팀에 맞는 그라운드 룰을 가지고 있다.
쉽게 말해 팀에서 지키고자 하는 규칙들이다.
내가 그라운드 룰에서 가장 인상깊었던 부분은 이 룰의 유래였다.
유래
야구 경기에서 MLB가 정한 기본 규칙에 모순되지 않는 한 개별 야구경기장마다 추가 규칙을 설정하는 것
즉 좋은 소프트웨어 엔지니어링을 위한 가치를 추구한다는 기본 규칙만 존재할 뿐이지 다른 추가 규칙들을 팀원들끼리 정하는 것이다.
우리 팀에서 그라운드 룰을 정할 때 개인적으로 다른 팀들의 그라운드 룰에 대해서 굉장히 많이 찾아보았다. 이 중에 끝까지 가지고 간 룰도 있지만 중간에 생긴 룰들도 많았고 우리 팀과는 맞지 않는 룰들도 있었다.
이렇게 팀의 그라운드 룰은 계속 변하고 이는 곧 팀의 색이 된다.
그 다음에는 사용자 스토리와 UX에 대해서 말하는 내용이였다.
사용자 스토리
사용자 스토리를 만드는 것의 주된 목표는 우선 서비스를 사용할 사용자를 특정하는 것이다.
팀원들끼리 처음에 서비스에 대해서 기획하고 설계하는 과정에서 어디까지 해야하나 라는 막연함이 있었다.
또한 각자가 생각하는 서비스의 목표에 대한 시각차이가 존재하여 이 부분에 대해 끝없는 회의를 하게 되는 상황도 발생했다.
이 과정에서 팀이 사용자를 특정하면서 얻게된 장점이라도 느낀 것들은 아래와 같다.
- 특정 사용자에 대한 기능을 마련하면서 목표의 싱크를 맞출 수 있게 되었다.
- 특정 사용자가 필요한 기능에 대해 정하면서 초기 기능의 범위에 대한 막연함이 해소되었다.
- 한 사용자가 필요한 기능들을 마련한다는 것은 규모가 작더라도 사용자가 사용가능한 서비스가 된다는 것이다.
- 전체적으로 서비스가 불가능해도 기능을 차례차례 만들어 최종적으로 원하는 서비스를 만드는 방식에서 점점더 서비스를 고도화하면서 발전하는 방식으로 자연스럽게 이어질 수 있다.
또한 다른 크루들에게 서비스에 가지고 있는 가치와 관련있는 질문을 통해 인터뷰함으로써 앞으로 우리 서비스가 가야할 방향에 있는 사용자를 특정할 수 있었다.
사용자를 특정한 이후에는 해당 사용자가 우리 서비스를 사용하는 사용자의 시나리오를 작성했다.
그 다음엔 작성된 시나리오를 통해서 우리가 우선순위에 둬야할 기능들을 도출해냈다.
UX (사용자 경험)
이 부분을 다시한번 회고하면서 이 부분에 대한 고려가 다른 부분에 비해 적었다는 것을 깨달았다.
- 사용자를 고민에 빠뜨리지 마라
- 누구나 어려움없이 사용법을 알 수 있어야 한다.
- 투입한 비용(수고) 에 비해 큰 가치를 얻을 수 있어야한다.
이 부분에 대해서 우리의 초반 서비스의 모습은 사용법에 대한 고민이 필요한 서비스였다. 이런 부분을 코치들의 피드백을 통해서 다시 깨닫고 이후에는 신경썼었다.
- 사용자가 웹을 사용하는 방법
- 사용자는 웹페이지를 읽지 않고 훑어본다. 여러개를 만들어서 보여주려고 하지 말자.
- 사용자는 최소 조건만 충족하면 만족한다.
- 사용자는 보통 시간에 쫒긴다.
- 사용자는 작동방식을 이해하려고 하지 않는다.
- 임기응변을 사용하여 해결할 수 도 있다.
- 사용자가 여러번 생각하게 하지말자.
위에 두가지 부분이 초기 자료에 있는지는 완전히 까먹고 있었지만 프로젝트 3차 데모데이 쯤 부터 개인적으로 신경썻던 부분이였던 것 같다.
회의 때 사용자에게 너무 많은 정보를 주지 않고 간단하게 우리의 기능을 사용할 수 있는 최소의 환경을 제공하는게 좋을 것 같다는 의견을 꽤 많이 냈던 것 같다.
그 다음은 팀 개발 문화에 대한 내용들이 있었다.
팀 개발 문화
업무의 세분화, 전문화
소프트웨어 개발에 있어서는 작업을 세분화, 전문화 시키는 경우 다른 사람에게 지식은 전달하는 과정에 더 많은 시간을 요구한다.
개인적으로 너무나도 뼈져리게 느낀 부분이였다.
프로젝트의 마지막 데모데이를 기한이 굉장히 빠듯하게 진행하면서 세분화가 이전에 비해 많이 이루어졌었다.
나는 인프라 쪽에 많은 신경을 쓰는지라 팀원들의 코드에 대해서 파악이 완벽하게 안되었다고 느껴 팀원들한테 모든 코드에 대한 리뷰를 올리겠다고 말하고 하루 밤을 새서 모든 코드에 대한 리뷰를 진행하면서 파악을 했던 경험도 있다.
개인적으로 참 많이 생각을 하게하는 내용이 다음이였다.
진통제같은 서비스
사람들이 고통을 겪는 핵심 기능을 초반에 잘 정의하는 것이 중요하고, 잘 정의되어 있다면 초반부터 사용자에게 피드백도 훨씬 유용하게 받을 확률이 높습니다.
내가 개인적으로 파악한 내용은 다음과 같다.
만약 당신이 개발자끼리 쉽게 정보 공유를 하기 위한 커뮤니티를 만든다고 한다면 당신은 커뮤니티에서 정보를 공유하는 경험을 위한 기능들보다는 공유를 쉽게 할 수 있는 경험을 위한 기능들을 더 집중해야 한다.
즉 사용자의 피드백도 커뮤니티 기능에 대한 피드백이 아닌 쉽게 공유하기 위한 기능에 대한 피드백이 더 필요하다.
목표 3단계
- 미니멈 : 프로젝트가 성공하기 위해 반드시 해결하려는 것
- 타겟 : 어렵지만 달성 가능한 목표
- 에픽 : 우리의 상상을 뛰어넘는 성공의 목표
위에 목표 3단계를 정해봄으로써 우리가 드러내고 싶은 핵심과 기능을 도출해 볼 수 있다.
레벨3를 통해 미니멈에 대한 해결은 성공적으로 이루었다. 개인적으로 위에 레벨4를 시작하면 팀원들과 다시한번 목표 3단계를 도출해서 타겟을 미니멈으로 바꿔보고 싶다!