블로그를 Jekyll과 Github.io 기반으로 옮기다 ⊙ 삶의 작은 일들

지금까지 즐겨 사용하던 많은 인터넷 서비스들이 문을 닫았다. 개인이 운영하던 오픈유어북에는 수백개의 책을 등록해놓고 메모를 해놓았었는데, 어느날 알림도 없이 서버가 사라져버렸다. 그리고 오픈마루에서 운영하던 스프링노트는 미리 서비스 종료 공지를 했었지만 기간 내에 백업을 받아두지 못하는 바람에 담아놓았던 수십개의 글들을 날려버렸다. 그 이후로는 웬만하면 서비스에는 중요한 것들을 담아놓지 않으려고 한다.


개인적으로 사용하고 있는 위키는 데이터베이스를 사용하지 않고 파일만을 사용하고, 데스크탑 서버 모드도 지원하기 때문에 보관이 용이하다. 로컬에서 서버를 띄워서 사용하다가 모바일 기기에서도 사용하기 위해 서버를 셋팅해서 올려두었지만, Dropbox에 싱크를 해놓고 있다. 서버가 사라져도 그대로 다른 서버에 올리거나 로컬에서만 사용할 수 있게 되어있다.


이렇듯 한 서비스에 종속되기보다는 데이터의 이동성(portability)을 중요하게 여기게 되었다.


2003년부터 이글루스 서비스를 사용해오던 블로그도 언젠가 적당한 도구를 사용해서 옮겨야지 하고 있었는데, 문득 기회가 생겨 Jekyll과 github.io를 사용해서 만들어보았다. 마침 작년부터 손에 익혀 사용하면서 매우 만족해하는 Emacs와도 잘 어울리는 구성이라서 더욱 마음에 든다. 아직은 Org-mode와 연동을 하지는 않았지만, 언젠가 또 기회가 되면 Org-mode와도 연동을 해놓으면 좋을 것 같다. Org-babel과도 연동하면 아주 훌륭한 환경이 될 것 같다.


처음에는 예전 이글루스 블로그 글을 모두 옮겨오는 작업부터 하려다가, 너무 일이 커질 것 같아 가볍게 접근해야지 하는 생각을 했다. 일단 최근 글 몇 개를 옮겨두고, 앞으로 올리는 글은 Jekyll을 사용해서 옮길 수 있도록 해놓고 나서, 기존 글을 옮겨오는 작업은 시간이 될 때 해야겠다.


(일단은) 새 블로그 주소는 http://toracle.github.io 이다. 나중에 AWS S3에 기만해서 custom domain에 붙이게 될지도. 그래도 그 때는 이전하는 수고가 훨씬 줄어들겠지.


Project Retrospectives - Chap 2. Anatomy of a Retrospective: A Case Study ⊙ 전공노트

Norm Kerth의 Project Retrospectives 2장 정리

Chapter 2. Anatomy of a Retrospective: A Case Study


이 장은 프로젝트 회고의 실제 사례를 살펴보면서 회고가 어떤 것인지 알아본다. 이 장은 저자인 NormKerth의 홈페이지에도 공개되어 있다.

회고를 준비하기 위해서, 각 참가자를 미리 인터뷰했다. 그 결과로, 매니저 그룹과 개발자 그룹이 각자 걱정스러워하는 부분이 어떤 것인지 파악했다. 회고 계획을 짜기 시작했다. 계획은 짜지만, 현장 상황에 따라서 얼마든지 바꿀 수 있다. 그리고 그렇게 하기 위해서 일부러 촘촘한 계획은 짜지 않는다. 일단은 다음과 같이 계획을 짰다.

  • 도입
    • 목표: 공동체가 진행자를 편안히 느낄 수 있도록 돕고, 프로젝트를 리뷰한다는 것을 편안히 느낄 수 있게 한다. 참가자들이 중요하다고 생각하는 것을 표현할 수 있도록 환경을 조성한다. 프로젝트가 성공적이었음을 일깨운다. 왜냐면 여러 장애물들이 있었지만 제품을 무사히 공급했기 때문이다.
    • 접근법: 도입에 적절한 활동을 한다 - ex. "Define Success" Exercise, "Create Safety" Exercise, "Artifacts Contest" Exercise
  • 중간
    • 목표: 중요한 것들을 학습할 수 있도록 프로젝트를 리뷰한다. 팀 멤버들간에 손상된 관계를 복구한다. 이처럼 대단한 일을 해내는데 들여야 하는 대가를 인식한다.
    • 접근법: 적절한 활동을 한다 - ex. "Develop a Time Line" Exercise, "Mining the Time Line for Gold" Activity, "Passive Analogy" Exercise, "Repair Damage Through Play" Exercise
  • 마무리
    • 목표: 다음 프로젝트가 더 성공적이기 위해서는 어떤 장기적인 활동이 필요한지 결정한다. 이 조직이 리서치 중심보다는 제품 중심으로 옮겨가기 위해서는 어떤 대안 행동을 해야 하는지 확인한다.
    • 접근법: 마무리에 적절한 활동을 한다 - ex. "Cross Affinity Teams" Exercise, "Making the Magic Happen" Exercise

인상적이었던 부분은, Artifacts Contest Exercise였다. 각자에게 이번 프로젝트에서 중요한 유물이라고 생각되는 것을 가져오라고 해서 그것을 모아놓고 이야기를 하는 것인데, 다양한 이야기가 나올 수 있을 것 같다. 예제에서는 바퀴벌레 살충제를 가져온 한 엔지니어의 이야기가 나온다. 한참 버그를 잡고 있을 때였는데, 누가 자기 책상에 살충제 통을 놨단다. '이게 뭐지?' 하고 집어들었는데, 그 한쪽에 "고맙습니다"라는 쪽지가 붙어있었다더라. 그 사람이 살충제 통을 들고 그 에피소드를 이야기하자, 청중 중에서 누군가가, "내가 줬던 것은 아니지만, 지금 이 말을 해주고 싶네요. 정말 수고했어요."라고 말을 꺼내자, 다른 사람들도 맞장구를 치며, 갑자기 전체 그룹이 그에게 박수를 쳐줬다고 한다.


Appreciative Inqury에서도 서로가 에피소드를 이야기하면서 다양한 사례들, 각자가 바라보거나 경험했던 다양한 면면들이 끄집어내어지는 것을 중요하게 이야기하는데, 여기서도 이런 저런 에피소드들이 나오게 하는 것이 좀 비슷하다. 도입 부분은 이런 저런 에피소드로 시작하는 것이 좋은 것 같다.


중간 활동으로는 타임라인을 그리고, 프로젝트를 4개의 계절로 큼직하게 구분하여, 각 시기에 있었던 일들을 적게 했다. 그걸 또 작은 그룹으로 나누어서 그룹별로 논의해서 적게 했다.


첫째날과 둘째날의 활동들을 거치면서 사람들은 피곤하지만 자신의 의견을 솔직하게 이야기하는데는 편안해졌다. 마지막 활동을 하면서 사람들은 진심에서 우러나오는 말로, "다시는 그렇게는 하지 않겠어! (Never again!)"라는 다짐을 한다.

회고는 구성원들이 갈 필요가 있다고 하는 곳은 어디든지 간다. 퍼실리테이터의 역할은 그들이 그곳에 도착할 수 있도록 돕는 것이다. 다음 것들을 활용해서 말이다:

  • 과정을 관찰하고 인도하는 것을 통해
  • 모두의 의견을 들을 수 있도록 기회를 제공하는 것을 통해
  • 모든 사람의 의견과 프라이버시를 존중하는 것을 통해
  • 건강한 상호작용을 위한 가이드라인이 무엇인지 구성원들이 발견할 수 있도록 돕는 것을 통해
  • 그들이 반응할 때에는 기꺼이 감정을 다루는 것을 통해

어떤 퍼실리테이터는 회고에서 감정을 다루는 것을 꺼려하는데, 그렇게 해서는 마법이 일어나게 하기가 어렵고, 효과가 낮아서 회고가 끝난 후에 시간낭비였다는 인상을 받기 쉽다.

숙련된 퍼실리테이터는 많은 목표를 달성해야 한다.

  • 커뮤니티 내에 신뢰를 구축한다.
  • 어려운(difficult) 이슈를 탐색하도록, 인도적이고, 돌보고, 효과적인 방법으로 돕는다.
  • 반드시 관리자가, 지배하기보다는 참여하고 기여하고 배우도록 확실히 한다.
  • 무엇이 진짜 이슈인지를 그룹이 이해하도록 돕는다.
  • 팀 멤버들이 합께 일하는 더 나은 방법을 찾도록 돕는다.

Project Retrospectives - Chap 1. Introduction to Retrospectives

Preface

but sometimes he feels that there really is another way, if only he could stop bumping for a moment and think of it.

If we would only take a moment to stop and think of alternative ways to proceed, I'm sure we could find better ways to do our work.

The reason for this is that a well-run retrospective can help members of a community understand the need for improvement, and motivate them to change how they go about their work. The community designs the changes, since it knows best how to identify, organize, and give priority to the problems to be solved. Owning the changes helps the community become the master of its software process.

Chapter 1. Introduction to Retrospectives


"(Humans,) They hope that even if they do things that didn't succeed before, that by doing them the same way twice, they will get different results."

Owl is wise, but the pigs do not share his wisdom - the learning that comes from experience. Without this type of learning, most creatures are in danger of reliving earlier experiences - landing back in the swamp time after time.

경험은 중요한 학습의 재료이다. 하지만 잠시 멈춰서서 그것을 숙고해보지 않는다면, 재료가 저절로 숙성되지는 않는다.


Instead, they believe that what worked so well in one situation is the perfect technology to use in all their engineering efforts, whether they are building a house or an ark.

The pigs, like so many of us in the software engineering field, are missing the bigger picture.

I call this The Law of Wisdom Acquisition: 'It is much easier to identify another's foolishness than to recognize one's own'

This law suggests that it is not natural for us to stop, reflect, and learn from our software projects.

The act of reflecting on my just-finished project is not naturally a high priority.

회고하는 것은 자연스럽게 되지 않는다. 다른 할 일도 많기 때문에 우선순위가 밀린다. 때문에 일종의 '의식'으로 미리 정해놓는 것이 좋다.


The Need for Ritual

It should involve everyone associated with the project. One person can not know the whole story of the project; one individual's reflection can only bring about small-picture learning.

This big-picture wisdom comes from our ability to understand the relationship between an individual's work and that of the entire team. We need to tell our piece and see how it helps make up the whole story.


Prime Directive for a Retrospective

For a retrospective to be effective and successful, it needs to be safe. By "safe," I mean that the participants must feel secure within their community - to discuss their work, to admit that there may have been better ways to perform the work, and to learn from the retrospective exercise itself. Safety must be developed and maintained.

Part of being safe means knowing that there will be no retribution for being honest (such as being given a negative evaluation during the next performance review). Trust must be established and maintained during a retrospective.

반드시 회고 이전에는 사람들이 회고 공간을 안전하게 느끼도록 관리해야 한다. 그래야 사람들이 솔직해지고, 회고를 통해 배울 수 있다.

A method for expressing "unsafe" ideas during the retrospective needs to be established. To begin building safety and trust, the facilitator must communicate the prime directive for all retrospective rituals: KerthPrimeDirective

Regardless of what we discover, we must understand and truly believe that everyone did the best job he or she could, given what was known at the time, his or her skills and abilities, the resources availables, and the situation at hand.


The Darker Side of Retrospectives

Complaint energy is tricky to handle. The message in the complaint is worth listening to, but the packaging of the complaint can harm the learning process.

사람들은 비난에 익숙하다. 또한 한 번 비난의 분위기가 형성되면, 정직하게 자신을 돌아보고 그 분위기를 깨닫고 빠져나오는 사람도 적다. 안전하지 않은 상태에서 진행된 회고는, 상어떼에 물어뜯기는 상황이 된다.

Streetlights and Shadows 요약 정리


Streetlights and Shadows - 18, 19장

== 18장. 의사결정의 잘못된 10가지 믿음 (Reclaming our minds) ==

# 페이지 첫 장의 총 정리 표. 스포일러가 될 수 있어서 블로그에서는 제외했습니다. :-)

지금까지 논의한 목적은 그 주장들에 대해서 비판적으로 평가함으로써, 그 주장들을 더 잘 이해하고 그 주장들이 적용되지 않는 상황에 대해서도 이해하며, 그 주장들 때문에 우리가 어떻게 곤경에 빠질 수 있는지를 이해하고 우리 자신에 대해서 더 완전하게 이해할 수 있도록 만드는 것이다. - p. 440

우리는 직관적인 사고와 분석적인 사고 둘 다 사용한다. 심리학 연구자들은 주로 숙고 형태의 사고에 대해서 연구한다. 그 결과 우리는 직관적인 사고에 대해서는 그만큼 많이 알지 못한다. 그리고 사람들이 복잡하고 모호한 상황에서 어떻게 사고하는지에 대해서도 그만큼 많이 알지 못한다. - p. 445


== 19장. 당신의 경험은 답을 알고 있다 (Getting Found) ==

어둠 속에 있을 때 우리는 밝은 가로등 불빛 아래서와는 다르게 생각하고 행동한다. 우리는 정확하게 목표를 찾아가기보다는 방향 감각을 활용해서 길을 찾는다. - p. 446

우리는 어둠 속에서 적응형 의사결정을 하기 위한 열쇠를 찾아야 한다. 우리는 사람들이 '복잡성', '까다로운 문제', '암묵적 지식을 필요로 하는 과업'에 직면했을 때 사고하는 방법을 이해해야 한다. 이 세 가지 주제가 이 책의 각 장의 중심 내용이다. - p. 446

우리가 직면하는 가장 큰 도전은 복잡하고 예측 불가능한 상황이다. - p. 447

그러나 복잡한 상황에서 우리는 대개 목표를 미리 설정할 수 없다. 목표는 일을 하는 도중에 확립되는 것이다. 우리는 일을 해나가면서 시행착오를 통해 배운 것들을 토대로 목표를 명확화하고 재설정해야 한다. - p. 448

전문가를 걸어 다니는 백과사전으로 보는 일반적인 관점과는 반대로, 그들을 탐지기로 간주하는 게 더 낫다. 그들은 보통사람들이 볼 수 없는 단서들을 알아차리는 능력을 키우기 위해 오랜 시간을 투자해왔다. 그들은 우리들 대부분이 식별할 수 없는 것을 식별할 수 있다. - p. 449

이제 길 찾기를 다른 관점에서 생각해보자. 즉 '각 단계 따르기' 사고 경향보다는 '회복 지향적' 사고 경향을 택해보자. ... 회복 지향적 사고 경향은 우리가 혼란을 겪을 가능성이 있는 곳을 지도에서 찾아보는 것이다. 정해진 길을 벗어났다는 것을 어떻게 알 것인지, 길을 어떻게 찾을지를 생각해보는 것이다. ... 회복 지향적인 관점을 채택하면, 지도도 다르게 보인다. 우리는 기존과느 다른 특성에 주목하게 된다. 예를 들면, 길을 지나치게 될 경우 만나게 되는 도로, 회전을 해야 하는 도로와 비슷한 도로, 길을 잘못 들 가능성이 있는 혼동 지역 등이다. 이런 식으로 지도를 살펴보면, 실수를 일부 예방할 수도 있다. 그러나 이런 '회복 지향적 관점 연습'의 핵심은 실수를 없애기 위한 것이 아니다. 실수를 없애려는 것은 통제 심리가 작동하고 있다는 것이다. 새로운 관점의 핵심은 길을 잃게 될 거라고 가정하는 것이다. - p. 455

우리의 현재 위치와 목적지를 알면 길 찾기는 쉽다. 하지만 일단 길을 잃으면 훨씬 어려워진다. 복잡한 조건의 프로젝트를 할 때마다, 우리는 중간에 길을 잃고 방향을 회복해야 하는 상황에 처할 가능성이 매우 높다. 그렇더라도 우리는 길을 찾아야만 한다. 이것이 두 사고 경향이 차이를 보이는 부분이다. 프로젝트가 곤경에 빠졌을 때, 통제 지향의 사고를 가진 사람은 좌절하고 낙담한다. 하지만 회복 지향의 사고 경향을 가진 사람들은 계획이 어긋나면 변속 기어를 바꿀 것이다. 그리고 그들은 즉흥적으로 대처하고 차선책을 찾을 것이다. 그들은 어둠 속을 탐구할 기회를 가질 것이다. - p. 457

1 2 3 4 5 6 7 8 9 10 다음



메모장

크리에이티브 커먼즈 라이센스
이 저작물은 크리에이티브 커먼즈 라이센스에 의하여 이용허락되었습니다.