[Book] Software Creavity


이 책은 로버트 L 글래스의 작품으로, 오래전에 나온 책이지만, “이 분의 내공은 정말 굉장하구나”란 느낌을 받게 한다.

이분의 책은 “우리가 알지 못한 소프트웨어 공학의 사실과 오해”를 통해 처음 접하게 되었는데, 그 당시 충격을 받을 정도였다. 엄청난 대가가 햇병아리에게 어마어마한 내용을 가르치는 느낌을 받을 정도였으니까..

Anyway, 이 책의 내용은 소프트웨어는 창의적 능력이 필요한 것인지 아니면 규율이 필요한 것인지를 다룬다.

결국, 규율을 중시하는 프로세스 oriented이냐 아니면 유연함을 중심하는 창의성 oriented이냐이다.

결론만 놓고 보면 그때그때 달라요 인거 같다. agile이 나온것도 보면 waterfall의 반대작용으로 나온것이고 덜 규율적이고 덜 문서작업을 하도록 하기 위한 것으로 생각된다.

pattern이 있으면 anti-pattern이 있듯이 뭐가 좋다고 하면 거기에 반대해서 다른게 나오고 그러는 것 같다.

이 책에서 또 한가지 놀랐던 것은 A-7프로젝트의 SCR이었다. Software Cost Reduction(SCR) – 이것은 내가 한라공조의 HVAC controller를 모델링할때 reference하기 위해 많이 봤던 프로젝트였다… 그 프로젝트의 실체와 전말을 그 책을 알게되어 놀랐다. SCR이라는 프로젝트가 formal specification의 우수성을 입증하기 위해서 실시한 것이었으나, 시간이 지날수록 본래의 목적을 달성하지 못하였고… 해군들은 결국 기존의 소프트웨어를 사용하고, 연구팀에서 수행하던 코드들은 전부 버렸다는 사실에 깜짝 놀랐다.

대학원때 정형검증쪽을 공부하면서 형식주의자가 된다는 것은 상당히 매력이 있는 것 같았고, 수리철학을 공부하면서도 그 내용에 매료되었었는데, 정형명세의 한계를 알고 좀 기분이 좋지는 않았다.

하지만, 무엇이든 좋은 점이 있으면 나쁜 점이 있는 법이고, 그런 의미에서 봤을 때 형식주의적 접근법이 만능이 될 수 없다는 것은 인정해야 할 것 같다. 많은 경험을 해볼 수는 없었지만, 분명 형식주의적 접근법은 매력적이고 나를 흥분시키는 방법임에는 분명한 것 같다. 다른 사람들이 쉽게 그것을 하지 못한다는 것이 내겐 더 매력적이었던 거 같기도 하고..

그런 방법이 대중화되는 것은 좀 쉽지 않을 것 같다. 다만 정형검증의 application이라고 할 수 있는 모델 기반의 test case 자동 생성은 그나마 성과라면 성과랄까…하지만 그것도 약점이 있긴 하겠지만..

이 책을 실용서라고 할 수 있을까 라고 물어본다면 긍정적 답변을 하긴 어려울 것 같다. 하지만 소프트웨어 공학의 근간을 연마하기 위한 목적이라면 매우 유용한 책임에는 틀림없다. Technic적인 것을 찾기 위해 읽으려고 한다면 실망이 클 것이고 이 무슨 개풀뜯는 소리냐고 할지 모르겠다.

프로세스에 대해 개발자들에게 무조건 닥치고 지키라고 강요하는 그런 사람들(품질관리자, 경영자, 프로세스 컨설턴트)이 있다면 이 책을 권하고 싶다. 이해할 수 있을지 모르겠지만..이해한다면 많은 반성을 하게 할 책이라고 생각한다.

[Book] 프로젝트가 서쪽으로 간 까닭은


컨설팅을 하면서 느꼈던 점들 가운데 많은 공감이 가는 부분들이 많다.

책 제목을 “프로젝트가 산으로 가는 까닭은”이라고 했으면 더 좋지 않았을까 싶은데, 달마 그림이 나와서 그게 개인적으로는 아쉬운 부분이다.

어찌되었건, 프로젝트를 진행하는데 있어서 많은 어려움이 있지만, 대다수의 일들은 회사가 일을 잘 할 수 있도록 지원하는 일을 게을리하면서 닥달하기만 하는데 있다고 볼 수 있다.

일부 개발자들의 역량이 부족하거나 변화를 거부하는 못된 습성으로 인해 프로젝트가 어려움을 겪는 경우도 있기는 하지만, 그런일들보다는 커뮤니케이션과 관리적 측면에서 발생되는 문제가 훨씬 많았고, 그래서 나 자신도 비록 엔지니어로서 문제 해결능력을 키우는데 관심이 많지만, 일을 하다보니 그런것보다 더욱 더 중요한 것이 관리라는 것을 깨닫는다.

프로젝트가 산으로 가지 않도록 하기 위해서는 여러가지 발생가능한 문제들을 해결해야 하는데, 그런 문제들을 해결하기 위한 조언을 포함하고 있어서 프로젝트 관리자로서는 필독서라고 할 수 있겠다.

책에서 공감가는 내용들 중에서 일부를 발췌한다.

  1. 광신도 – 팀원 한 명이 특정 이론을 신봉한다. 원칙에서 조금만 벗어나도 신성모독이라 여긴다.

–> 컨설팅을 수행할 때에 조심해야 하는 일 중의 하나이다. 실무자들에게 뭔가 어떤 목적을 달성하기 위한 방법으로 그들이 수행하기에 상당히 어려운 것들을 요구할 수 있는데 이를 조심해야 한다. 프로세스 개선을 하는 목적이 repeatable 하고 습관이 들 수 있는 뭔가를 하는 것이 목적인데, “넌 그냥 이번 프로젝트에서는 시키는대로나 해라… 앞으로도 너가 그렇게 할 수 있을지는 난 관심없다”는 식으로 받아들여지게 되면 갈등이 생길 수 있기 때문이다.

컨설팅이라는 것이 coach를 하는 것이고 시범을 보일 수 있어야 하는 일이고, 그게 현실적으로 무리한 일인지를 생각하면서 해야 하는 일인데, 그런 것을 고려하지 않다보면 실무자들과 충돌을 하게 된다. 그 때 주로 실무자들이 컨설팅 팀에게 하는 말은 이거다

“야.. 이걸 어떻게 하라고.. (말도 안되는 소리다.!)… 너 이거 해보기는 했니?”

  1. 조각칼을 우었으니 미켈란젤로가 되어라

–> 타이틀부터가 매우 공감가는 말이다. 회사에서 어떤 방법론이나 도구가 필요하다고 해서 도구를 사주기는 하는데, 그런 방법을 사용해서 생산성을 높이기 까지 매우 많은 시행착오 및 교육훈련이 필요하다는 사실은 미처 깨닫고 있지 못하는 듯 하다.

로버트 글래스의 책 ()에서도 언급했듯이 새로운 기술을 적용하면 오히려 생산성은 하락하고 그것을 익숙하게 할 때까지는 시간이 생각보다 많이 필요할 수 있다.

Simulink도구가 여러 장점을 가지고 model based development가 silver bullet인 것처럼 생각하고 모든 것을 그런 식으로 개발하려고 한다. 이런 접근법은 위험한 발상이다.

code수준의 복잡도는 requirement상의 logic의 복잡도를 해결하거나 design상의 abstraction등의 방법으로 complexity를 낮춰야만 관리 가능한 수준이 될 수 있다. 이것을 model based development로 하게 되면 미친년 머리 모양의 난잡한 stateflow model만 만들어지게 될 뿐이다.

  1. 한놈만 팬다 – 프로젝트 업무마다 책임자가 한명씩 존재한다. 모두 자신이 맡은 책임과 동료가 맡은 책임을 정확히 안다.

–> 요즘 agile관련 책을 보고 있는데, (이것도 프로젝트 계획 및 추정 목적이니 프로젝트 관리를 위해서이다.) agile의 정신과 위배되는 주장이다. 나도 경험상 20번의 원칙이 필요하다고 생각한다. 어떤 업무가 누구에게도 할당된 것이 아니면 그 일은 누구의 일도 아닌 경우를 많이 봐 왔기 때문이다. 회사에서 시키지도 않았고, 요구하지도 않고 바라지도 않는 일을 어떤 사람이 한다고 해서 그 사람에게 박애주의자라던지, 희생정신이 투철한 사람이라던지.. 그런말 하지 않는다.

넌 왜 시키지도 않는 일을 하냐? 시키는 거나 똑바로 해라.. 는 식의 핀잔만 듣게 되지 않을까?

 

관련링크

개발 프로세스의 불명확한 이해로 인해 발생되는 엉망진창 개발 사례

Project가 실패하는 이유(Why projects fail?)

흔한 프로젝트 관리 실수 12가지와 예방법

‘프로젝트 계획은 이렇게’··· 10가지 가이드라인

‘프로젝트 관리·통제는 이렇게’ 경험자들의 조언

 

[Book] 불확실성과 화해하는 프로젝트 추정과 계획


나는 소프트웨어 컨설팅 엔지니어이고, 프로젝트 관리 부분에 대한 영역은 그다지 큰 관심이 없었다. 그런데 컨설팅을 리딩하는 입장에서 프로젝트를 진행하면서 이해관계자들간 의사소통에 애를 먹었고 프로젝트의 범위 및 일정을 진행할 필요가 생겼다.

그런 니즈 외에도 Automotive SPICE 컨설팅을 하다보니 프로젝트 관리쪽의 중요성을 점차 깨닫게 되었다. 어떤 일이 10일이 걸려서 끝나는 일인지 20일이 걸려서 끝나는 일인지를 모르고 5일만에 계획을 하게 되면, 그 일에 할당된 사람은 거품을 물고 쓰러질 수 밖에 없다..

프로젝트 초반부터 하루에 짜장면 100그릇을 먹어야 하는 그런 말도 안되는 프로젝트에 참여하다보니, planning이 정말 중요하다는 것을 몸소 깨달은 것이다. 프로젝트 시작시점부터 망할것이라고 예감을 하고 시작하는 나 자신이 비참하다고 까지 생각이 들었다. 어쨌든,

프로젝트 계획은 그것이 소프트웨어 개발이든, 아니든 모든 프로젝트를 시작하는데 있어서 중요하며, 일정관리를 하는 것은 프로젝트를 시작하는데 있어서 핵심적인 사항 중의 하나이다.

서론은 이쯤에서 해두고, 이 책에서 얻은 내용을 기술하자면 다음과 같다.

1. 요구사항을 확인해보지도 않고 견적을 내는 바보같은 짓은 하지 말아라.

구현의 복잡도, 규모, 난이도 등이 고려가 되어야 일정에 대한 비용이 산출될 수 있다. 12월 31일까지 scope은 xx를 다 해야 한다는 제약 조건에서 이를 만족시키기 위한 방법을 물어본다면 작업 산출능력이 매우 뛰어난 슈퍼맨 수십명에게 수억달러를 투입한다면 모를까?.. 시작부터 말도 안되는 요구조건을 들이대는 곳을 많이 경험했다. 그리고 그런 부분을 아무생각없이 ok하고 수주하는 곳도 많이 봤다. 밑에 사람들은 죽으라는 얘기겠지?

2. 요구사항을 사용자 스토리로 만들어서 각각의 요구사항들의 상대적 구현 노력을 산출한다.

자동차 domain에서 요구사항을 사용자 스토리로 만들어서 하는 곳을 본 적은 없지만, 나름 적용할 만한 point가 있다고 생각이 된다. 요구사항을 식별하고 그 요구사항들을 가지고 구현의 복잡도, 규모, 난이도 등을 고려해서 투입되어야 하는 상대적 effort를 산출하는 것이다. 여기서 요구사항 1개에 대해, 설계, 구현, 시험등을 모두 포함시킨다.

여기서 가정하고 있는 것은 개발 life cycle이 waterfall이나 v모델이 아니라는 점이다. iteration model이어야 가능하다. waterfall을 생각하고 있다면 어떻게 구현해야 하는지 어리둥절 할 것이다.

요구사항 1개에 대한 상대적인 구현 effort의 장점은 절대적인 작업량을 의미하는 것은 아니라는 점이다. 그리고 그 요구사항을 구현하는 team의 작업량은 상대적일 수 있으므로 해당팀의 작업 속도에 따라서 작업일이 결정될 수 있다는 점이다. 이 부분이 매우 매력적이고 현실적이라고 생각된다.

요구사항 추정할 때에 여러사람이 게임을 하듯이 작업량을 추정하는 방법을 사용할 것을 권장하는데(플래닝 포커) 이 방법이 효과가 좋을 것으로 생각한다. 아직까지 해본적은 없지만 상당히 유용한 방법이 될 것으로 생각한다.

3. 프로젝트를 진행하면서 자신이 속한 팀의 작업 속도를 측정하여 프로젝트 추정을 보완한다.

프로젝트 추정은 1회성으로 끝나는 것이 아니라 프로젝트 모니터링을 하면서 지속적으로 보완을 하여 추정 오차를 지속적으로 줄여나간다. 그렇게 함으로써 프로젝트 초기의 추정 오차는 매우 클 수 있지만, 프로젝트 후반의 추정 오차는 매우 작은 값이 될 것이다.

이 책을 읽으면서 보통 계획을 수립할 때에 WBS를 많이 작성하는데, 그 부분은 old한 방법이고 여러 문제가 있고 현실적이지 않고… 등등 비판을 하면서 스토리 포인트 기반의 추정을 할 것을 이야기 한다.

무슨말인지 이해는 가는데, WBS를 버려야 하는지는 잘 모르겠고, 좀 더 프로젝트 계획을 경험하고 나서 판단을 해야 할 듯 싶다. 아직 WBS의 fundamental을 경험해보지 못한 것일 수도 있으니까 좀 더 공부해 봐야겠다.

Reference

[1] 애자일 마스터 – 프로젝트 추정에 대한 내용이 있다. 같이 보면 좋을 듯 하다.

[2] Combining Estimates with Planning Poker – An Empirical Study

[3] 플래닝 포커, http://ko.wikipedia.org/wiki/플래닝_포커

ISO26262, DO-178C, DO-278A