Page History

...

티켓:특정한 것을 할 수 있는 자격. (네이버사전)

처음에는 , 뭔가 답답했습니다.  우리는 우리만의 아날로그적인 감성과 , 아날로그적으로 일하는것을 더 선호했습니다.

내가 하는일의 제목을 무엇으로 달지?  할당은 누구에게 하지? 그냥 담당팀 아무개한테 해달라고 하면 해줬는데~~

이런 고민을 하는게 아주 소모적이였습니다. 그리고 내가 하는 일을 스스로 보고하여 트래킹 당하는것도 싫었습니다.

그러면서 잘못된 세가지를 알게되었습니다.

• 상대팀의 리소스를 , 내가 함부로 사용할수 없다란것. 
• 또한 그 리소스에 대한 역활및 사용권한에대해  애시당초 정의한적 없었다란것
• 미리 계획하고 요청했을 기회를 무시하고 , 나중에 언제든 요청하면 바로 해주겠지하고 미룬것

...

• 퇴근시간 갑자기 생긴일에 응대를 해주면 착한 개발자 
• 문의받은 그내용이 무엇인지 어렵풋이알지만 신속하게 잘못된 정보로 응대를 해줘도 착한 개발자

그렇습니다. 기존에는 자신의 팀업무를 위해서 특정누구한테 문의가 집중되었으며 관리도 안되었습니다.

할당수로 측정이되니, 이제 팀내에서 분업을 어떻게 시킬까 고민을 하게 만들었습니다. 대부분의 팀의 일은

이제 팀장에게 직접 할당이 되니까요.

 어쨋건 우리가하는일을 트래킹 시스템을 도입하고 ,아주 세세한 일까지

...

하지만 어딘가 이러한 티켓이 발견이 됩니다. "BI-001 다중기기를 로그인을 허용했을때 수익증가율 분석"

그리고 사업부 에서 사업부에서 BA(비지니스분석,기획)에게 이 티켓을 좀더 분석해 구체안(기획서)을 만들라고 할당합니다.

...

PM은 이때 냄새를 맡고 , 개발관련 스케쥴을 컨트롤 하려고 합니다. 그리고 으 프로젝이 런칭될때까지 책임을 집니다런칭일을 준수하지 못하면

프로덕트 메니져에게 혼나기 떄문입니다.

"PKIV-001-다중기기 사용자를 대비한 멀티 로그인  대장정(EPIC)"  우선 가장 거대한 티켓을 만들고 봅니다.  

(여기서 PKIV는 프로덕트기준 약속된 개발관련 접두어이며 자동으로 붙습니다.)

이때 대부분의 사업요구서와 기획티켓이 연관이되기때문에 여기에 직간접 참여한 모든 개발자및 QA 데브옵스 디자이너등등

자신이 무엇때문에 일을 하고 있는지 그 이유에대해서 알게됩니다. 

 아키텍트의 참관하에 BA가 설명을하고 어떤 개발팀이 필요한지 물어봅니다.  

...

QA는 QA범위 산정을 위해 미리 참관을하지만, 새롭게 작동되는 방식에대해 의문을 제기합니다제기하기도 합니다. 기존작동은 아시냐구요?  

서버팀도 한마디 합니다. "이거 부하 증가가 예상되어 로그인서버 2대더 필요합니다." 하지만  뒤늦게 후회합니다. 다중기기 허용하면 부하증가 어떻게 하실겁니까?" 하지만  아차합니다. 자기팀에서 해야되는 일이기때문에

괞히 부하이야기 꺼냈다가 아키텍트가 로드 테스트팀을 붙여서 로드테스트 티켓도 만들어버립니다. 차라리 스케일업할껄이라고~

갑자기 PM은 그래 서버가 필요해? 잘 쉬고 있는 데브 옵스를 데리고 오고, 데브옵스는 "ITO-001-개발서버두대추가" 티켓을  즉석으로 만들고

PKIV- 멀티로긴 개발대장정(EPIC) 티켓에 연결시킵니다. 물론 이 서브티켓에는 BIGIP등록및 BIGIP설정및 SSL인증서 라우터룰셋팅등 잡다한 티켓이 생성됩니다.

알고싶지는 않지만, 서버두대 추가로 해야되는 고급 일들이 많아 보입니다. 그리고 데브옵스는 임무를 마치고 자기일 하러 갑니다.  아직 프로젝트이

완료되려면 한참 남았으니까요 

결국 DB / 서버 / 클라이언트/모바일팀  4팀에서 개발을 하기로 결정하고 기획서의 숨겨지고 함축된 의미에 대해

...

PM이 BA및 아키텍트의 조건부 승인을 받아냅니다. 런칭 날짜가 더 중요하니 이 로직은 그냥 서버에 있게하자~~ 있게하고 다음에 개선하자

어느정도 아키텍쳐가 그려지는듯 하더니   이러는 동안 PRD(프로덕요구사항)에 수정이 일어나고,

...

이때까지한 설계가 수포로 돌아가거나, 수정이 필요합니다.  아키텍. 원래부터 탄탄한 구조가 아니였기에 옵션화를 통해 할수 있는게 아닙니다.

여러가지 사이드 이펙트 문제로 아키텍/개발자/기획 의 논쟁이 끝나지 않습니다. 

이런문제는 관련 충돌 담당자 모두를 모든 충돌사항을 수용을 시켜야 해결이되며, 일을 시작할수 있습니다그것이 끝날때까지는 개발이 시작될수없습니다.

이때 항상 해결자가 등장하여, 어떠한 중립적인 아키텍쳐를 제시하여 그 문제를 해결을 합니다.  

이러한 설계 티켓번호는 분쟁이 심하면 내용으로 기억되지 않습니다.

...

QA는 조용하게 이때까지 준비한 테스트 케이스를  모두 폐기하고, 최종 결론본에 맞춰 처음부터 다시작성합니다.

개발

그이전에 개발 이전에 수많은 분석및 설계 티켓이 먼저 생성되었지만 생략하였습니다생성되었습니다. 그렇습니다. 그것은 티켓번호 7782입니다.

PKIV-001 대서사시(EPIC) 에대한 서브 티켓으로  스토리가 생성되었습니다. 

• PKIV02-DB팀의 다중 로그인 추가에 대한 이야기(STORY)
• PKIV03-서버팀의 다중 로그인 추가에 대한 이야기(STORY) 
• PKIV04-클라이트팀의 다중 로그인 추가에 대한 이야기(STORY)
• PKIV05-다중로그인 테스트에대한 아름다운 QA의 이야기(STORY)

...

진행사항을 PM이 개입하기 시작합니다. PM은 스토리 과정에 작업 과정에는 관심이 없고 스토리가 모두 완료되는것에만 관심이 있습니다.

실질적인 하위 일(TASK)이 모두 끝나야 각팀의 이야기가 끝나기 때문에 당근과 채찍을 준비합니다때문입니다. 

개발팀은 소스변경범위를 어느정도 예측하여 QA에게 테스트 범위를 대략 알려주지만, 쓸모없습니다.

대부분 버그는 개발자가 안 알려준곳에서만 생깁니다. 체크리스트는 개발자가 알려준곳 제외하고 나머지를 정리하는것입니다.

소스및 소스에따른 구동환경은 다음과 같이 진행됩니다.

최신 master로부터  featured-기능 브랜치를 각각 만들고,  개발테스트가  로컬 개발테스트가 완료되면   release -1 브랜치로 통합하여 QA를 준비합니다.

이와 동시에  데브옵스는 릴리즈 브랜치를 확인하고 DEV 배포 환경을 준비합니다. (완전 자동화는 아님)

DEV 배포환경이라고 각 기능서버가 한대씩만 존재 하지 않습니다.

실전과같이  스위칭 환경 테스팅도 포함되기때문에 스위칭이되는 장비는 최소  이중화가되어 쌍을 이룹니다.

또한  개발서브  실제 개발 서브 도메인을 사용합니다.  host를 변경하여 테스트하는 순간 변질된 테스트이기때문입니다.

한가지 팁을 알려드리면, 이런것이 가능한것은 내부/외부 모든 url은 설정화이며 백오피스에 런타임으로도 바꾸면

모든 서버및, 모슨 수만명의 브라우져 사용자에게 실시간 변경사항 적용되기 때문에 가능합니다.

host를 변경하는 테스트를 DEV테스트라고 하지 않습니다. 이것은 QA에 내보낼수 없는 로컬 테스트입니다.

...

완벽하게 작동됩니다. 라고 이야기하는것입니다.

DEV-QA

개발이 완료되고, release 브랜치를 통해 QA가 시작됩니다. 여기서 여러가지 수정사항이 생깁니다.

기획서의 내용이 추가되고 개발이 추가됩니다. 동시에 기능 TEST를 하고 A를 FIX하고 문제가 없던 B가 문제가 생깁니다. 

...

10번 시도하고 8번정도 복구가됩니다.  인터넷 제공업체의 인터넷 품질에 대해 커버를 모두할수는 없기에 테스트 OK하고 넘어갑니다. 

 이제 대서사시(EPIC) 종료를 위해

...

대서사시의 마무리단계에서, 중간 이야기를 변경하면 그 이후의 이야기도 다시 작성해야 하기때문입니다. 하기때문에 독자들이 화를 낼것입니다.

(QA를 또해야한다는 뜻)우리끼리 약속한 릴리즈가 프리징단이 문제없을것이다라고 희망을 합니다또해야하고, QASingOFF 날짜도 PM과 약속한 QA가 완료해야할 날짜가 있기때문입니다. )

DEV-릴리즈 프리징이되었으며 이것은 서비스에바로올려도 문제가 없을것이다란 희망입니다. 그리고 통합환경인 INT로 넘어갑니다.

INT-QA

INT환경은 소스통합 테스트를 위한 개발환경이 아닙니다. 소스통합에 따른 문제는 DEV단계 Release 프리징을 통해 이미 완료 되었으며

...