생성된 티켓(Task)을 통해서만 개발(브랜치생성) 가능

...

PMS 티켓이 없으면, 개발일을 하지 못하게 하는건 아주 단순하고 강력한 프로젝트 관리방법입니다.

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

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

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

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

했으며 작명은 쉬운일이 아닙니다. 타팀의 문의에 대한 처리도(사소한 문제라고 생각한부분) 티켓을 통해 명시화 해야했습니다.

우리가 하고있는 일을 작은 일들을 명시화함으로 잘못된 일을 알아가기 시작했습니다. 

작은 문의가 구두로 구두또는 메신져를 통해서 전달이 되면 왜곡될수 있으며 그 왜곡된 사실이 타팀의 개발에 반영이

된다란것입니다. 그리고 그러한 잘못된 정보와 올바른 정보를 걸러내기 위해 다시 메일로그/메신져로그등을

확인해야 하는 절차를 거친다는 것입니다.  이러한 활동이 TASK로 명시화가 되면 정보제공자는

적어도 어떠한 다이어그램을 그려가면서 설명하려하고 팀은 그것이 올바른지 다시한번 확인할수 있습니다.

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

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

실마리를 찾으려는 노력으로 연결이 되며 이것만 관리하고 개선하는 아키텍트가 생겨나게됩니다된다란 것입니다. 

핫픽스라할지라도  생성된 티켓의 브랜치를 생성통해 작업이 진행되어야 하며 사소한 개선 변경역시 포함됩니다.

...