[SW개발 방법론] SW개발 방법론 수립 기법 [OMG 표준 ESSENCE] 2일차

SW개발 방법론 수립 기법 [OMG 표준 ESSENCE] 2일차

오늘은 3분정도 늦었는데, 평소처럼 위치정보 인식도 안되서 출석이 되지 않아 수기출석을 하였습니다. 

========================================  1  ========================================

[ 09 : 05 ~ 09 : 46 ] 

강의 시작 전 <2장 Practice의 이해 및 활용> 이라는 주제로 강의자료를 화면에 띄워두시고 신창섭 강사님께서 방법론의 개론에 대해 이야기를 하셨습니다.

우리나라의 경우는 확산이 늦어지고 있다고도 하셨습니다. 

essentialize : 기존의 방법론을 에센스의 표기법으로 표현을 하는 것 입니다. 

간단히 지난주 강의 들었던 내용에 대해 복습도 진행을 해 주셨습니다. 강의자료 6page!

엑티비티

기법

제품(Product)

경쟁력과 역량 (팀원, 진행자의 역량)

 위의 4가지는 방법론을 적용할 때 확인해야 할 요소라고 설명을 해 주셨습니다. 특히 4번째의 경쟁력과 역량, 즉 팀원의 능력이나 역량, Skill을 고려하지 않고 맨먼스와 단가등만 따져서 그것에 맞춰 넣는것은 알맞은 인원배분이 아니라는 정말 쉽고 간단하고 누구나 이해할 수 있지만 현업에서 관리자들이 하지 못하는 것에 대해 지적을 하셨습니다. 같은 방법론을 적용을 하더라고 위의 4번째 항목을 고려하지 않는다면 아무리 좋은 방법론도 무용지물이라고 하셨습니다.

강의자료 10~11을 총해서 표기법에 대해서 학습을 해 보았습니다. 

강의자료 19페이지에서는 새로운 Role을 정의하는 것을 보여주었습니다.

Use Case 2.0도 재미있다고 하시면서 소개를 해 주셨습니다. Use case기반의 에자일 방법론이 동작할 수 있도록 수정이 된 것이라고 하셨습니다. 

프렉티스를 어떻게 쪼갤것인가? 하는것이 오늘 수업의 핵심이라고 하셨습니다 또한 21페이지에서와 같이 프렉티스 식별은 관심의 분리가 핵심이라고 하셨습니다. 즉, 역할에 맞게 관심사항(업무사항)단위로 분리하는 것이 필요하다고 하였습니다.

========================================  2  ========================================

[ 10 : 00 ~ 11: 38 ] 

강의자료 23페이지부터 수업을 다시 이어가셨습니다.

SW를 알파로 한다면

아키텍쳐

빌드

테스트

등이 서브알파가 될 수 있을것이라고 하셨습니다.

24페이지의 스크럼 예시를 통해서 에센스의 입장에서 볼 때 에자일 방법론의 XP는 풀 메서드정도로 볼 수 있지만 스크럼(Scrum), 칸반(Kanban)등은 프렉티스나 하나의 액티비티 정도라고 하셨습니다. 

30페이지에서는 엑티비티 스페이스와 에자일 에센셜 카드의 엑티비티를 배치 해 보았는데 그러면 해당 카드의 엑티비티가 어느 엑티비티 스페이스의 엑티비티가 많은지, 또 반대로 어느 스페이스의 엑티비티가 부족한지를 확인할 수 있습니다. 

32페이지에 기업적용 사례를 보면 고객 부분보다 솔루션부분이 많은 엑티비티가 있는데 이러한 경우는 SI업체나 그러한 성향의 기업에서의 모습이고, 위쪽의 고객 부분이 보다 강하다면 솔루션 개발 회사일 수 있다고 하셨습니다. 

또한 32페이지의 엑티비티들을 프렉티스로 정의 해 보았습니다.

<간단히 프렉티스 개요 부분 정리>

알파 -> 커널의 메타

엑티비티 스페이스 -> 엑티비티의 메타

프렉티스의 조립을 하기 위해서는 기본요소 뿐 아니라 기법을 알아야 하고 패턴을 쓰면 된다

추정치는 전 세계의 방법론이 10만개정도 될 것으로 얘기 하였으며, 300여개정도의 프렉티스면 10만여개의 방법론을 표현할 수 있을 것이라고 할 수 있다고 했습니다.

www.omg.org 에 스펙에 관한 문서들을 모두 확인할 수 있으니 필요하면 받아보고, 강의를 잘 못 했으면 언제든 지적해달라고 하셨습니다. 

프렉티스 예시로 스크럼의 프렉티스를 보고, 스팩으로 확인을 해 보며, 또한 표준이다 보니 Sytnax를 가지고 표현하면 tool을 이용하며 Card로 결과물을 얻을 수 있다고도 하셨습니다.

11시쯤 쉴려고 했는데 수강생 두분이 질문을 하시면서 수업이 계속 되었습니다.. 생각보다 길어져서 집중이 잘 안되지만

하나의 적용 사례에서 어떻게 개발 방법론을 적용을 했고, 실제 적용했던 사례에서 프로젝트 진행 방법에 대해 자세한 이야기를 들을 수 있었습니다. 최소 6개월을 소요할 것으로 예상했던 프로젝트를 2달만에 끝낼 수 있었던 방법에 대해서 자세하게 이야기를 해 주셨습니다.

인원편성을 어떻게 하였는지, 기존의 방법론으로 한 작업에 대해 무슨 차이가 있었는지에 대해서도 확인을 할 수 있었습니다.

또 그후 몇몇 질문을 받아주셨습니다.

========================================  3  ========================================

[ 13 : 00 ~ 14 : 06 ] 

47~ 60페이지

점심식사 인사와 함께 실습을 진행 할 것이라고 하시면서 이론수업을 시작하셨습니다.

간단한 예로 개발자들에게 방법론을 적용하였을 때, 일반적인 개발자들이 결과를 내는 방식을 농담과 함께 이야기하셨습니다. 보통의 경우는 방법론 문서를 보고 따르는 것이 아니라, 결과물 예시나 양식을 보고 그에 맞게 결과를 자신의 방법으로 만들어낸다고 하셨습니다.

kanban와 scrum의 차이는 scrum은 스프린트에서 전력질주 하기 위해 만든 것이고, kanban은 도요타의 작업에서 따 온 것으로 한사람이 복수의 일을 하는 순간 일이 잘 되지 않는 문제를 개선하기 위해 만든 것으로 한 사람이 하는 일의 개수를 제한하는 것 입니다.

kanban은 당김(pulling) 방식으로 일을 하는 것이라고 하셨습니다. 스크럼이 보다 비 인간적인 방식이라고도 하셨습니다. 스크럼은 장기 프로젝트나 일당 근무 시간이 초과가 되도 비 효율적이라고 하셨습니다.

몇가지 설명을 더 하신 뒤 강의자료 60 page부터 있는 실습을 진행하였습니다. 우선은 개인으로 진행을 하고 나중에 팀으로 진행을 한다고 하셨습니다.

 60 page -> 개인 실습

========================================  4  ========================================

[ 14 : 20 ~ 16 : 30 ] 

강의자료 61, 62페이지에 해당하는 실습을 진행하였습니다. 조별활동으로 이번에는 원래 5명이던 팀원이 왜인지 모르게 3명만 참석을 하게 되었습니다.

========================================  5  ========================================

[ 16 : 30 ~ 17 : 27 ] 

실습을 진행한 내용을 조별로 발표를 하며 토론수업을 진행하였습니다.

D조부터 발표를 시작하였습니다. D-> A-> B -> C 순으로 발표를 하였습니다.

<발표 사진 자리>

먼저 각 조별로 프렉티스 분류를 한 이유나 프로덕트를 왜 어떤 알파의 프로덕트로 봤는지, 또는 옮길 수 없는지에 대한 이야기를 하였습니다.

저희 팀에대한 몇몇 수정사항을 적으면 요구사항과  소프트웨어시스템에 동시에 매핑되었는데 그러한 표기는 하지 않는것이 좋다는 이야기와 CBD라는 프렉티스틑 더 쪼개서 요구사항에 관련된 것을 다른 프랙티쓰로 쪼개는것이 더 낫다고 하셨습니다.

17:10쯤 모든 팀의 발표 및 토론이 끝났습니다. 

프랙티스로 나누는 모범답안에 대한 몇몇 강의자료에 없는 것들을 보여주셨습니다. 수강생들이 계속 핸드폰으로 사진을 찍자, 강사님께서 공유를 해 주겠다고 하셨습니다.

갑자기 강사님께서 강의하시는 PC가 재부팅이 되어 강제 휴식 후 수업을 진행하기로 하였습니다.

========================================  6  ========================================

[ 17 : 33 ~ 18 : 20 ] 

새로운 강의자료로 설명을 계속 해 주셨습니다.

아침에 늦은 사람들이 못 들었을 것이라고 하시면서 방법론 구성 요소에 대해 복습을 진행하였습니다. 강의자료 2일차 내용을 전체를 빠르게 훑어주셨습니다. 슬라이드 하나하나 보면서 설명을 해 주셨는데 생각보다 강의 종료 시간이 너무 늦어졌습니다. 

왜 방법론을 쓰는가? 더 나은 결과를 내고, 더 빨리 처리를 하는 것. 보다 경제적으로 프로젝트를 처리할 수 있도록 하는 것 이라고 하셨습니다. 기존의 방법론은 방법론 전문가들의 방법론이었다면 에센스는 그렇지 않다는 것을 이야기하셨습니다.

"방법론을 적용하지 않는 것이 더 낫다." 라는 말을 프로젝트가 끝날 때 마다 하는 것들을 보면 프로젝트 방법론을 잘 못 적용하였기 때문입니다. 또한 방법론을 적용하는 것 또한 팀원, 적용 대상이 되는 사람들의 역량을 파악하지도 않고 방법론을 적용하기 때문에 문제들이 생긴다고 하셨습니다. 

semat : www.semat.org

working area -> EDU. area -> 

Semat Korea : www.semat.-korea.org

회원가입 및 운영진 역할 문의 환영한다고 하셨습니다. 회원 가입후 같이 활동을 하자고도 하셨습니다.