Exception을 보고 흥분하지 않으면 개발자가 아니다.(2)

“개발자를 믿는 것이 해결의 출발점입니다.
프로젝트는 개발자의 머리와 손으로 만들어지게 되고 개발자를 믿지 못한다면 프로젝트 자체를 믿지 못하는 것과 같습니다. 프로젝트가 제대로 될 수 있을까라는 의심을 가지고 있다면 어떻게 성공적인 프로젝트를 만들 수 있겠습니까? 그렇다고 개발자를 모두 믿고 그냥 기다리라는 건 아닙니다. 개발자의 무엇을 믿을 것인가가 중요하겠죠.

개발자의 경력? 개발자의 지식수준? 개발자의 사회성?

세가지 전부 중요합니다. 경력은 경험을 말하고 지식수준은 업무이해도와 코딩실력을 말하고 사회성은 소통을 말하는 거겠죠. 하지만, PM님이 믿어야 하는 것은 개발자의 본성입니다. 개발자의 본성이 발현되는 방향으로 프로젝트를 진행하면 위 세가지가 모두 낮더라도 프로젝트에 온 힘을 쏟게 되고, 반대로 개발자의 본성이 억제되는 방향으로 프로젝트를 진행하면 위 세가지는 모두 필요없게 됩니다.

개발자는 차별성을 지닌 creator의 본성을 가지고 있다고 했습니다. 또한, 이 본성으로 부터 독립적이고 스스로 완벽하려고 하는 성질을 가지고 있다고 말씀드렸습니다. 이러한 본성을 최대로 발현하기 위해 어떻게 하면 좋은 지 한가지 경우를 말씀드리겠습니다.

개발단계를 개발초기, 개발중기, 개발후기로 나누시기 바랍니다. 개발 초기에는 전체 개발의 30%를 배정하고 개발중기에는 60%를 배정하고 개발후기에는 10%를 배정하도록 요청하세요.

개발완료는 개발자 스스로 완료를 결정짓게 하면 됩니다.

개발자는 해당 단위개발건에 대해 어느 정도 구성이 갖춰져서 다음 단위 개발건으로 넘어 갈 수 있을 때 완료라고 정의합니다. 개발자는 PMS에 개발이 완료되었다고 해서 절대로 그 단위 개발건을 가만 놔두지 않습니다. 연관된 다음 단위 개발건이 어느 정도 진행되면 다시 이전 단위 개발건을 맞춰서 진행, 수정을 반복합니다. 개발 중기 까지 90%의 개발진척률을 보이는 것은 버거울 수 있습니다. 하지만, 단위 테스트 없이 진행한다면 가능한 수치이고, 가능해야 합니다.

개발후기에 단위테스트를 진행하고 단위테스트는 SUB PL이 책임지게 하십시오.

SUB PL도 개발에 참여하기 때문에 개발계획 수립시 반드시 이 부분을 명시해야 합니다. 그래서 SUB PL의 개발은 개발 중기에 끝날 수 있도록 계획이 수립되어야 합니다. SUB PL은 단위 개발 영역 전체에 대해 이해도가 높아 단위테스트 진행을 유도리 있게 진행할 능력이 있습니다. 스스로 테스트 데이터를 만들어 낼 수 있고 테스트를 보류해야 하는지의 여부도 판단내릴 수 있습니다. 개발 중기 후반에 SUB PL에게 단위테스트 목록 작성을 요청하세요. 단위테스트 목록은 화면위주로 작성하고 화면ID, 화면명, 개발자, 테스터, 테스트일시, input, process, output, result, 비고 의 내용으로 엑셀로 작성되는 것이 좋습니다. 화면ID 하나에 테스트 건이 20 – 40 건이 도출될 수 있습니다.

이 단위테스트 목록은 SUB PL과 조직의 개발자간 공유되며 결함 발생 시 SUB PL과 개발자간 논의하여 해결하게 됩니다. 단위테스트를 이렇게 진행하면 개발이 90% 정도 진척된 상태에서 대부분 보류 없이 진행할 수 있으며, 화면간 순차적인 테스트가 아닌 병렬적이고 연관된 테스트가 진행됩니다.

또한. 개발 후기의 마지막은 이 목록으로 현업이 직접 테스트를 진행합니다. 이 목록에는 테스트 데이터 및 방법등이 실제 테스트를 진행한 내용으로 기재되어 있어서 원활한 테스트가 가능합니다.

진척률 관리는 개발진척률, 단위테스트 진척률을 별도로 관리하시기 바랍니다.

개발진척률은 단위개발건의 목표 완료 수 대비하여 현재 완료 건을 비교하시면 됩니다. 단위테스트 진척률은 단위 개발건이 아닌 전체 단위테스트 건 목표 완료 수 대비하여 현재 완료 건을 비교하시면 됩니다.
마지막으로, 단위 테스트 증빙서류에 대해서는 전체가 아닌 주요 테스트 결과만 단위테스트 목록에 sheet로 추가하도록 요청하세요. SUB PL이 추가할 것이며 SUB PL을 믿으셔야 합니다.”

“너무 좋은 제안입니다. 이런 식으로 해서 문제없이 진행된다면 그보다 좋을 수는 없겠죠. 그런데, 걱정되는 것은 개발이 지연되거나 실제 개발이 완료되지도 않았는데 완료되었다고 하면 어떡하죠? “

“개발 지연도 결국 개발자와 SUB PL이 원인을 찾아서 해결해야 하는 일입니다. 다른 누구도 해결 해 줄 수 없죠. 그 원인이 팀 내부가 아닌 다른 곳에 있다면 나서서 해결해 주셔야 합니다. 반대로 내부에 있다면 개발자와 SUB PL스스로 해결할 수 있도록 믿고 기다려 주고 계획을 수정하여 다른 개발건부터 진행할 수 있도록 해야 합니다.
개발의 완료 여부에 대한 것은 단위테스트 기간에 해결됩니다. 물론 개발의 완성도에 따라 단위테스트 기간에 어려움을 겪을 수는 있습니다. 하지만, 개발자와 SUB PL은 잘 헤쳐나갈 것입니다. 믿어준다면요.”

“많은 생각이 듭니다.

개발자를 믿는다는 것, 믿어야 한다는 것. 개발자는 분명 성공해 낼거라는 믿음.

감사합니다.”