Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

Expand
title티켓과 관련된 경험담

 실제로 최고 관리지침이 갑자기 내려왔습니다. 티켓없이는 그냥 놀아라~

이것은 티켓없이 개발이 진행되고, 빌드관리자의 수동반영 경고를 무시하고 운영에 반영하는 

고약한 문제를 인지한 상위관리자가 내린 지침이였습니다.  


처음에는 혼란이였습니다. 작은단위의 일을  명시적으로 타이틀화를 해야하는것 부터 시작해야

했으며 작명은 쉬운일이 아닙니다. 사실 이런게 귀찮아 비싼 PMS툴을 도입해도 잘 기입하려 하지 않습니다.  

문의에 대한 처리도(사소한 문제라고 생각한부분) 티켓을 통해 명시화 해야했습니다.

그 이전에는 어떠한 프로젝트진행과정중 비지니스로직에해당하는 문의가 구두또는

메신져를 통해서 전달이 되면서 왜곡이 되고 그 왜곡된 사실을 타팀 운영개발에 반영이 된다란것입니다되버린다는것입니다.

그러한 잘못된 정보제공자를 찾기위해 메일로그/메신져로그등을 확인하면서 책임자를 찾으려했으며

중요한 올바른 정보도 메일어딘가에 있었다는 사실입니다.

이렇게 아날로그적으로 작업을 진행하는게 올바르다라고 생각했으며

우리가 하고있는 작은 일들을 명시화함으로 그러한게 잘못된것임을 알아가기 시작했으며

 다음과 같이 개선이 되었습니다.

이러한 활동이 TASK로 명시화가 되거나, 관련 티켓에 정보를 추가하면

정보제공자는 적어도 어떠한 다이어그램을 그려가면서 설명하려하고 팀내에는 공유가되기때문에

그것이 올바른지 다시 한번 확인할수 있습니다.

이것의 원초적 문제는 설계문서가 약할뿐더러 설계문서와 코드가 일치하지 않는 본질적인 문제에서

시작한 문제이나  MBD(ModelBaseDesign) MDD(Model Driven Development)를 사용해서 해결의

실마리를 찾으려는 노력으로 연결이 된다란 것입니다. 

...