개발자에서 아키텍트로 4차 스터디

오늘은 `개발자에서 아키텍트로`라는 책의 11~13장을 읽고 공유하는 자리를 가졌다.

 

나는 11장, 아키텍처 문서화하기 를 읽고 느낀점에 대해 공유했다.

특히 책에서는 변경가능성과 공유 범위에 따라 아키텍처 서술 방식이 결정된다고 되어있는데, 

물론, 명세서와 테스트케이스는 다르지만 테스트케이스는 어느 서술방식이 적정한지,

그리고 어떠한 툴을 사용하는 것이 좋을 지에 대해 생각해보게 되었다고 말했다.

동시에 테스트케이스보다 가벼우면서 다른 느낌인 테스트맵이라는 개념을 공유드렸는데,

피그잼을 사용한 테스트맵은 영향도 파악이 편리하고 테스트케이스보다 정형화되어있지 않아서

애자일 프로세스를 가진 프로젝트에서는 테스트케이스보다 좀더 적절하지 않을까? 하는 생각을 했다.

 

이와관련하여 다른 QA분이 본인의 경험을 공유해주셨는데, 실제로 테스트 맵을 도입했을 때

테스트 영향도 파악 및 테스트 범위 가시화에 대한 도움을 받았다고 말씀하셨다.

 

다만, 수정 로그를 추적하기가 어렵다는 단점때문에 현재는 다시 엑셀을 사용하고 있고,

현재는 중간 시스템을 맡고있는데 영향 범위 파악은 좋지만 대시보드에 대한 이야기를 진행하고 있다고 했다.

 

이와 관련하여 나는 아직 테스트맵을 사용해본 경험이 없지만,

프로젝트 상황에 맞춰서 서술 방식을 결정하고 테스트케이스와 테스트맵 중 하나를 고르는 것이 아니라,

상황에 맞게 커스터마이징하여 문서화하는 것이 더 좋을 것 같다고 의견을 말했다.

---

다른 QA분은 12장 평가하는 단계에서 팀 내부적으로 사인오프하는 부분에 대해서

기준이나 정책을 어떻게 가져갈지를 재정립하는 단계인데, 이 책을 통해서 어떤 부분을 놓치고있는지 등

모호한 부분들의 정책을 정립해할 지에 대해 도움을 받을 수 있었다고 말씀해 주셨다.

 

동시에 기준을 QA에서 제공하는데 제공 후 전체적으로 문서화하고

이해관계자들에게 리뷰하는 자리를 만드는 것을 생각하고 있다고 하셨다.

---

백엔드 개발자분은 11장을 통해 개발자로서 의사소통할 때 어떻게 해야할까? 에 대해서 돌아보게 되었다고 했다.

또한 누구에게 보여줘야할지를 미리 정하면 표기법 및 단어 사용법이 자동으로 세팅된다는 부분이 와닿았고

이와 관련하여 QA분들이 개발자분들과 이야기할 때 어떤부분이 의사소통상의 오류가 있었는지,

어떤부분을 공유해주면 좋았는지 등에 대해서 공유해주실 수 있는지 물어보셨다.

 

이에 대해 나는 개발자분들로부터 공유받을 때, 개발언어로 공유받았을 때 이와 관련하여 영향범위나

어떤 부분을 테스트해야하는지 등에 대해서 공유해달라고 요청드렸고 강경한 포지션을 취한 적이 있었다고 했다.

 

또한 QA는 서비스의 전체적인 부분을 보기 때문에 개발자분들이 한 부분을 수정했을 때,

개발자분들이 보이는 부분보다 훨씬 많은 부분들이 영향을 받게 되고, 이와 관련하여 공유드렸을 때,

방어적인 태도가 좋지 않다고 말씀드렸으며, 이와관련하여 다른 QA 분들도 동감하셨다.

 

다만, 이러한 것들 기반에 서로 존중하는 마음을 가지고 있어야 하며 나는 처음 일을 시작할 때부터

개발자분들께 `감사합니다.` 라는 단어를 무조건 사용하게끔 교육을 받았다고 말씀드렸다.

 

동시에 개발자분들도 버그리포트를 받거나 수정확인을 요청할 때 서로 감사를 표하는 분위기가 있었기 때문에

강경한 태도를 취했을 때에도 나쁜 분위기가 아니라 좋은 분위기에서 일할 수 있었던것 같다고 말했다.

---

풀스택 개발자분은 11장, 12장을 읽으면서 방법론에 대해 주의깊게 읽었다고 했다.

 

특히 11장의 공감지도와 12장의 루브딕이라는 개념이 신선했다고 공유해주시며

공감지도에 대해 스스로 생각해본 경험은 있지만, 이해관계자들을 대상으로 진행하면 좋을 것 같다고 하셨다.

루브릭은 사이드프로젝트나 현제 진행하는 프로젝트에서 진행할 수 있을것이라고 하셨다.

 

나는 도중에 루브릭을 실제로 사용해본 경험이 있는지 여쭤봤고, 가용성 같은 경우, 트레이드오프가 있는데

그것들이 결정되었을때 사유들을 함께 정의해서 루브릭으로 정의할 수 있을 것 같다고 하셨다

---

마지막으로 나는 11장 마지막에 나온, "가지 않은 길을 공유하는 것" 에 대해 언급했다.

결정사항을 이해하도록 돕는 방법은 거부한 선택지를 보여줌으로서, 맥락을 파악할 수 있도록 한다는 부분이고,

 

실제로 선택했던 것들을 공유하기 편한데, 실패했떤 사유들에 대해서는 기록을 남기는것이 쉽지 않았으며,

이러한 것들에 감명을 받았다는 점을 함게 공유해주셔서 보람있는 스터디 활동이었다.

---

오늘은 11~13장에 대해 이야기해보았고, 나는 12, 13장을 다시한 번 읽어봐야겠다고 생각했다.

 

다음 스터디는 14장부터 마지막까지 읽어보고 의견을 공유하기보다

서로 어떤 방향으로 스터디를 이어나갈 지에 대해 이야기해보는 시간을 가지려고 한다.