생산성 향상은 과연 개발자 개개인의 능력에만 달려있는 문제일까요? 생산성 높은 툴, 언어, 프레임워크를 이용하는 것 이상으로, 팀플레이가 생산성에 미치는 영향력 역시 매우 큽니다.
생산적이고, 단결력 있는 팀을 만들기 위해선 어떻게 해야 할까요? 이 화두에 대한 전문가의 경험을 여러분과 함께 공유합니다.
팀 생산성 향상은 개발자 뿐만 아니라 프로젝트 관리자에게도 관심 있는 부분일 겁니다. 대부분의 패턴들은 소프트웨어 설계에 초점이 맞추어져 있습니다. 그러나 독특하게 조직구조와 협력을 위한 패턴들(“Capable, Productive and Satisfied : Patterns for Productivity”)이 PLOP 학회에서 발표 되었습니다.
여기서 소개되는 패턴들과 저의 부족한 경험과 지식을 엮어 팀 생산성 향상을 위한 패턴 이야기를 풀어보고자 합니다.
EuroPLOP
이번 포스트는 PLOP의 또 하나의 다른 종류인 EuroPLOP를 소개하고자 합니다.
PLOP 미국에서 세계 각지에서 열린다면, 각 대륙권으로 또 다른 PLOP 행사를 가지고 있습니다.
- ChiliPLoP (Hot Topic을 위주로 다루는 패턴 학회)
- EuroPLoP (유럽인을 위한 패턴 학회)
- KoalaPLoP (오스트렐리아인을 위한 패턴 학회)
- MensorePLoP (일본에서 열리는 패턴 학회)
- SugarLoafPLoP (라틴 아메리카인들을 위한 패턴 학회)
- VikingPLoP (북 유럽 사람들을 위한 패턴 학회)
어떻게 해야 패턴을 좀더 쉽게 공부하고 체득할 수 있을까요? 제가 강의나 Online을 통해 많은 분들이 저에게 질문을 하십니다.
제가 집필중인 “미워도 다시 보는 패턴 이야기”라는 서적 안에 패턴서적의 빌드오더를 적어놓았지만, POSA2와 Framework Design Guideline 이 두 서적의 편역 작업이 급해 집필이 무한정 연기되었습니다.
이 책이 나올때 까지 기다리세요!! 라고 말하면 너무 장사치 같겠죠. 🙂
이번 POST를 통해 부족하지만 제가 걸어온 그리고 걸어갈 패턴의 길을 알려드리고자 합니다.
기러기가 왜 V 자로 날아가는지 아십니까? 이것은 아주 머나먼 곳으로 여행하기 위한 그들간의 아름다운 팀플레이 입니다.
제일 앞에 한마리의 기러기가 선두가 되어 날아가면, 그 뒤에 여러 기러기가 붙어서 날아 갑니다.
그 이유는 상승 기류를 최대한 이용하기 위해서입니다.
제일 앞에 날아가는 선두 기러기는 힘들지만, 그 뒤에 있는 기러기는 상승 기류를 이용해 아주 적은 힘으로 날아갈 수 있기 때문입니다.
그리고 주기적으로 선두 자리를 돌아가며 서로의 힘을 분배하며 날아가기 때문에, 힘을 아끼며 비행할 수가 있죠.
요즘 소프트웨어가 갈수록 거대해지면서 소프트웨어 통제에 대해 많은 애기를 들을수 있습니다. 그리고 소프트웨어 통제를 들어보신 분이라면, xDepend 라는 툴은 한번쯤 들어보셨을 겁니다.
이번 post는 아키텍쳐 설계시 dependency는 무엇이고 어떠한 종류가 있는지 설명하고, dependency를 관리할때 유용한 Layering과 xdepend 툴에 대해서 소개해 보는 시간을 가지겠습니다.
의존성 (dependency)을 어떻게 관리하느냐에 따라 여러분이 가진 시스템이 쉽게 확장가능한지 (변화에 쉽게 대처 가능한지)를 파악할 수 있으며, 이러한 추세를 반영하여 요즘 쉽게 패키징 할수 있는 단위로 시스템을 구축하는 것에 대해 많은 연구가 진행되어지고 있습니다.
지식을 공유한다는 것은 매우 가치 있는 것입니다. 비록 부족하지만 작은 것 하나 하나 나누다 보면, 작은 것들이 모여 풍성한 지식이 되어, 여러가지 보람을 느끼게 됩니다.
이러한 것이 조그만 저와 저희 팀들의 지식 나눔의 이유 였습니다
하지만 가끔 저와 저희 팀들의 지식의 부족함으로 인해, 실수로 인해 잘못 지식을 전달할 때가 있습니다.
김지선님이 번역해 주시고, 저희 스터디 팀이 몇개월동안 노력해 감수(감역)작업을 펼쳤던 POSA1 권에 대한 오역과 부드럽지 않은 번역으로 인해 승차감이 불편하시다는 피드백을 주셨습니다.
아키텍트! 참으로 열망하고 있고 능력을 갖추기 위해 노력하고 있습니다.
아키텍트와 관련된 여러가지 글을 적었지만, 과연 우리에겐 아키텍트의 롤이 언제쯤 주어질까요? 이런 수동적인 상황을 깨는 좋은 만남을 가졌습니다.
많은 고심과 새로운 길을 개척하기 위해 노력하는 도중에, 지인의 소개로 System Architect를 만났습니다. 제가 머리속에 그리고 있는 아키텍트와는 전혀 다른 모습이었습니다.
개발자 출신이시며, 45세라는 나이, 솔로, 수많은 실패를 경험한 그분에게는 온실속 화초같은 생활을 하는 저에게 많은 가르침을 주셨습니다.
국내 환경에 적합한 생존 전략을 구사하시는 System Architect셨습니다.
4시간동안 그분의 열변과 경험을 전달해 주셨고, 느낀바를 여러분과 공유하고자 합니다.
Framework Design Guideline의 저자인 Krzysztof Cwalina의 TechED 2007 Framework Engineering 온라인 세션을 듣고 토론회를 가졌습니다.
편역을 하기전에 Framework 에 관해 배경지식을 쌓고, Paper Meeting 행사를 위한 가이드라인을 만들고 공유하기 위한 목적도 있었습니다.
Krzysztof Cwalina는 실제 .NET Framework를 설계한 분으로, 그의 경험을 책을 통해서 공유했을 뿐만 아니라, FxCop 이라는 툴을 이용해 VS.NET 내부 개발자들의 코드 품질을 검증하는 시스템을 외부로 공개하고 알린 분이기도 합니다.
Framework Engineering은 TechED2007 Europe 에서 발표한 세션으로 원래 일반인에게는 비공개이나, 고맙게도 자신의 블로그를 통해 공유해 주시고 계십니다.
아키텍트가 되기 위해서 우리에게는 어떠한 덕목이 필요할까요?
2007년 10월에 소프트웨어 아키텍쳐 이론과 실제 (Software Architecture in Practice)의 저자인 Rick Kazman이 한국을 방문해 ATAM에 대한 강연을 하였습니다.
세미나가 마친후 어떤 분이 “당신과 같이 휼룡한 아키텍트가 되기 위해서는 어떠한 소양과 지식이 필요한지 설명해 주시겠습니까?” 라는
질문을 했고, 이에 대한 멋진 답변을 해 주셨는데 제가 알고 있는 지식을 덧 붙여 여러분과 함께 공유하고자 합니다.
Architecture 101 