스크럼 vs 간판(Kanban)
![]()
스크럼과 간판(看板 Kanban)을 비교한 무료 책. 스크럼과 XP를 쓴 아저씨가 블로그에 공개한 버전과 그 후에 내용이 추가되어 InfoQ에 올라간 버전이 있음. 블로그 버전을 오늘 읽어봤는데 스크럼에 익숙한 상태에서 간판에 대한 이미지를 얻는데 큰 도움이 되었다. 내용이 추가되어 InfoQ에 올라간 무료책. 다운로드를 위해서 InfoQ에 계정 등록이 필요. 120페이지.http://www.infoq.co-m/minibooks/kanban-scrum-minibook 블로그에 공개된 무료책. 계정 등록은 필요 없음. 41페이지.http://blog.crisp.s-e/henrikkniberg/2009-/04/03/1238795520000-.html
일의 재정의
재밌게 하는 것은 "놀이"고, 그렇지 않은 것은 "일"이다.
이너게임
![]()
http://www.yes24.com-/24/goods/1941471 원제를 해석하면 "일의 이너게임"으로 다양한 이너게임 시리즈의 결정판 같은 책이다. 이너게임의 주장은 "목표"를 올바르게 "인식"하는 것만으로도 대부분의 문제가 해결되고 원하는 바를 달성할 수 있다는 것. 막 태어난 어린 시절에는 자연스러운 '셀프2'만이 존재하는데, 성장하면서 주입되는 가치관, 관습, 문화에 의해 부자연스러운 '셀프1'이 생성되어 셀프2의 순기능을 억제한다는 논리다. 예를 들어 어떤 일에 순수하게 몰입하고 있는 순간에는 자각이 없다가 정신을 차리고 나서야 깨닫는 경우가 있는데, 이 때는 순수하게 셀프...
도쿄 눈
![]()
어제 낮부터 갑자기 겨울날씨가 되더니 급기야 밤에 눈이 왔다. 2년만에. 아래는 큰 사이즈의 사진들. (파일첨부 기능에 버그가 있어서 사진첨부로 -_-;;) 원본 크기 요건 보너스
조카 일본 구경 시켜주기
![]()
주말에 조카가 놀러와서 일본 구경을 시켜줬는데, 몇 가지 새로운 사실을 알았다. Wii의 인터페이스는 일본어 모르는 애들도 쓸 수 있다.OK나 Next 같은 긍정적인 단추는 크고, Cancel이나 Return같은 부정적인 단추는 작다. 메뉴 중에 가장 바람직한 것이 제일 위에 나온다. 디즈니랜드에 대한 재인식평일에 7시에 닫는다. (너무 일찍 닫는다) 평일에 가니 엄청 유명한 어트랙션 빼고는 10~30분 이내에 탈 수 있다. 어트랙션에서 사고가 생기면 "우선권"을 한 장씩 받는다.우선권을 보여주면 기다리는 사람의 양해를 구하고 줄 앞쪽으로 보내준다. 지브리 미술관아...
싸움난 캥거루 사진
![]()
사진 정리하다가 재밌는 사진을 찾았습니다. 우에노 동물원이구요. 잃어버린 우산을 찾아오는 길에 진귀한 장면을 목격했네요. 급하게 찍느라 초점이 집을 나갔는데, 왠지 오히려 극적인 느낌이 ^^;; 어디를 맞았을까요? 알고 때렸을까요?
불안
![]()
http://www.yes24.com-/24/goods/1794971 "불안은 욕망의 하녀다"라는 말이 내 머릿속을 적나라하게 표현해준다는 느낌이 들었다. 철학과 종교, 예술, 역사를 넘나들며 불안의 원인과 해법을 파헤치는 "알랭 드 보통"은 참 박식하다. 그리고, 같은 말을 해도 어쩌면 이렇게 멋지게 비유할까라는 생각이 끊이지 않을 정도로 글도 잘쓴다. "불안" 이외에도 사람이 느끼는 감정을 적나라하게 파헤치는 책이 시리즈로 나왔으면 좋겠다. 지위로 인한 불안사회에서 제시한 성공의 이상에 부응하지 못할 위협에 처했으며, 그 결과 존엄을 잃고 존중을 받지 못할지도 모른다는 걱정. 원...
스크럼 일기 3 - 모자
![]()
어떤 모자를 썼는지 명확하게 하자 자격증을 가진 스크럼 마스터가 있는 것도 아니고 기존의 조직 체계도 있다보니 한 사람이 여러 역할을 맡을 수 밖에 없다. 우리 팀장님은 실장님, 팀장님, 프로덕트 오우너, 경력많은 개발자(조언자) 역할을 해야하고, 노예형 스크럼 마스터는 개발자 역할을 병행해야 한다. 그러다보니 지금 "경력많은 개발자"의 모자를 쓰고 조언을 해주는 것인지, "프로덕트 오우너"의 모자를 쓰고 요청을 하는 것인지 오해가 생기기 쉽다. 이렇게 설계하는게 좋았다라는 경험을 말해주는 것 뿐인데, 명령으로 받아들여 프로덕트 백로그에도 없는 ...
소프트웨어 공학의 사실과 오해 10 - 연구, 마무리
![]()
http://www.yes24.com-/24/goods/1418676 연구 그런데, 소프트웨어 연구에는 문제가 있다. 평가적 연구(방법, 모델, 이론 등을 검토하는 연구)가 거의 없다는 것이다. 소프트웨어 공학 연구 유형의 스펙트럼에서 14%만이 평가적 연구다. 컴퓨터 과학 연구도 단지 11%만이 평가적 연구다. 이와는 대조적으로, 정보 시스템과 같은 다른 주요 컴퓨팅 분야에서는 평가적 연구가 67%에 이른다. p.265 Potts(1993)은 이런 잘못된 연구 방법을 '연구한 다음 전파하는 방식'이라고 불렀는데, 이는 새로 연구한 접근방법의 제안과 이를 실무에 전파하기 위해 제시하는 중간에 평가가 ...
스크럼 일기 2 - 프로덕트 로그
프로덕트 로그도 점진적으로 발전한다 개발팀에게 전달되는 요구사항이나 스펙이 완벽하지 않다고 불만을 가질 일이 아니다. 좋은 설계를 반복없이 한 번에 만들어 낼 수 없는 것처럼 좋은 프로덕트 로그도 한 번에 만들어 낼 수 없다. 보통 고객이란 불특정 다수이므로 완벽한 요구사항을 건네줄 사람이 있는 것도 아니고, 개발 도중에도 시장환경이나 조직의 상황이 계속 변하므로 스펙이나 우선순위 조정이 불가피하고, 기술적인 한계나 복잡성에도 영향을 받는데 이는 개발팀이 연구, 조사, 스파이크 같은 것을 해봐야 알 수 있는 것이라 초기에는 예상하기 힘들다...
Altruistic Programmer's Blog
이타주의적