Versions Compared

Key

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

...

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


Expand
title티켓과 관련된 경험담

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

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

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


처음에는 혼란이였습니다. 작은단위의 일을

...

 명시적으로 타이틀화를 해야하는것 부터 시작해야

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

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

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

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

메신져를 통해서 전달이 되면서 왜곡이 되고

...

그 왜곡된 사실을 타팀 운영개발에 반영이 된다란것입니다.

그러한 잘못된 정보제공자를 찾기위해

...

메일로그/메신져로그등을 확인하면서 책임자를 찾으려했으며

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

...

.

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

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

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

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

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

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

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

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

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


실제 PMS의 티켓(TASK)가 만들어지면 어떠한 기능을 활용할수 있는지 살펴보겠습니다.

...

배포자동화툴-QA및 개발이슈를 관리하는 프로젝트관리툴 -소스관리툴-문서화툴 등이 아주 잘 연동이 되어야합니다.


Expand
title스프린트와 관련한 경험담


실제 운영과 신규기능을 동시에 추가해야하는 개발팀에서는 업데이트 주기가 느슨한 폭포수 모델로 진행했으며

아직 운영을 하지않는 신규 개발팀에서는 스크럼방식을 도입하고 스프린트단위로 작게 기존기능을 따라오고 개선기능을 추가하려했습니다. 

순발력있게 개선된 기능을 짧은주기로 배포및 QA까지 마치는것은 이상적이나, 기존 서비스가 솔리드형태로 뭉쳐져 있었고

어떠한 작은것을 고쳤을때 영향범위 측정이 안되고, 자동화테스트툴이 준비가 안되어  작은수정 몇가지에도 풀테스트가 필요했기때문에

이미 개발 프로세스가 고착화된 실제 운영서비스에서 새로운 개발 프로세스를 도입하는것은 쉽지 않습니다.  





이렇게 진행된 티켓들의 리포팅은 자유롭게 자동생성가능합니다. (별도의 리포팅기능이 있으나, 위키에서도 동적으로 언급 가능합니다.)

...