2011/12/5 갱신 진행 방향을 공유하고, 함께 준비하기 위해 구글 그룹스를 만들었습니다. 잠깐 고민했는데 일단 공개된 그룹스로 생성했습니다. 아래 내용은 원문: 2011/12/1 근거는 없지만 분명 우리도 할 수 있다는 생각 아니 생각이 아니라 가슴에서 울리는 소리 들었다. 궁리하고 궁리했고 어찌 할 수 있을까 노력했는데 머리로는 답이 없었는데 어찌어찌 오다 보니 드디어 할 수 있는 때가 왔다. ... 암튼.. 함께 하실 분 연락 주세요. 댓글도 좋고 ahnyounghoe_AT_gmail점컴으로도 좋아요.

우리 회사는 초기엔 어디서도 (무슨 일을 시켜도) 밥 벌이는 알아서 할 수 있는 컨설턴트가 주류여서 매출을 기준으로 평가했다. 규모가 커지면서 자연스레 평가 모델에 대한 변화가 요구되고 있지만, 여전히 대기업과는 차이가 있다 보니 나로써는 곁에서 보는 이들이 느끼는 평가시즌의 스트레스를 가늠하기는 힘들다. 작년에도 매우 가까운 사람이 C를 받았을 때 박탈감을 옆에서 목격한 일이 있지만, 어떻게 일했는지 알지 못하다 보니 그저 안타까울 뿐이었다. 하지만, 2009년엔가 1년 내내 함께 일한 고객사 한 분이 고과에서 C를 받고 일주일동안 퇴사/이직을 거론할 때는 곁에서 봤기 때문에 여러 가지 단면을 볼 수 있었다. 그 분을 편의상 C로 부른다. C는 마치 애사심 자체인양 사심 없이 주어진 일에 충실하다. 아니 주어지지 않은 일까지 한 발 ..

1. 스토리 재조정 원리/접근법 애자일 도입을 위해 난세(초기)에 할 다양할 일을 어찌 고객과 공유할 수 있는 일감으로 만들까 해서 사용자 스토리(User Story)에 대해 인터넷을 통해 학습하고 있다. 그러던 중 꽤나 괜찮아 보이는 논문을발견해서 정리. 제목은 Managing the Bootstrap Story in an XP Project Bootstrap Story! RUP 어휘로 따지면 architecturally significant use cases 에 해당하는 것이다. 사실, 방법론이 뭐든 초기에 토대를 닦는 것은 상식에 가깝다. 그런 면에서 RUP에 익숙하다면, Elaboration Phase에서 가장 중요한 산출물인 executable architecture를 애자일 환경에서는 어찌 만들까는 고민스런 일이 아닐 수 없다. 하지만, 여기서 난 그게 궁금하진 않다. 살짝 내가 아는 바만 정리해두면 결국 architecturally significant use cases 찾고 정리하느라 고생할 시간에 빠른 학습 사이클을..

몇 년 만에 다시 애자일 적용 준비 중. Dennis Doomen.NET이란 블로그에서 흥미로운 내용 일부 발췌 정리 기능 추가 전에 확인한 버그 수정 작업부터 먼저 하라. 스프린트 계획 회의에서는 User Story 단위로 이야기하고, 초점 흐리지 않게 통제. 오전에 스프린트 계획 회의를 하고, 점심 직후에 상급자 2, 3명이 모여서 스프린트 백로그를 훑어 위험요소를 다루자. 스프린트 계획할 때 쉬는 날과 하루 실제 근무 시간을 고려하라. 경험상 스토리 완료에 대해 25% 정도는 검토와 재작업에 쓰인다. PO(Product Owner)는 기술적인 제안이나 작업 추정에 관여치 말고 시연 방안이나 스토리와의 관계를 고려하고 스토리 명세 자체에 초점 맞추라. 초기부터 데모를 위한 서비를 운영하라. 유사한 업무 규칙은 복잡함을 감수하고라도 묶어서 다루라. 명확한 스토리만 스프린트에서..

Finding the Right Data Solution for Your Application in the Data Storage Haystack을 보고 정리함. RDBMS를 하나의 항목으로 취급해서 데이터 저장 솔루션을 바라보는 관점에서 다뤄짐.

Applications with Seasonal Traffic Patterns Proof-of-concept Applications Quick Temporary Dev & Test Environments CPU Intensive Applications On-Demand or Unknown Future Demand 출처: http://www.iheavy.com/2011/04/05/cloud-computing-use-cases/ 수긍이 가는 분류다. 다만, 애플리케이션 배포에 엄청난 노력을 기울이지 않으려면 자동화가 필요하고, 나아가 Portability가 확보되면 좋을텐데. 아직 PaaS가 초창기인 우리 환경을 고려하면 가능한 의존성을 줄여서 빌드/배포 자동화를 준비하는 일이 현실적인 대응일 듯