애자일 14

Azure Devops - 스크럼 테스크 관리, 빌드, 소스코드 리파지토리, 테스트툴

Azure Devops 조대협 (http://bcho.tistory.com) 페이스북 타임라인을 보다가. “Azure Devop가 나왔는데. JIRA 따위는 꺼져버려.." 라는 말이 있어서 몬가 궁금해서 살펴봤는데 이거 정말 물건이다. MS가 요즘 많이 변하하고 있다고 들었는데, 정말 잘 만든 제품인듯 Devops라고 해서 Monitoring,Logging쪽 제품으로 생각했는데, Task management, 부하 테스트, git repo & 빌드, 빌드 파이프라인, 웹테스트 툴 등이 들어있는데, 전반적으로 정말 좋은듯. 예전 IBM의 Jazz 플랫폼과 컨셉은 비슷한데, UI나 기능이나 반응 속도나 압권이고 거기다가 일부 플랜은 무료다!! 나 같은 개인 개발자(집에서는)에게는 딱이 아닐까 싶다. 대충 후..

ALM 2019.05.15

사람이 최대한 관계를 유지할 수 있는 숫자는 150명이다. (Dunbar's law)

Dunbar’s law - 인간의 인맥은 150명 까지 가능하다. 조대협 (http://bcho.tistory.com) 어제 API 아카데미의 Amunsen의 강의중에, MSA 아키텍쳐에서 적절 팀 사이즈에 대해서 재미있는 학문적인 근거가 언급되어서 기록해놓는다. 던바의 법칙 (Dunbar’s law)이라는 건데, 던바는 옥스퍼드 대학의 인류학자로 인간의 사교성을 연구하던중, 인간이 맺을 수 있는 인간관계의 수에 대한 연구이다.http://terms.naver.com/entry.nhn?docId=2847498&cid=56774&categoryId=56774 이 연구에 따르면, 인간관계에 대해서 사람은 친밀도에 대해서 크게 4가지 단계로 인간관계가 분류된다.Intimate friends 5Trusted f..

비지니스 2016.02.25

MSA의 중복 개발에 대한 단상

MSA의 중복 개발에 대한 단상 조대협 (http://bcho.tistory.com) 어제 우연한 기회로, API Academy 세미나에 다녀왔습니다.발표자는 Mike Amundsen 이라는 분으로, CA의 API 아카데미의 일원이며, OReilly 출판사를 통해서 REST API에 대한 저서를 집필한 분이기도 합니다.http://www.oreilly.com/pub/au/1192 API 아카데미였지만, 결국 MSA와 조직 문화 소통으로 수렴되는 내용이었습니다만, MSA 에 관련하여 재미있는 접근이 있어서 남겨놓고자 합니다. 예로 든것중의 하나가 API를 외부용, 내부용, 그리고 특정한 파트너용 3가지로 나누어서 접근을 하였는데, 이 접근 방식보다 특이했던 것이 구현의 주체입니다. 일반적인 생각으로는 유사..

Feature team에서 길드 모델을 이용한, 기술 거버넌스의 확보방안

Feature team에서 길드 모델을 이용한, 기술 거버넌스의 확보방안 조대협 (http://bcho.tistory.com) 지난번에 고민했던, Feature team model에 대해서 조금더 리서치를 해보니, 음원 서비스를 제공중인 Spotify가 이 모델을 조금 더 발전 시켜서 Squad & Tribe 라는 모델을 사용하고 있다. Feature team 모델의 문제점 중의 하나가, Feature 단위로 팀을 나누다 보니 발생하는 문제가, 같은 기술을 쓰는 엔지니어가 다른 팀에 속하기 때문에, 기술에 대한 통제(거버넌스)나 기술 교류가 약해질 수 있는 문제가 있다. 이러한 문제를 해결하는 방법으로는 길드의 개념을 사용한다.길드는 같은 기술을 사용하는 사람들의 모임으로, 기술적인 리더쉽을 위해서 각 ..

ALM/애자일 2015.09.14

애자일 팀 모델에 대하여

애자일 팀 발전 모델에 대하여Functional team, Product Team, Feature Team조대협 (http://bcho.tistory.com) 개요 관리자(CTO)역할을 맏으면서 가장 고민중에 있는 것 중 하나는 팀을 어떻게 모델하여 최적화된 개발팀 구조를 가지느냐 이다.근래의 개발팀의 모델은 애자일 사상에 영향을 받아서 작고, 독립적인 팀의 모델로 진화하고 있으며 대략적인 특징은 다음과 같다.· Self organized· Cross functional· 2 pizza team Cross functional 모델은, 하나의 팀 내에서 기획부터 디자인,개발 및 테스트를 모두 진행할 수 있는 팀 모델로 팀 안에 앱,프론트,백앤드 개발, 기획,테스터와 같은 모든 역할을 하나의 팀내에 모두 가..

ALM/애자일 2015.09.08 (1)

플래닝 포커를 이용한 프로젝트 일정 산정

플래닝 포커를 이용한 프로젝트 일정 산정조대협 (http://bcho.tistory.com) 프로젝트 진행을 하거나, 애자일 방법론 기반으로 스프린트 기반의 프로젝트를 진행할때도 항상 문제가 되는 것이, 일정 산정이다. 먼저 정확한 일정 산정이 어려울 뿐더러, 프로젝트를 진행하는 외부의 인원이 보기에 일정 산정의 근거가 약해서 “왜 저일이 왜 그렇게 오래 걸려요?” 라는 등의 비난을 받을 수 가 있다. 그래서 정확한 일정 산정 프로젝트 일정 관리와 함께, 팀의 일정 산정에 대한 정당성을 확보하는 것 두 가지의 목적을 가지고 있다. 그러나 이러한 일정 산정은 불확실한 미래를 예측하는 작업이기 때문에 매우 어려운데, 이러한 일정 산정의 좋은 기법의 하나로 “플래닝포커(Planning Poker)”라는 기법을..

ALM/애자일 2015.07.22 (2)

스크럼 방법에 대한 회의와, FDD 방법론에 대한 고민

스크럼 모델에 대한 고민 요즘 애자일 스크럼 방법론에 대한 회의를 느끼고 있습니다.가장 널리 사용된다는 스크럼 방법론이고, 예전 몇몇 회사에서도 톡톡히 재미를 봤던 방법론이기 때문에 새로운 팀에 스크럼 방법론을 적용하기 위한 시도를 하고 있습니다. 그런데, 이 스크럼 방법론이 동작하지를 않습니다.스크럼의 전제 조건인 즉슨, 스크럼팀이 Product(상품/서비스) 단위로 움직인다는 개념을 가지고 있습니다.즉 특정 기능이나 모듈에 대해서 특정 팀이 계속해서 오너쉽을 가지고 개발을 진행하는 모델로, 이렇게 하면, 상품에 대한 경험이 지속적으로 쌓인다는 장점이 있습니다. 그리고 기획자 (Product Owner : PO)가 팀 내에 있기 때문에 궁극적으로는 각 서비스가 독립적으로 스스로 기획 부터 개발, 테스트..

ALM/애자일 2015.07.13 (1)

빅데이타 팀을 이루기 위해서 필요한것 3가지

빅데이타 팀을 이루기 위해서 필요한것 3가지조대협(http://bcho.tistory.com) 요즘 모가 그렇게 바쁜지, 블로그 업데이트를 한참 못했습니다.모처럼 주말에 시간이 있어서, 그간 정리한번 해야지 했던 내용들을 올려봅니다.먼저 빅데이타 팀에 대한 이야기인데, 아래 그림은 빅데이타에서 유명한 그림입니다. 데이타 사이언티스트가 가져야할 그래프로 표현한것인데, 제가 해석하기에는 데이타 사이언티스트 보다는 빅데이타 팀이 가져야할 영역으로 보입니다. 각 영역별로 설명을 해보자면 1.Math & Statistics (수학과 통계학에 대한 지식)빅데이타 처리는 수학과 통계학적인 지식을 전제로 합니다. 데이타의 상관관계를 분석하거나 데이타의 특성을 파악하는 등의 기술은 수학 특히 통계학적인 지식을 필요로 합..

빅데이타 2015.01.12

프로젝트 인셉션에 대해서

프로젝트 인셉션에 대해서 원글 : http://www.infoq.com/articles/project-inception-meeting 프로젝트 시작전에, 프로젝트 팀에 대한 alignment를 하기가 어렵다.alignment란 팀이 같은 프로젝트에 대한 배경과 목표를 이해하고, 주요 기능과 일정, 그리고 인원별 역할등 전체적인 프로젝트의 컨텍스를 이해하는 것인데,일반 개발자들은 비지니스쪽 인원을 만나기 힘들 뿐만아니라, 상위 임원들의 방향과 생각을 중간 메니져를 통해서 듣기 때문에, 내용 전달이 부족하거나 오역 되었을때, 팀의 alignment가 제대로 되지 않는 경우가 많다.이런 문제를 해결하기 위해서, 하루 full day로 프로젝트 시작하기 전에 공유하는 회의를 갖는데 이를 프로젝트 inceptio..

ALM/애자일 2014.08.13