스터디 그룹을 위한 패턴 언어에는 총 4개의 파트로 구성되어 있으며, 정신(Spirit), 분위기(Atmosphere), 역할 (Roles), 관습(Customs) 으로 나뉜다 .

스터디 그룹을 위한 패턴 언어 – Sprit 편 ‘Spirit(정신)’ 부분에서는 1. (숫자는 해당 패턴 번호를 의미한다.) 스터디를 왜 해야 하는지, 2. 토론의 중요성에 관해, 3. 집중할 수 있는 분위기에서 진행하기, 4. 꾸준히 하기, 5. 인맥형성 부분이 있다.

스터디 그룹을 위한 패턴 언어 – Atmosphere 편 ‘분위기’ 부분에서는 큰 부분에서부터 점차 세부적으로 기술하고 있으며, 6. 스터디의 지역적 장소 설정, 7. 장소의 분위기 설정, 8. 자리배열 방법, 9. 웹 페이지 의 순으로 기술하고 있다.

스터디 그룹을 위한 패턴 언어 – Role 편 ‘역할’ 부분에서는 각 구성원의 역할에 대해 기술하고 있는데 10. 리더는 열정적으로, 11. 사회자는 의욕적으로, 12. 참가자는 적극적으로 임하고, 13. 참가자는 또한 준비를 해 와야 한다. 마지막으로 14. 잘하는 사람을 적극 영입해야 한다는 것으로 설명되고 있다.

이 자료에 대한 모든 권한은 1차적으로 Joshua Kerievsky에게 있으며, 편역된 이 post의 권한은 소프트웨어 마에스트로 멘티였던 김민수, 장성환, 이원희, 채경훈 님에게 있습니다. 사용하실 분이 있으면, 위 네 분에게 문의해서 답신을 드리겠습니다.

습관  (Customs) 편

지금까지 스터디를 유지시키는 마음가짐, 여러 가지 분위기 조성, 그리고 규칙들에 대해 알아보았다. <<자조론>>으로 유명한 영국의 저술가인 새뮤얼 스마일스는 “습관은 나무껍질에 글자를 새긴 것과 같다. 그 나무가 커감에 따라 글자가 커진다.”라는 말은 남겼다. 좋은 습관 하나하나가 모여 스터디를 원활하게 돌리는 원동력이 될 수 있는 것이다.

이어지는 글들은 스터디를 위한 7가지 Customs(습관)에 대한 패턴들이다.

15. 토론을 시작하는 질문 (OPENING QUESTION )** 

Joshua Kerievsky는 대학 1학년 여름방학에 일리아드 오디세이를 읽고 독후감을 쓰는 숙제를 받았다고 한다. 밤낮을 가리지 않고 읽고 또 읽어 숙제를 마칠 수 있었는데, 당시 그 책은 전쟁에 관한 소설인줄 알았다고 한다.

학기가 시작한 이후 교수님께서 한 사람의 운명과 그 자신의 의지에 관한 질문을 던지셨다. 이 질문은 양을 치는 양치기가 언덕에 숨어서 전쟁을 보는 책의 장면과 연결이 되었다. 이 수업 이후 저자는 일리아드 오디세이를 운명에 순응하는 것과 개척하는 것에 대한 관점으로 바라볼 수 있었다고 한다.

사람들은 시작질문 없이 책을 읽으면 책의 진정한 내용을 알지 못하고 겉모양만 이해하게 된다. 하지만 이처럼 시작질문을 하게 되면 사람들의 관심을 끌 수 있게 되고 생각하기 어려운 부분들을 쉽게 접근할 수 있도록 해준다. 이 방법은 어려운 내용에 대해 공부할 때 더 유익하게 쓰일 것이다.

계속 읽기

7월 7일 있었던 제2회 대한민국 커뮤니티 데이에 발표한 동영상 강좌가 올라왔습니다.

안드로이드, 오픈소스  그리고 패턴에 대한 강좌입니다.

 

계속 읽기

스터디 그룹을 위한 패턴 언어에는 총 4개의 파트로 구성되어 있으며, 정신(Spirit), 분위기(Atmosphere), 역할 (Roles), 관습(Customs) 으로 나뉜다 .

스터디 그룹을 위한 패턴 언어 – Sprit 편

‘Spirit(정신)’ 부분에서는 1. (숫자는 해당 패턴 번호를 의미한다.) 스터디를 왜 해야 하는지, 2. 토론의 중요성에 관해, 3. 집중할 수 있는 분위기에서 진행하기, 4. 꾸준히 하기, 5. 인맥형성 부분이 있다.

스터디 그룹을 위한 패턴 언어 – Atmosphere 편

‘분위기’ 부분에서는 큰 부분에서부터 점차 세부적으로 기술하고 있으며, 6. 스터디의 지역적 장소 설정, 7. 장소의 분위기 설정, 8. 자리배열 방법, 9. 웹 페이지 의 순으로 기술하고 있다.

이 자료에 대한 모든 권한은 1차적으로 Joshua Kerievsky에게 있으며, 편역된 이 post의 권한은 소프트웨어 마에스트로 멘티였던 김민수, 장성환, 이원희, 채경훈 님에게 있습니다. 사용하실 분이 있으면, 위 네 분에게 문의해서 답신을 드리겠습니다.

역할  (Roles) 편

앞서 두  파트를 통해  스터디를 유지시키는 마음가짐, 여러 가지 분위기 조성에 대해서 알아보았다면, 이제는 스터디 팀원들 개 개인의  역할에 대해 설명하는 패턴언어이다.

‘역할’ 부분에서는 각 구성원의 역할에 대해 기술하고 있는데 10. 리더는 열정적으로, 11. 사회자는 의욕적으로, 12. 참가자는 적극적으로 임하고, 13. 참가자는 또한 준비를 해 와야 한다. 마지막으로 14. 잘하는 사람을 적극 영입해야 한다는 것으로 설명되고 있다.

계속 읽기

드디어 또 하나의 작품이 출간되었습니다.

아키텍트가 가 알아야 할 97가지에 이어 프로그래머가 알아야 할 97가지가 드디어 출간되었습니다.

여러 지인들이 의기투합해서 만든 작품으로, 오랜 시간이 걸려 드디어 빛을 보게 되었습니다. 정말 많은 분들이 고생을 해주셨구요.  10명이 넘게 번역 작업을 하느라 정말 고생이 많았습니다. :

특히 일정한 퀄리티가 나오도록 어려번 검수를 해주시느라 고생해 주신, 김수현 , 최현미 두 역자님에게 정말 감사드립니다.

저보다 더 많은 노력을 해주셔서, 최종 검수때  많이 편했습니다. 정말 두 분에게 고개 숙여 감사드립니다. 어떻게 보면 두 분의 이름이 1,2 역자로 먼저 나와야 하는데, 겸손하게 저에게 1역자를 주셔셔, 책임감이 크게 느껴집니다.

또한 베타리더 분들에게도 정말 감사드립니다.  오역을 많이 다듬어 주시고, 좀더 쉬운 용어로 바꾸는 작업을 해주셔서 이 분들이 아니였으면 정말 더 오래 걸렸을거 같습니다.

이전 소프트웨어 아키텍트가 알아야 할 97가지 보다 좀더 개발자에게 와 닿고 가슴을 적실 선배들의 조언들이 듬뿍 담겨 있습니다.  업계 최고의 아키텍트, 프로그래머, Agile 전문가들이 경험에 기반한 조언들입니다.

또한 특별 부록으로, 원서에는 없는 한국의 유명한 프로그래머들의 추가 에피소드가 실려 있습니다.

계속 읽기

지난 주말 (2012년 5월 20일) 코엑스에서 스마트 개발자 협회가 주관하는 글로벌 커뮤니티 써밋에  EVA 커뮤니티 연사로 발표를 했습니다.

먼저 이번 발표에 많은 도움을 준 소프트웨어 마에스트로 멘티인 오유환, 강미경, 김나래, 손윤정 4 멘티에게 감사드립니다.  이 4명이 아니였다면 이러한 좋은 자료는 나오지 못했을 겁니다.

프리젠테이션이 다루는 내용은 다음과 같습니다.

Android 이해

  • 구글이 꿈꾸는 Android의 미래 (Modu 사 특허 인수와 Android@Home)
  • Binder ( Broker 패턴 )과 Intent

오픈소스 그리고 사례

  • Simple Framework
  • Logcat보다 Microlog4Android
  • 불편하지 않은 화면 갱신 (Publisher-Subscriber)

분석 방법

  • Localytics로 사용자 행동 패턴 분석
  • STAN을 이용한 Android App 분석방법

이번 발표는 소프트웨어 마에스트로 멘토로 활동하면서, 멘티들과 같이 만들어 낸 작품입니다.   비록 여러가지 상황(취업, 학업등)으로 모든 멘티가 다 2단계에 진출은 하지 못했지만, 지금도 열정을 내뿜으며 같이 성과를 만들어내고 좋은 팀웍을 유지하고 있습니다.

여러분이 프로그래머라면, 여러분의 관리자나 동료 또는 사용자에게 지금 하고 있는 업무의 예측 결과를 알려 주어야 합니다. 그렇게 해야 그들이 목적을 달성하는 데 필요한 시간, 비용, 기술 등을 정확하게 이해할 것입니다.
정확히 예측하려면 예측에 대한 기술을 배우는 것이 가장 중요합니다. 첫째로, 예측이란 무엇이고, 그것이 어떻게 사용되는지 배워야 합니다. 이상하게 들릴 수 있겠지만,  많은 프로그래머와 프로젝트 관리자들이 예측이 무엇인지 정확히 알고 있지 못합니다.

다음에 나오는 프로그래머와 프로젝트 관리자의 대화는 전혀 이상한 것이 아닙니다.

  • 프로젝트 관리자: 이 기능을 개발하는 데 얼마나 걸릴까요?
  • 프로그래머: 한 달이면 됩니다.
  • 프로젝트 관리자: 너무 길어요. 일주일 안에 완료해야 합니다.
  • 프로그래머: 적어도 3주는 필요할 것 같은데요.
  • 프로젝트 관리자: 2주까지는 시간을 드릴 수 있을 것 같습니다.
  • 프로그래머: 네, 좋습니다. 2주로 하죠.

프로그래머는 결국 프로젝트 관리자가 만족하는 선에 맞춰 예측하고 있습니다. 하지만 이것은 프로그래머가 예측치를 제공한 것이기 때문에 프로젝트 관리자는 프로그래머
에게 책임을 전가할 것입니다. 이 대화에서 무엇이 잘못되었는지 파악하려면 예측, 목표, 커밋먼트라는 세 단어를 정의해야 합니다.

계속 읽기

저는 원하는 것을 말하지 않아도 될만큼 만족하고 있는 고객을 만나본 적이 없습니다.   대부분 그들은 엄청나게 세세한 부분까지 이야기 합니다.  문제는 고객들이 항상 모든 진실을 이야기하지 않는다는 것입니다. 그들은 보통 거짓말을 하지 않습니다만,  고객의 관점에서 말할 뿐 개발자의 관점으로는 이야기 하지 않습니다.  그들은 그들만의 용어를 사용합니다. 그들은 중요한 세부사항들은 생략합니다.  그들은 마치 여러분도 그들처럼 그 회사에서 20년동안 근무했다고 생각하는 것 같습니다.

거기에다가 많은 고객들이 처음에는 정말로 원하는 것이 무엇인지 모른다는 사실까지 더해집니다!   고객들중 일부는 ” 큰 그림”을 파악하고 있을 수도 있겠지만, 그들이 보고 있는 “큰 그림”에 대한 세부사항을 효과적으로 전달할 수 있는 경우는 흔치 않습니다. 다른 사람들은 전체그림에 대해서는 얕은 지식을 가졌을 수도 있지만, 그들이 원하지 않는 것이 무엇인지를 알고 있습니다.

그러므로, 무엇을 원하는지에 대한 전체의 진실을 여러분에게 말해주지 않는 누군가에게 어떻게 소프트웨어 프로젝트를 제공할 수 있겠습니까?  그것은 매우 간단합니다. 그들과 더 많이 접촉해야 합니다.

계속 읽기

이 분은 Object Mentor 의 리더이자,  Clean Code의 저자인 Bob 삼촌 (Uncle Bob – Robert C. Martin) 의 글이 “모든 프로그래머가 알아야할 97가지” 에 실려 있습니다.

저도 사실 뭔가 재미난 이야기를 해 줄거라고 했는데… 저희에게 너무나도 익숙한 객체지향의 중요한 원칙인   SOLID 의 S인 SRP를 이야기를 하셨네요.

익숙하지만 정말 중요한 원칙인 SRP 이야기를 다시 한번 들어보시길 바랍니다.

Single Responsibility Principle written by Uncle Bob

좋은 설계를 위한 가장 기본적인 원칙 중 하나는 다음과 같습니다.

동일한 이유로 변경되는 것들은 함께 모으고, 서로 다른 이유로 변경되는 것들은 분리시킨다.

이 원칙은 종종 단일 책임의 원칙(Single Responsibility Principle, SRP)이라고도 알려져 있습니다.   한마디로 말해서, 하나의 서브시스템, 모듈, 클래스, 또는 심지어 함수에 대해서도 한 가지 이상의 변경 이유가 있어서는 안 된다는 것을 의미합니다.

계속 읽기

12월 3일 있던 한국 커뮤니티 데이에서 김현종님이 발표한  Fearless Change 발표자료입니다.

현종님이 직접 조직에서 체험한 Fearless Change 이야기가 많은 도움이 되셨는지 모르겠습니다.

연차가 올라가면서 정치는 소프트웨어를 만드는데 아주 큰 영향을 미친다는 것을 다들 서서히 깨닫으시리라 믿습니다.

사람들의 성향을 파악하고, 그에 맞게 점진적으로 조직을 바꿔나갔던 현종님의 경험담이 잘 전달되었는지 모르겠네요.

계속 읽기

박현철 이사님으로 부터 정말 즐거운 메일이 왔습니다.

일전에 Meet the Architect라는 세미나를 진행해 주셨고, 정말 많은 가르침과 깨달음을 주셨던 박현철 이사님께서 Scrum 세미나를 진행해 주십니다.

산전 수전 다 겪으시고, 풍부한 컨설팅 경험을 가지신 이사님께서 Scrum 세미나라니. 단순히 스터디가 아니라,  현업의 목소리를 들려 주실 것 같습니다.

일전에 Meet the Architect 세미나로 감명을 받으신 분이라면, 한번 다시 찾아 뵙는 것이 어떨까요?

100명 선착순이니 서두르셔서 예약하셔야 될거 같습니다.

세미나  주제 : “Scrum 네~ 이놈!

부제 : “도()를 닦기 위한 Scrum인가? 프로젝트 성공을 위한 Scrum인가?” , 기존 방법론은 방법론이 나빠서 실패하고, Scrum은 사람이 나빠서 실패한다?”

“당신이 Scrum을 진정 좋아한다면, Scrum의 잠재적인 문제를 얼마나 고민했고, 실제 상황에서 이들을 극복하기 위해 얼마나 시도했고 발전시켜왔는가? 당신이 Scrum을 진정 가치가 있다고 생각한다면, Scrum으로 무엇을 했고, 어떤 성과가 있었는가? 도대체… 당신이 진정 Scrum을 좋아한다고, 가치가 있다고 말할 수 있는가?

<<세미나 등록하기>>

http://www.bitacademy.com/etc/semina_list.asp

  계속 읽기