Page History
| Info |
|---|
지라의 선택이유는 실제 이것을 잘 활용하는 개발팀 내에서 무의식중으로 사용해서 익숙해서이며 개발 프로세스가 어떻게 개선이 되었나? 경험을 바탕으로 지라의 기능을 통해 간단하게 설명을 하는 페이지입니다. |
...
티켓은 어떠한 주제의 단위 스토리,작업,부작업등이 될수 있고 티켓발급은 누군가가 해야할일이 생겼다란 의미도 될수있습니다. 익숙하지 않는 단어라 여기서 티켓=TASK=작업 단위로 한정짓겠습니다. |
생성된 티켓을 통해서만 개발(브랜치생성) 가능
...
PMS 티켓이 없으면, 개발일을 하지 못하게 하는건 아주 단순하고 강력한 프로젝트 관리방법입니다.
실제로 최고 관리지침이 갑자기 내려왔습니다. 티켓없이는 그냥 놀아라~
이것은 티켓없이 개발이 진행되고, 빌드관리자의 수동반영 경고를 무시하고 운영에 반영하는
고약한 문제를 인지한 상위관리자가 내린 지침이였습니다.
처음에는 혼란이였습니다. 작은단위의 일을 적어도 명시적으로 타이틀화를 해야하는것 부터 시작해야
했으며 작명은 쉬운일이 아닙니다. 문의에 대한 처리도(사소한 문제라고 생각한부분) 티켓을 통해 명시화 해야했습니다.
우리가 하고있는 작은 일들을 명시화함으로 잘못된 일을 알아가기 시작했습니다.
작은 어떠한 프로젝트진행과정중 비지니스로직에해당하는 문의가 구두또는 메신져를 통해서 전달이 되면 왜곡될수 있으며 그 왜곡된 사실이 타팀의 개발에 반영이
된다란것입니다. 그리고 그러한 잘못된 정보와 올바른 정보를 걸러내기 위해 다시 메일로그/메신져로그등을
확인해야 하는 절차를 거친다는 것입니다. 이러한 활동이 TASK로 명시화가 되면 정보제공자는
되면서 왜곡이 되고
그 왜곡된 사실을 타팀 운영개발에 반영이 된다란것입니다. 그러한 잘못된 정보제공자를 찾기위해
메일로그/메신져로그등을 확인하면서 책임자를 찾으려했으며 중요한 올바른 정보도 메일어딘가에 있었다는 사실입니다.
이러한 활동이 TASK로 명시화가 되거나, 관련 티켓에 정보를 추가하면
정보제공자는 적어도 어떠한 다이어그램을 그려가면서 설명하려하고 팀내에는 공유가되기때문에
팀은 그것이 올바른지 다시한번 다시 한번 확인할수 있습니다.
이것의 원초적 문제는 설계문서가 약할뿐더러 설계문서와 코드가 일치하지 않는 본질적인 문제에서
시작한 문제이며 문제이나 MBD(ModelBaseDesign) MDD(Model Driven Development)를 사용해서 해결의
실마리를 찾으려는 노력으로 연결이 된다란 것입니다.
핫픽스라할지라도 생성된 티켓의 브랜치를 생성통해 작업이 진행되어야 하며 사소한 개선 변경역시 포함됩니다실제 PMS의 티켓(TASK)가 만들어지면 어떠한 기능을 활용할수 있는지 살펴보겠습니다.
개발티켓에서 브랜치를 직접 생성할수있으며 부가적으로 전체 프로젝트 스케쥴및 배포관리등을 소스관리,코드리뷰,자동배포등 티켓을 통해 유기적으로 할수 있게됩니다.
어떠한 이유가 없이는 소스 커밋도 되면 안되고 , 배포도 되면 안되기 때문입니다.
분기점(브랜치) 만들기를 수행했을때 작동되는 UI
...
코드리뷰 코멘트에대한 대응으로, 피드백 교환및 바로 개선작업을 만들수가 있습니다.
| Warning |
|---|
Git에서 직접 브랜치를 생성하고 작업을 시작하면 해당 작업이 프로젝트 관리에서 제외될수가 있습니다. |
PMS를 통해 진행된 작업은 빌드툴(밤부)에 연동되어 개발장비 자동반영가능하며 -보통 브랜치 빌드
배포여부를 통해 QA 진행도가능합니다. ( 배포자동화로 잠수함 패치 방지 )
여기서 품질향상은 진행된 티켓을 통해 코드 개발코드 리뷰 과정도 포함될수 있습니다.
...
또한 빌드와 관련된 머지 이슈도 마찬가지입니다. GIT에서 머지를하고 수동반영하고 , PMS에는 언급이 되지 않았지만 소스 형상관리 자체는 된다고 볼수 있으나! 이를 모르는 QA는 , 결함이아닌 어제와 다른 오늘의 어플리케이션 차이가 뭘까요? 테스트 계획은 하지 못할뿐더러 개발자의 수수께끼를 푸는데 대부분의 시간을 보내야 합니다. |
| Info |
|---|
운영배포 티켓은 운영에 반영되는 만큼 다음과같은 엄격한 조건을 걸수가 있습니다.
|
...
티켓(Task)을 통해 문서화 추적기능
...
프로젝트 메니져(지라) 에서 문서를 언급을 하던지?
...
스프린트는 한달이상의 계획으로 밀린 문서화와 테스트 품질향상을 마지막에 몰아서 하는 리스크를 줄이기위함입니다. (폭포수모델의 위험)
개발 배포단위를 작게 나눠 개발-문서화-배포-TEST를 지속적 진행하여 작은단위로 통합하는게 목표이며(애자일에서 주로 언급)
배포자동화툴-QA및 개발이슈를 관리하는 프로젝트관리툴 -소스관리툴-문서화툴 등이 아주 잘 연동이 되어야합니다.
실제 운영과 신규기능을 동시에 추가해야하는 개발팀에서는 업데이트 주기가 느슨한 폭포수 모델로 진행했으며
아직 운영을 하지않는 신규 개발팀에서는 스크럼방식을 도입하고 스프린트단위로 작게 기존기능을 따라오고 개선기능을 추가하려했습니다.
순발력있게 개선된 기능을 짧은주기로 배포및 QA까지 마치는것은 이상적이나, 기존 서비스가 솔리드형태로 뭉쳐져 있었고
어떠한 작은것을 고쳤을때 영향범위 측정이 안되고, 자동화테스트툴이 준비가 안되어 작은수정 몇가지에도 풀테스트가 필요했기때문에
이미 개발 프로세스가 고착화된 실제 운영서비스에서 새로운 개발 프로세스를 도입하는것은 쉽지 않습니다.
이렇게 진행된 티켓들의 리포팅은 자유롭게 자동생성가능합니다. (별도의 리포팅기능이 있으나, 위키에서도 동적으로 언급 가능합니다.)
...