1. 요구 사항 분석과 설계 작업은 시간만 걸리고 효율적이지 못한 작업이다.
                      • 요구 사항은 항상 변경되고 추가 된다.

                      • 고객의 요구는 다 받아주어야 한다.

                      • 요구 사항에 대한 관리가 이루어지지 않는다.

                    2. 개발자는 정확한 데이터에 근거한 합리적인 일정을 제시하지 못하고, 경영진은 도전적인 일정으로 압박한다.

                      • 창의적인 일을 하는 직종인 개발자를 데이터로 관리하는 건 수치스러운 일이다.

                      • 개발의 산출물은 압박하면 결국 나오게 되어 있다.

                    3. 기술적인 결정을 내릴 때 비합리적인 결정을 내리는 경우가 많다.

                      • 신기술이 최고니까 무조건 도입하여 적용한다.

                      • 새로운 환경의 과제에서 과거의 경험을 고집한다.(구관이 명관이다.)

                      • "잘 모르겠는데 이건 아닌거 같다."라며 막연한 결과를 도출한다.

                    4. 뭘 하는지 모르고 코딩부터 시작한다.

                      • 코딩부터 빨리 시작해서 일단 있는 것(초기 요구 사항)부터 구현하여 최대한 일정을 확보한다.

                      • 이미 개발해 놓은 코드 최대한 변경이 없도록 수정하거나 추가로 구현한다.

                    5. 문서로 작업하는 문화가 없다

                      • 개발하는 데 필요한 것은 오직 컴퓨터와 에너지 음료뿐이다.

                      • 엑셀과 아웃룩은 최고의 관리 도구다. 더 이상의 시스템은 과부하일 뿐이다.

                      • 중요한 내용은 머릿속에 있어야 보안상 안전하고 A씨가 처음부터 끝까지 아주 자세하게 잘 알고 있다.

                    6. 무엇을 개발하려는지 고객 스스로 모른다.

                      • "일단 만들어오면 보고 나서 의견을 주겠다."

                      • "전 봐도 잘 모르겠습니다. 전문가니까 알아서 잘하실 거라 믿습니다."

                      • "이것저것 요것 살짝 변경(골격 구조)하거나 추가(핵심 기능)했으면 합니다."(난 갑이다.)

                    7. 몇몇 능력 있는 개발자(슈퍼 개발자)를 중심으로 프로젝트가 진행된다.

                      • 코딩, 설계(아키텍처), 분석, 테스트, 기획, 고객지원, 프로젝트 관리, 행정 관리, 심지어 버그 해결까지 엄청나게 많은 일을 수행하는 뛰어난 개발자가 항상 있다.

                    8. 우리는 특별한 상황에 있기 때문에 일반적인 원칙이 적용되기 어렵다.

                      • 우리 분야(도메인)에서는 아무도 그렇게 사용하지 않는다. 혹은 전부 다 쓴다.

                      • "아, 그건 특별하게 구현된 거라서 일반적으로 생각하시면 안 됩니다."

                      • "해 보셨어요? 안해보셨으면 말을 하지 마세요."


                    + Recent posts