IT프로젝트 애자일 개발방식 확산 `소프트웨어 선진화 과제` 좌담회 (2) "'애자일 방식'등 새 관리기법 적극 도입해야"

성철이형이 알려준 Java Persistence with Hibernate에 대한 Rod Johnson의 혹독한 평이다. 날카로운 지적에 몇 번이고 다시 읽었다. 일반화시켜두면 후에 내가 쓴 글에도 적용할 수 있을 듯해서 남겨둔다. 글이 길면 주제에 따라 구분할 수 있지는 않은가? 주제와 무관한 내용을 끼워 넣지는 않았는가? 새로운 개념을 소개할 때 필요성에 대한 소개를 빠뜨리지 않았는가? 주요한 상황에 대한 고려를 빠뜨리지 않았는가? 도래하지 않는 가정을 기반을 두고 있지 않은가? 주요한 유관 개념을 설명하지 않고 쓰고 있지 않은가? 그림으로 표현하면 좋을 내용은 없는가? 독자를 고려한 난이도인가?

두 가지 소스에서 파생한 내용이다. 하나는 InfoQ 글 10 Suggestions for the Architect of an Agile Team 다른 하나는 IBM 리뷰 블로거 모임에서 나온 이야기 호주 MS에서 열린 테크애드 발표를 요약한 InfoQ 글:10 Suggestions for the Architect of an Agile Team EA와 구분하기 위해 글쓴이는 솔루션 아키텍트(solution architect)로 아키텍트를 구분했는데, 여하튼 아키텍트의 10가지 덕목을 나열했다. 이 중에 눈에 띄는 항목 세 가지와 호감이 가는 이유를 메모로 남겨본다. Trust your team… but be there for them Write docs … but only if someone needs to read them Write code! Trust your team… but be there for them – this has to do with the relationship architect-developer. The architect needs to make sure he does not overstep his role, making the developer’s job boring by taking all the fun of decision making. In the same time, the architect needs to be a mentor for..

You're a Bad Programmer. Embrace It. 초반에 받는 인상만 놓고 보면 별 다섯 개 만점에 일곱개를 주고 싶다. :) 물론, 후반부로 가면서 강도는 약해지고, 용두사미스런... 마치 내 블로그 글과 같은 가벼움을 느낄 수 있다. 친근(?)하네. 많은 분이 읽으시라고 번역할 시간(혹은 애정)은 없고, 앞부분이라도 영문으로 읽어보시라 권함

ㅁ 어제는 너무 바빠서 프랭클린 다이어리 할일 목록이 모자랄 정도였다. 하루 동안 다양한 목적으로 많은 사람을 만났다. 양적 풍부함에 뿌듯했지만, 반대로 돌아볼 여유도 없이 일에 날 맡길 수밖에 없었다. 여유를 내며 살아야 시도 때도 없이 범하는 시행착오를 깨달을 수 있다. ㅁ 목 디스크 치료받으면서 수 없이 운동(스트레칭)하란 말을 들어도 유념하지 않다가 일요일 저녁 봤던 S본부 특집을 보고 걸음걸이 교정을 시작했다. 이틀이 지나자 몸 안쪽 근육에 통증이나 뻐근함이 느껴진다. 아프단 생각보다는 그간 내가 너무나 내 몸을 버려뒀음을 깨닫는다. 자세 교정에 신경을 쓰니 몸의 신호에도 민감해진다. 오랫동안 실컷 쓰기만 하고 돌보지 않던 내 몸을 챙기자. ㅁ 출근길에 미끈한 다리에 눈길이 갔다. 쩝. 몸의 자세뿐 아니라 마음 자세도 ..