Page History

 하루에도 여러차례 서비스코드를 개선하기위해 커밋을하고, 그 커밋은 어떠한 결정에 의해 이루어졌으며

또한 서버재부팅도 어떠한 원인 파악을 통해 이루어졌지만 지식및 운영에 관련하여 그어떠한 노하우도 쌓이지않고

높아지지 않았습니다. 1년전과 똑같은 오늘을 보내고 있다라고 생각한 상위 관리팀에서 이러한 지침이 내려왔습니다.

그냥 놀아라, 너가 노는것을 보장해주겠다.

하지만 활동을 하고 싶은면 너가 하는일이무엇인지?  사소한 일도 티켓을 만들어라~

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

그렇게 이야기는 시작이 됩니다.

신규기능 추가

 신규기능은 어떻게 추가하나? 사업부에서 어떠한 아이디어를 떠올려 초안을 세웁니다.

...

내용: 다중기기 사용자가 늘고있으니, 멀티로그인을 허용해라~~ 이하 생략,아니 없음

왜 시작하는지 아무도 모릅니다. 그냥 BI가 "다중기기를 허용했을때 수익률증가?"

라는 리포팅을 했을거같은 의문점이 듭니다. 

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

그리고 사업부 에서 BA에게 이 티켓을 좀더 분석해 구체안(기획서)을 만들라고 던집니다. .

비지니스 분석가가 기획서를 만들어야하는것인가?에 대해서는 개발자는 알수없습니다.

기획자라고 부르지 않았으니까요~~ 

기획초안 작성

 이제 BI는 BA는 발빠르게 움직입니다. 도대체 이게 무슨 내용이지?  기존 작동법부터 배우기시작합니다.

...

충돌이나는 기존 기능에대해 고려하지 못할수도 있습니다.

그리고 기획문서가 완성되기 시작하는 기획문서 초안이 완성되는 시점 관련 개발팀을 소집합니다.

"기획-001:멀티 로그인을 통한 플래폼 기능개선"  내용: prd에서 내용약간 추가됨

BI와 개발자는 의사소통도안되고 만나면 싸우기때문에BA와 개발자는 의사소통이 어렵기 때문에, 아케텍트에게 개발가능하게 구체화해달라고 구체화 해달라고 토쓰합니다.

분석

 각 개발팀이 모여 어떻게 누가? 어떻게 개발해야할지 분석에 들어갑니다.  PM은 이때 냄새를 맡고 , 개발관련 스케쥴을 컨트롤 하려고 합니다.

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

(여기서 PKIV는 프로덕트기준 개발 티켓명입니다그들만이 사용하는 개발관련 티켓명이며 자동으로 붙습니다.)

아키텍트의 참관하에 BI가 BA가 설명을하고 어떠 어떤 개발팀이 필요한지 물어봅니다.  개발팀이 거짓말 못하게 개발팀의 거짓말을 방지하기위해

감독역활로 아키텍트는 그냥 참관합니다. QA는 QA범위 산정을 위해 미리 참관을하지만, 기존 작동되는 방식에대해 더많은 설명을 하게되며

BI를 가르쳐줍니다.  서버팀은 말합니다이것은 문제가 될것 같은데요 라구~~  

서버팀더 한마디 합니다. "이거 부하 증가가 예상되어 로그인서버 2대더 필요합니다." 하지만  뒤늦게 후회합니다.

괞히 부하이야기 꺼냈다가 아키텍트가 로드 테스트팀을 붙여서 로드테스트 티켓도 만들어버립니다.

PM은 잘 쉬고 있는 데브 옵스를 데리고 오고, 결국 데브옵스는 "ITO-001-개발서버두대추가" 티켓을  즉석으로 만들고

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

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

결국 DB / 서버 / 클라이언트/모바일팀  결국 4팀에서  4팀에서 개발을 하기로 결정하고 숨겨지고 함축된 의미에대한 기획문서를 재해석하기 시작합니다. 의미에 대해

기획문서를 두리뭉실하게 재해석을 하고 파이팅을 외치며 회의는 끝나게 됩니다.

설계

 아키텍트는 이떄부터 개발팀과함께 다이어그램을그리기 시작하며

개발팀의 어떠한 기능에대해  비지니스 로직이 어디에 있어야 하는가에 대해 분쟁이 시작됩니다. 이 연산은 DB가 해라? 서버가해라? 클라이언트에서해라?

DB냐? 서버냐?  게으른 서버개발자는 이것을 클라이언트에게 넘기기도 합니다.

아키텍트는 아름다운 중재를 합니다. 반반씩 해라~~~  DB반 서버반....  이 단계가 길어집니다. PM이 개입합니다.

아무나 빨리해라~~  어느정도 뭣이 중한디? 아무나 빨리하고 일정을 맞추시오. 어느정도 아키텍쳐가 그려지는듯 하더니   이러는 동안 PRD에 PRD(프로덕요구사항)에 수정이 일어나고,

기획서가 변경됩니다.   기획-001 수정01 - 멀티로그인 티켓을 은근슬쩍 수정하여 공지합니다

멀티 로그인 허용이지만 모바일은  허용하고,PC는 비허용

다시 분석단계를 돌아 설계단계로 와서  아키텍/서버/DB 의 논쟁이 끝나지 않습니다.

...

숫자로 기억됩니다.  7782번 티켓이라고  ..... 어쨋든 이문제를 해결하고 개발시간을 다 까먹었지만 릴리즈 날자는 변경없이 다음 단계로 돌입하게 됩니다.

개발

PKIV-001 스토리에대한 대장정(EPIC) 에대한 서브 티켓으로  에픽이  스토리가 생성됩니다.

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

...

• 테스트에대한 아름다운 QA의 이야기(STORY)

각팀에서 해야할 스토리들이 만들어집니다.  하부에 어떠한 개발 티켓이 추가되고 그룹핑이 될지는각팀에서 알아서 합니다.  STORY가 추가가되고

그 이야기에 대한 하부를 어떻게 그룹핑하고 풀어야 할지는 각 개발팀이 만들어야 하며 이때부터

진행사항을 PM이 개입하기 시작합니다. 

개발팀에서는 소스변경범위를 어느정도 예측하여 QA에게 테스트 범위를 대략 알려주지만, 쓸모없습니다. 개발자가 안 알려준곳에서만 문제가 생깁니다.

...