sosa0sa.com

Agile 방법론에서 가장 유명한 것은 XP이지만 그 외에는 Scrum도 있다. Scrum은 MS에서 사용해서 유명한 듯하다. MS에서 나온 몇 권의 책도 있고,

이번에 Scrum 책 한권이 번역되어 나왔다. 아직 읽어보지는 못했지만 정진호 님의 글을 읽다가 손뼉을 치고 싶을 만큼 “맞아 맞아”를 외치게 한 문장 하나.

프로젝트의 일정이 점점 꼬이고 제어할 수 없는 상태에 빠지는 것은 숨어 있던 문제가 나중에 드러나기 때문입니다.

Scrum은 숨어있는 문제를 빨리 드러나게 해 준다고 하는데 도대체 어떻게 하길래 그럴 수 있을까? 궁금하다.

관련 포스트. (프로젝트 초기의) 때 이른 고통

시간이 갈 수록 S/W의 중요성에 대해 말하는 사람이 많아지고, 그 만큼 관심이 많아지는 듯하지만 그렇다고 효과적인 대안을 제시하는 경우는 별로 없다.

S/W의 품질을 높이기 위해 그들이 취하는 방식은 언제나 “뭔가”를 더 시키고, 더 요구하는 것이다.
단계마다 숫자를 확인하고, 그들이 생각하는 기준을 맞출 수 있는 지만을 확인한다.

그렇다고 기본적인 품질을 보장할 수 있도록 반드시 필요한 “시간”을 충분히 주지는 않는다.

이번에 하고 있는 과제 역시 “잘못된 계획”덕에 H/W에게는 필요한 충분한 시간이 주어졌지만 S/W에게는 전혀 그렇지 않다.
신규 보드를 받은 지 15일만에 BT(Block Test)를 하라는 게 말이나 되는 소리냐는 말이다.

누가 계획을 세웠는 지는 모르겠다. H/W는 신규보드니까 크게 바뀐다고 생각하는데 S/W는 그냥 예전대로만 하면 된다고 생각하니. 그 “예전대로”, “현재 수준으로만”이라는 조건을 만족시키는 것이 H/W의 의존성을 많이 갖을 수 밖에 없는 임베디드 시스템에서는 그리 녹녹한 일이 아니라는 걸 왜 모르는 건지. (물론 그런 하드웨어 의존성을 잘 구분해 놓은 구조여야 한다는 것은 인정. 제길. 다행히 많은 코드들이 그렇게 구현되어 있지만, 그런 코드가 어디에 있는 지 뭘 고려해야 하는 지를 모른다는 것이 문제다. 어이가 없지만 그게 사실이고)

회의에서 제일 자존심 상하고, 듣기 싫은 소리가 “H/W는 별 탈없이 잘 끝났네”, “S/W가 준비가 안되서”라는 소리다. 자기들이 S/W를 뭘 안다고.

S/W 개발의 가장 큰 문제는 바로 시간이라고 한다. H/W는 비교적 정확한 예측이 가능하지만 S/W는 전혀 그렇지 않다는. 그래서 필요하다고 생각하는 시간을 제시해도 수긍하지 않는다. 그리고 그 예측 역시 너무나 쉽게 한다. 도전적인 것이 아니라 엉터리로 계획을 한다는 것이 바로 문제다.

웹 브라우저에 나눔 고딕체를 적용한 데 이어 블로그에도 적용했다.

미투에 어떻게 적용해야 할까 라는 글을 남겼더니 금새 답이 달렸다. 감사.

볼 수록 맘에 든다. 맥 화면에는 적용할 수 없는 건지 :-)

1. 새로 구입한 마제스터치 텐키리스 키보드. 택배를 받았는데 왼쪽 윈도키가 잘 안 눌려진다. 신상에 문제가 있는 것도 기분 나쁜데 수리 받으러 토요일 가려고 했더니 토요일은 논단다. 어이 상실. 평일에만 하는 고객센터가 뭐냐고.
   월요일에 전화해서 택배로 수리받는 절차를 물어봐야겠다.

2. 핸드폰 소리가 안 들린다. 덕분에 오해 사기 딱 좋다. 전화를 걸어도 통화음도 안 들려서 상대방이 왜 말을 안하고 끊냐고 화낸다. -_- 가볍고 얇은 거 빼고는 하나 장점이 없어 미워하는 마음 뿐인데 이 녀석이 그걸 느꼈나 보다. 8개월 만에 맛이 간 거로 보니.
   (집 근처에 A/S 센터가 있어 오늘 고쳤다. A/S 기사 아저씨 “매우 만족”으로 평가 해주니 무척 좋아한다. 그 정도 호의?야 뭐.)

3. 어젠 개발한 패키지를 부서내 검증 팀에 넘기는 날이었는데 걱정했던 “판정회”는 무사히 끝났다. 부족한 자료가 많았지만 현실적으로 더 이상 미룰 수가 없는 상황이어서 일단 넘겨줬다.
   그리고 나서 최종적으로(사실 최종 확인을 먼저 하고 판정회를 해야 하는데 그 놈의 시간이 뭔지) flash 적용하고, 패키지 적용하고 확인을 마친 시간이 밤 11시. 전날 새벽에 자동으로 total compile이 되었어야 하는데 서버가 불안해서 실패하고, 낮에도 한 번 또 실패하고. 결국 total compile 완료된 시간이 저녁 7시. 후배 녀석이랑 낑낑대고 적용해서 확인하고. 옆에서는 다른 시험하는 인도 친구들 안된다고 도와달라고 해서 그거 봐주고.
   근데 문제는 최종 flash랑 패키지를 적용했더니 이제서야 드러나는 문제점들 뭐냐고.

   정말 한심한 OS 팀의 업무 처리 방식때문에 머리가 돌아버릴 지경이다. 어쩜 그렇게 이기적으로 일을 하는지. 남에 대한 배려는 전혀 하지 않는다. 배려를 하지 않으면 거면 “이렇게 하라”는 지침이라도 주던가. 그냥 알아서 하란다.
   그런 이야기를 몇 명한테 했더니 다들 “이제야 알았구나~”란다.

정말 맘에 안 들어.

덕분에 판정회 끝내고 간만에 일찍 집에 가나 했는 결국 강남행 버스 타고, 지하철 갈아타고, 택시 갈아타고 새벽 1시에야 집에 들어왔다. 하도 힘들어서 화가 나고 기운 없어서 들어오는 길에 수퍼에서 맥주 1캔 하고 안주 하나 사서 먹었다. 오징어 안주는 왜 그리도 맛이 없었는지.

확실히 깨달았다.

프로젝트 실패의 원인 중 50%는 소통의 문제라는 것을 그리고 30%는 멍청한 일정. 그리고 나머지.

실은 멍청한 일정이 소통 문제를 일으킬 수도 있겠지만, 소통의 문제가 가장 커 보인다. 그리고 소통의 문제는 개발자들의 기본 자세가 문제가 크다고 생각한다.

내가 아는 것을 남도 알고 있겠거니 하는 생각.

바벨탑을 만들고 있다는 심정이다.

maczoo.com :: View topic - 하드코어 PC 광의 맥 사용기54- 타임머신의 작은 에러..

딱 내가 느낀 그대로다. 그래도 필요하면 무슨 에러가 왜 난 건지 알 수 있는 방법이라도 제공해줘야 지.

아무리 “깔끔”, “단순”을 추구한다고 해도 이건 -_-

8년 동안 함께 살아줘서 고마워요.

사랑해요.