제목 : 소프트웨어공학 테크니컬세미나의 연사님으로 초청드립니다. (8월 29일)
(▼ 아래) 메일 내용 일부
 |
"어?? 나를?? 무슨 근거로 나를??" -_-
GCS 정부과제 수행을하면서 품질 검토를 진행한 NIPA 담당자의 추천이었다.
좋은 기회이다 싶어 회사에 동의를 구하고 수락했다.
문제는 그다음이다.
4월에 SW 품질 세미나에서 발표한 내용으로 하면 되겠구나 했는데...
주어진 시간이... 1시간을 넘어.. 80분이라니!!
제94회 SW공학 Technical 세미나 (https://www.onoffmix.com/event/193725)
"음... 답이 없다...답이 없다.. 안 한다고 할까..." 급.. 후회;;;
기존 20분짜리 발표 자리를 4배 뻥 튀기를 해야 한다.
(▼ 아래) 기존 발표 자료
20page * 4 = 80page ???? => 페이지당 1분?? (속사포 불가능 ㅠㅠ)
(20page * 4) / 2 = 40page => 페이지당 2분!! (결정)
- 40 page 문서 만들기
- 페이지당 2분 이내로 발표하기
어랏.... 표지, 마지막, 인덱스... 3장 빼면... 37 page 네!?
좋아.... 6분은 Q&A
모름지기 수업과 강의는 조금 일찍 끝내는 게 미덕이지!! ㅎㅎ
"기존 문서" + "Agile" + "Scrum Framework" ... 또 뭐를 추가.... 할 게 없다!!
기존 문서에서 빠진 프로세스를 추가하고... 조금 더 세분화하면...
땋!!!
들어가기
p1. 아이스 브레이킹, 발표 계기와 참석자 분위기 파악, 주제 선정의 배경
p2. 인덱스, 스크럼 진행 순서에 따른 세부 항목 안내
p3. 회사 소개, SW 개발 전문회사를 통한 당위성, 프로젝트 하나하나 설명 (시간 좀 끌기)
p4. 사례가 되는 프로젝트의 소개, 제품의 특성에 따라 고객에게도 가치를 전달해보자
p5. 프로젝트 이력, 도출된 문제점과 해결하기 위해 노력한 항목들
p6. 고객도 우리와 같은 고민에 빠져있더라, 여러분의 문제이기도 할 수 있다.
p7. 쉬어가기, 전문 강사가 아님을 강조(무지개 실드), 우리가 고민한 내용을 보고 같이 고민해 보기를 희망함.
전략 및 사례 > Agile : 시간도 벌고 공감대도 형성해볼까?
p8. 애자일 원칙에 대한 이해와 구성원들이 갖춰야 할 자세. 우리의 원칙!!
p9. 스크럼 선택의 이유, 남들 다 사용하고, 회사에 도움받을 수 있는 존재가 있다는 이점!!
p10. 스크럼 프레임워크 소개, (https://www.scruminc.com) 항목별 자세한 영! 어! 소개, 굿!!
p11. 책에 나온 스크럼 장점, 폭포수 대비 당연한 이점, 우리에게 와 닿는 건 팀워크!! (난 스폰서가 될 수 없으니)
전략 및 사례 > a u Ready? : 우리가 도입을 위해 준비한 항목들
p12. 역할 정의, 각각 역할에 대한 정의, 우선순위는 합의가 아닌 협의!!
p13. 물리적 환경, Best 는 독립적 공간, 우리 조직에서 최대한의 배려는 모여 앉기
p14. 프로세스를 운영할 도구, 지라-컨플루언스 하나면 끝나는 것을... 애썼다.
p15. 구성원 모두가 합의한 헌장 배포, 신규 인력이 들어와도 바로 적응할 수 있도록 담아 뒀음
p16. 자기조직화, 가장 어렵고 가장 중요한 항목!! 우리도 1년 넘게 걸렸음. 이제 이 제품은 우리 것 내 것임!!
전략 및 사례 > Scrum : 우리는 스크럼은 약간 다릅니다.
p17. 스크럼 벗, 조직에 맞게 변형된 스크럼, 무작정 바꾸는 것이 아니라 이해하고 하나씩 제거/변형해야 함
p18. 우리가 잘할 수 있을까에 대한 고민, 2주 상당히 짧아요!!
p19. 우리 찾은 해결 Feedback!!!. 강조!! 또 강조!!! 핵 강조!!!!. 40페이지 URL 링크 타고 블로그 보면 좋아요!!
p20. Feedback 을 스크럼에서 어떻게 녹여낼 것인가?? 의사소통이 필요한 구간엔 명확한 피드백 요건을 정의
전략 및 사례 > Backlog : 유저스토리의 작성과 변화
p21. 유저스토리 구성 설명, 유저스토리 이름은 PO, 유저 스토리 상세화는 SM, 나머지 개발팀의 개발 항목과 완료 조건 명시, 모든 스토리는 서술형, 하나의 기능, 간결성 유지할 것!!
p22. 초기 유저 스토리(작년) : 원칙이 준하는 트렐로 카드의 운영
p23. 현재 유저 스토리 : 중첩되는 부분을 통합, 개발팀에 자유도를 줌. 완성된 모습만 잘 보여줘 봐~~
p24. UI 설계서의 변화(기능) : 유저 스토리 및 추적성 확보를 위한 ID, 가급적 한 장에 한 가지 기능을
p25. UI 설계서의 변화(UI) : UI 정책 관련된 부분 놓치지 말 것. 나중에 UI 컴포넌트 통일성이 무너짐.
p26. 요구사항의 추적 : 요구사항을 시스템에 등록하고 검색할 수 있도록 함
p27. 테스트 수행 및 관리 : 요구사항과 TC의 연결, 테스트 계획과 수행에 직접 사용할 수 있는 장점 다수~
전략 및 사례 > Sprint Board : 백로그의 이동에 중점!!!
p28. 우리의 스프린트 보드, 2주(80시간), SM의 명확한 스프린트 통제 진행
p29. 그루밍, 별도 시간을 할애한 독특한 그루밍 방식을 통해 요구사항을 명확하게 공유할 수 있음. 진행할 프로젝트의 범위 산정 및 프로젝트 시작 보고 수행
p30. 플래닝 미팅, 프로젝트 백로그에서 스프린트 진행할 업무 선정 및 파트가 합의, 스토리 포인트는 어려워서 배제하고 완료 일정을 정하여 범위 산정함. (어려운 건 질색)
p31. 데일리 미팅, 짧게 정해진 것만 돌아가면서 모두 말할 것. 경청하고 서로가 무엇을 하는지 알아야 함!!!
p32. 리뷰, Conversation 이 모두 완료된 카드에 대하여 QA가 Validation 을 진행. 실패하면 기술 부채로 개발자에게 떠 안겨줌. 부채가 많으면 부담이라 개발자 스스로 노력하여 해결을 함. 압박보다 더 잘하게 하는 좋은 방법
p33. 데모, 패스 건 실패건 개발된 항목을 고객에게 보여주고 맞는지 확인, 구성원들 본의 피드백이 공유됨. PO는 멍 때리지 말고 모든 것을 수렴하여 다음 백로그에 발전시켜야 함.
전략 및 사례 > Integration
p34. 어서 와 이런 건 처음이지?? 스크럼과 V 모델의 조합 본 적 있음?? 우리 스크럼은 테스트 V 모델은 만족하고 있다규~~ (깔끔하게 잘 만들었단 말이지 스스로 대 만 족)
마무리
p35. 보여주기가 아닌 우리가 필요한 애자일을 하고, 모든 단계에 품질 활동을 유념하세요.
p36. 구성원이 동의하는 우리만의 원칙!! 우린 8페이지에 정의되어 있음.
p37. 우리의 과제, 회고를 통해 도출되는 내용들, 코드 리뷰를 통한 제품 품질 강화, 스프린트 회고를 통한 한 발 빠른 프로세스 개선 시도
p38. 프로세스 개선, 사전 예방활동으로 시간 확보와 확보된 시간을 사용성 평가라는 효율적 사용
p39. 끗
p40. 참고 링크, 늘 공부하고 배우는 자세, 잊고 있더라도... 1년에 한 번은 보지 않을까요?
세미나 참석자 연령층이 다양했다.
한 가지 특이한 점은 우측은 시니어들이 좌측은 상대적으로 젊은 분들이 자리에 잡고 있었다.
문이 약간 우측으로 치우쳐져 있어서 동선이 짧은 쪽으로 갔을까??
물어보고 싶었지만... 그냥 넘어갔다.
몰입해서 그런지 75분 쉬지 않고 떠들었다. 목이 갈라졌다.
이론이 아닌 실무 사례이었기 때문일까... 조는 사람이 없다니;;;; (솔직히 1분 계심)
그리고... 남은 5분과 쉬는 시간 20분을 꽉꽉 채운 질의응답이 시작되었다. 목이 갔다. 완전 목소리가 안 나온다.
그만큼 질의 내용도 다양했다.
질문 펼쳐 보기
기억나는 질문이 많지 않다.... 아쉽다.... (아직 미숙하다)
Q1. 그루밍은 스프린트 기간에 하는 것 아닌가? (시니어A)
A1. 맞다. 하지만 2주의 스프린트 기간은 개발기간이 상당히 짧은 편이다. 그래서 상위 개념은 프로젝트에서 1주일 시간을 빼서 프로젝트에 대한 그루밍을 진행한다. 1주일이라는 시간은 상당히 넉넉하여 스프린트 플래닝 미팅의 시간의 단축과 스토리의 정제 작업이 원활해진다.
Q2. 스크럼을 도입해서 SW 품질이 향상되었는가? (시니어B)
A2. 정량적으로 측정해보지 않았다. 하지만 사전에 예방활동 및 명확한 완료 조건을 통해 개발의 완성도가 높아졌고 이로 인해 테스트 기간 단축 및 이슈들이 현저히 줄어드는 것을 볼 수 있었다. 그래서 품질이 좋아졌다고 생각한다. (사실 QA팀에서 이슈 분석을 통해 리포트를 하고 있는데.. 이 부분을 깜빡 잊고 대답을 못해서 아쉽다.)
Q3. 스크럼을 하면서 느낀 가장 큰 장점이 무엇인가? (시니어B)
A3. 우리가 느낀 가장 큰 장점은 팀워크가 좋아졌다. 자기 주도적 업무를 통해
Q4. 스프린트 기간 동안 QA 부하가 걸리지는 않는가? (시니어C)
A4. 스프린트 기간 동안 QA가 쉰 적을 본 적은 없다. QA가 하는 일이 가장 많기는 하다. 하지만 프로젝트의 QA이면서 고객이기 때문에 제품에 대한 이해도가 매우 높아 일처리가 빠른 것 같다. 스프린트가 끝나 통합 기간에 테스트 진행에는 품질팀으로부터 테스트 인력을 지원받아 회귀 테스트를 진행하여 업무 부하를 줄이고 있다.
Q5. 개발팀과 QA 비율은 어떻게 되는가? (시니어C)
A5. 개발 조직 100명 정도이고 품질 조직이 15명 정도 있다. 프로젝트당 3명 정도라고 볼 수 있다. 하지만 인력이 부족한 건 현실이다.
Q6. 개발 중인데 다음 단계부터 스크럼을 도입하고자 한다. 팁을 준다면? (주니어 A)
A6. 우리 프로젝트도 개발 중에 스크럼을 도입했다. 시작은 개발할 항목을 정했다면 명확한 완료 조건을 명시해라! 그리고 범위는 가능하면 작게 잡고 시작해서 점점 늘려가는 게 좋다.
Q7. 스크럽을 도입하는 중에 있다. 나중에 메일로 연락드리겠다. (시니어D,E)
A7. 네
Q8. 지라-컨플루언스를 어떻게 사용하는가? 느리지 않은가? (미들A)
A8. 우리는 여러 개 도구를 엮어서 사용하는 툴체인을 구축하였다. 각 제품의 특성만을 잘 활용할 수 있도록 하였고, 개발자 중 한 명이 각 제품에 대한 연동 API를 분석해서 툴 간 연동될 수 있도록 구축해 주어서 편하게 사용하고 있다. 지라-컨플루언스는 우리도 도입을 하기 위해 한 달 무료 서버 버전과 클라우드 버전을 사용해 봤다. 클라우드 버전이 확실이 느리긴 하지만 서버 버전도 빠른 편은 아니었다. 그리고 지라-컨플루언스는 워크플로우를 어떻게 구성하느냐에 따라 툴의 이점을 살릴 수 있다. 조직에 맞게 컨설팅받는 것을 추천드린다. 우리가 받았던 견적은 500만 원이었다.
Q9. SI 같은 프로젝트에도 적합하다고 생각하는가? (시니어F)
Q9. 이미 고객으로부터 개발 항목이 명확해져 있다면 폭포수가 성공률이 높다고 생각한다. 우리는 자사 서비스였기 때문에 개발 범위 및 우선순위를 우리가 선정하여 스크럼을 진행할 수 있었다.
Q10. 프로젝트 백로그 하나가 유저스토리 하나인가? (미들B)
A10. 백로그 하나가 유저 스토리가 될 수도 있고, 더 큰 에픽이 될 수도 있다. 1주일의 그루밍을 통해 프로젝트 백로그를 생성할 때 충분한 시간이 주어지기 때문에 완성된 유저스토리가 나오기도 한다. 그리고 추상적인 에픽은 스프린트 기간 동안 PO, 디자이너가 구체화 작업을 진행하게 된다. 그러면 다음이나 다다음 스프린트 플래닝 미팅에서 유저스토리화 작업이 진행되고 개발이 진행된다. PO와 디자이너가 같은 스크럼팀에서 움직이지만 반드시 같은 스토리 해결을 위해 일을 하지 않고 다음 업무를 진행할 수 있도록 한다.
Q11. 백로그의 우선순위는 어떻게 정하는가? (미들B)
A11. 우리는 스토리 포인트를 사용하지 않고 우선순위는 협의를 통해 PO가 정한다. 플래닝 포커해봤더니 어렵다. 개발 속도는 처리된 카드 수로 측정을 하고, 개발 기간이 긴 카드는 내부 테스트 개수를 참고하여 속도 계산에 반영한다.
.... 기억나면 추가해야지
애자일이 나온 지 20년이 지나도 관심이 끝이지 않는 이유는 뭘까??
과연 개발 방법론은 SW 개발에 필요한 것일까?
디지털 트랜스포메이션, 프로세스 개선... 다양한 용어들로 조직의 변화를 꾀하는 이유는 뭘까???
내 머릿속에는 애자일... 너는 우리나라 정서랑 좀 안 맞아!!라는 생각이 강하다.
- 태생이 수평 문화인데... 우리나라는 유교사상의 수직 문화
- 상호 존중이 기본인데... 우리나라는 라테는 말이야... 꼰대 문화
아직까지 IT는 X세대가 이끌고 있고 이들의 자라온 문화적 특성은 애자일의 태생과 반대라고 생각한다.
젊은 스타트업이 100억대, 1000억대 가치의 기업으로 급속 성장할 수 있는 것은 자라온 배경이 달라서가 아닐까??
지금의 기업들을 애자일하게 움직이게 하려면 대대적인 계몽이 필요하지 않을까?
그에 걸맞는 용어가 디지털 트랜스포메이션이 아닌가 생각해봤다.
애자일을 이해하고 상호 존중을 기반으로 한 의사소통이 SW 프로젝트 성공의 지름길이라 개인적인 결론을 내린다.
- the end
참고. 용어 정의 펼쳐보기
너 참 낯설다.
Conversation : 유저 스토리 구성 요소로 사용자 요구사항을 구현하기 위한 개발 TASK 로 PO와 협의된 항목들을 개발자가 입력한다. 트렐로에 체크리스트 형태로 작성되어 모두 체크가 완료되고 QA가 작성한 Confirmation 을 만족한다고 판단되면 Review 로 넘긴다.
Confirmation : 유저 스토리 구성 요소로 명확한 완료 조건을 명시한 항목이다. 보통 QA가 작성하는 TC와 일치한다. Confirmation 을 만족하지 못한 유저 스토리는 다시 개발로 넘어가 수정/보완 작업을 거치게 되고 만족한 유저스트리는 완료로 넘어간다.
Verification & Validation : 테스트에서 많이 쓰는 용어로 한국어로 보게 되면 뜻이 비슷해서 헷갈린다. V 모델에서 설명을 하면 쉽다. V 모델의 왼쪽이 QA가 Verification 활동을 하는 부분으로 정해진 프로세스에 따라 제대로 개발이 진행되고 있는지를 확인한다. 필요에 따라 산출물까지 확인 한다. V 모델의 오른쪽이 QA가 Validation 활동을 하는 부분으로 개발이 완료된 산출물이 잘 만들어졌는지 요구사항, TC 기반으로 유효성 확인을 진행한다.
제대로 하고 있냐? 잘 만들었냐? 이 두 가지만 기억하면 된다.
Grooming : 스프린트 진행 중, 스크럼팀에서 시간을 쪼개어 다음 스프린트에 처리할 백로그에 대한 정제 작업을 미리 진행하는 활동을 말한다. 우리는 2주라는 짧은 기간에 처리하기 힘들어 따로 1주일이라는 시간을 두고 정제 작업과 코드 리펙토링 등 정비 시간으로 활용을 한다.
'딴 생각하는 공대생 > 일상 ᕙ(•̀‸•́‶)ᕗ' 카테고리의 다른 글
| [기록] 2019 ICT 아이디어ㆍR&D 기획 공모전 후기 (0) | 2020.11.25 |
|---|---|
| 카카오페이 모바일 교통카드 서비스 이용기 (하루) (0) | 2020.11.24 |
| 턴테이블과 LP판 (0) | 2020.11.23 |
| 가족여행 (0) | 2019.04.03 |
| 점심시간_올림픽공원 (0) | 2019.04.03 |
