프로페셔널리즘

[CHAPTER 14] 기술적 변화의 실행

새로운 기술적 실행 관례나 도구를 도입하거나 그러한 것들에 대한 태도를 바꾸려 할 때 상사나 관리자를 설득하는 것보다 실무 개발자들을 설득하기가 훨씬 어려운 편이다. 시작부터 저자가 말하는 내용이다. 변화를 시도하기 위해선 같은 실무 개발자를 설득하는 게 더 어렵다고 한다. 기술 변화를 시도할 때 발생하는 회의론과 새로운 아이디어에 좀 더 열린 태도를 갖도록 설득하는 방법을 살펴본다. 변화를 반대하는 다양한 회의론과 그런 실무 개발자들을 설득하는 방법을 알려주는 게 이번 챕터의 내용이다. 회의론의 종류 새로운 문화, 실행관례, 도구, 절차를 도입할 때 가장 먼저 어떤 반발에 부딪힐지 미리 파악해야 한다. 테렌스 라이언은 그의 저서 [기술적 변화 추진하기]에서 회의론의 종류 를 다음과 같이 정리했다. - ..

[CHAPTER 5] 영웅, 선의 그리고 프로페셔널리즘

이번 챕터에서는 저자의 안 좋은 프로젝트 경험을 이야기하면서 시작한다. 그 프로젝트는 내가 합류하기 10년도 더 전에 시작되었다... 프로젝트는 전형적인 폭포수 방식으로 진행되었다. 2년 반 동안 나는 고객을 한번도 만난 적이 없다. 나뿐만 아니라 개발자 중에서 고객과 이야기를 해본 사람은 없었을 것이다... 회사는 상파울루에 있었지만 100킬로미터 떨어져사는 개발자들까지 채용해서 통근 버스를 제공했다. 나는 새벽 5시 반에 오는 통근버스를 타기위해 새벽 5시 정각에 일어났다... 그 당시에는 야근이 흔해 퇴근 통근 버스를 놓쳐 대중 교통을 이용하면 자정이 훨씬 지나서야 집에 들어왔다. 상황은 점점 악화되었고, 어쩔 수 없이 자가용으로 운전하여 출퇴근했다... 회사는 통근버스를 이유로 출퇴근 비용을 보조..

[CHAPTER 1] 21세기의 소프트웨어 개발, Part1 이념과 태도 시작

저자는 1990년대 복잡하고 난해한 코드로 남이 이해 못하면 실력이 좋다고 한다. 그리고 7년차에 '숙련된 개발자'가 아닌 '소프트웨어 아키텍트'로 커리어가 전환이 되면서 겪는 이야기를 한다. 아키텍처 팀은 개발자들이 따라야만 하는 디자인 패턴 북을 만드는 막강한 권한이 있다 (생략) 아키텍트는 비즈니스 분석가와 대화하며 요구사항의 기능적/비기능적 요소들을 이해하고 (생략) 요구사항과 고객 환경이 어떻게 바뀔지 무당이 점치듯 추측해야 한다. 예측하는 것은 거의 불가능했다. (생략) 시스템이 커지더라도 부작용이 적을지 고민해야 했다. 이에 대한 대응책이 추상화를 하고, 요소마다 디자인 패턴을 적용하는 것이다. 오늘날에는 그런 방식을 오버 엔지니어링이라고 한다. 어리석지만 그 당시에는 아키텍트의 혜안이라고 ..