sanity check list라는 것을 QA에서 만들어준다. 지난 번에는 미리 살펴보지 않고, 너무 늦은 단계에서 필요성을 느끼게 되었다. 이번에는 사전에 sanity에 대한 리스트를 체크를 정확히해서 좀더 품질이 좋은 상태로 유지를 하고, 단계를 QA를 통해서 최대한 릴리즈에 가까운 상태를 유지를 해야겠다.
개발이 끝나고, 최종QA단계에서의 부담이 적을 것이고, 좀더 다양한 시나리오로 테스트가 가능해지기때문에 버그를 하나라도 더 줄일수 있을 것이다.
deep simplicity는 "심오한 간결성"으로 책에는 해석이 되었다. minimalism을 좋아하는 나로서는 무척이나 반가운 말이다.
deep이라는 말은 extreme이라는 단어로 대치해도 의미적으로 맞아보인다. "극단적인 단순함" 아키텍쳐를 만들때 어떠해야 하는지에 대한 이야기를 한 것이다. 너무 많은 내용을 담아서도 안되고, 중요한 부분을 심플하게 표현을 할 때 정말 필요한 아키텍처가 될 것이다.
그리고, 최소주의를 적용해서 아래와 같이 서브시스템 간에는 정말 필요한 의사소통만을 해야겠다. 소통이 많을 수록 유지보수나 운영도 어렵고, 버그의 가능성을 커질 것이다.
좋은 아키텍처는 서브시스템 간에 일어나는 의사소통을 최소화한다.
아키텍쳐의 목표가 복잡함을 감소시키는 데 있다는 것을 인식하고 나면, 아키텍트가 소프트웨어 내에 어떤 것을 포함할지에 집중하는 만큼 어떤 것을 제외시켜야 하는지에도 초점을 맞추어야 한다는 것이 명확해진다.
성공적인 아키텍쳐의 주요한 특징 중의 하나는 변경 가능성이 높은 프로그램부분을 식별하는 것이다.
제대로 아키텍쳐라면 아직 개발되지 않은 부분에 얽매지 않고도 상세설계를 할 수 있을 것이다.
http://blog.naver.com/jeong_jaehun/90022080910 코딩하지 않는 아키텍쳐는 아키텍쳐라고 말을 할수 없을 것입니다. 일단, 설계를 한번해보세요~ 아주 깔끔하게 잘 나옵니다. 자기 만족도가 엄청 높습니다. 그 설계로 코딩을 시작해보세요~ 설계가 수십번은 바뀌게 됩니다. 이게 바로 소프트웨어 개발입니다. 한번 수준 높은 설계를 할수 있을지는 몰라도 완벽한 설계를 할수가 없습니다. 설계단에서 코딩도 병행해서 해야 더 나은 설계가 가능합니다.
특히, 프로젝트가 끝난 후 다른 팀으로 이동은 별로 좋은 기대결과가 아니다. 그것이 자의에 의한 것이라면, 더더욱 그러하다.
팀원이 너무 개성이 있어서 적응을 못해서 떠날 수도 있겠지만, 팀에 이동이 많을 수록 좋지 않은 팀이다. 자신이 원하는 일을 하고, 만족스러운 과정과 결과를 얻었다면, 누가 팀을 떠나겠는가?
관리자들은 자신의 팀의 인력변화를 유심히 살펴봐야 한다.
P. 146 인력관리 전략
People-ware management accountability. 인간을 중심으로 관리하고 책임지라. - 스티브 맥코넬
이것은 팀원들이 프로젝트가 끝난 후 실력이 좋아졌든 나빠졌든 관리자들이 책임져야 한다는 것이다. 팀원이 팀(or회사)을 떠나거나, 회사에 손실을 끼치는 관리자이다. 이와 반대로 팀원들의 기술이 향상되고, 사기가 진작된 경우는 조직의 발전에 기여한 것이므로, 관리자도 당연히 그 만큼 인정을 받아야 한다.
인재개발
프로젝트를 수행한 팀원을 얼마나 잘 존속키지는가를 토대로 관리자를 평가했다.
프로젝트 기간동안 관련자에게 모두 전문가로 클 수 있는 기회를 제공했다.
팀원 모두가 프로젝트 비젼을 신뢰하였으며, 프로젝트가 끝난 후 회사(or팀)를 더 괜찮다고 느끼게 되었다.
회사를 떠나는 사람은 회사에 불만이 많은 사람이다. 이것은 연봉, 복리후생, 프로세스 구조에 대한 반항일 것이다. 하지만, 팀을 떠나서 다른 팀으로 가는 것은 회사에 대한 불만이라기보다는 관리자에 대한 불만이라고 할수 있다.
하지만, 왜 떠나는가를 물어보면, 대부분 정확한 이야기를 피하고, 다른 이야기를 할 것이 분명하다. 그래서, 객관적으로 팀원들이 들어오고, 나가는 것을 주의깊게 살펴볼 필요가 있다. 인력의 이동이 잦은 팀은 나 조차도 오래머물기 싫을 것이다. 이미 대부분의 팀원들이 다른 곳을 쳐다보기 때문이다.
일단 버그가 생기지 않을 정도로 아주 단순하게 구현을 한 다음 복잡한 기능들과 로직을 추가를 하면서, 계속 테스트를 하는 것이다.
단순한 구현은 버그도 없을 뿐더러 빠르게 테스트를 통과한다.
테스트 통과를 보면서 코드를 붙여나가는 것은 그만큼 안전한 방법이다.
기능 명세서, 설계 구현 등에 대하여 단순성을 강조해야 한다. 개발자들은 대부분 복잡한 것을 좋아한다. 그들은 문제를 간소화하기보다는 더 복잡하게 만드는 경향이 있다. 하지만, 프로젝트 성공의 열쇠는 프로젝트를 한층 단순화하는데 있다. 프로젝트의 목표를 달성하기 위한 지름길은 복잡성을 제거하는 것이다. P.84
더는 덧붙일 것이 없을 때 끝내는 것이 아니라, 더는 뺄것이 없을 때 끝낸다. - 프랑스 작가 볼테르(Voltaire)
개발자들은 대부분 개발을 해서 돈을 버는 사람은 아니다.
MS는 제품을 출시를 했을때 ship-it이라는 상금을 받는다. MS가 소프트웨어를 개발해서 수익을 내는 것이 아니라 소프트웨어를 출시함으로써 돈을 번다는 사실을 개발자들에게 강조하는 것이다.
