프로그래밍 대 계획 [닫기]

최근에는 팀을 이끄는 수석 개발자로 인해 더 높은 수준의 계획 업무를 맡았습니다. 나는 장기 계획이 싫다. 내 두뇌는 자연스럽게 유선으로 보이지 않으며, 그것을 배우는 데 시간을 할애 할만큼 관심이 없다 (그림의 프로그래밍 측면을 따라 잡기에는 어렵다).

높은 수준의 계획을 세우지 않고도 여전히 훌륭한 프로그래머가 될 수 있습니까?

선임 프로그래머로서 전체 제품을 계획하고 완료 날짜를 선택하는 데 능숙한 사람이 있습니까?

자세한 장기 프로젝트 계획은 일반적으로 매우 부정확 한 것으로 악명이 높습니다. 시스템의 기능은 출시 전에 필연적으로 변경 될 것입니다. 사람들은 일반적으로 이해 관계자에게 최대한의 시각을주기 위해 사양에 들어가는 세부 사항을 해결하는 데 오랜 시간을 소비합니다.

애자일 계획 에 대해 더 읽어보아야 합니다. 사고 방식에 더 적합 할 수 있습니다. 많은 애자일 방법론은 상세하고 장기적인 계획에서 벗어나는 방법을 찾으려고합니다.

민첩한 방법론 은 자체 문서화 코드 와 격리 된 원자 사용자 스토리 및 궁극적으로 작동하는 소프트웨어 를 위해 세부적인 기술 사양 과 문서 를 최소화하려고 합니다. 효율적인 애자일 팀에서는 계획 수립에 최소의 시간이 소요됩니다.

민첩한 선언문을 읽고 스크럼을 살펴보십시오 . 사용 반복 개발 및 동적 시스템 개발 방법은 프로젝트를 안내합니다.

애자일 접근 방식의 주요 단점은 프로젝트의 정확한 범위를 알지 못한다는 것을 공개적으로 인정 해야 한다는 것 입니다.이 아이디어에 대한 경영진 인수는 매우 어려울 수 있으며 보통 시간이 걸립니다. 이에 대한 팁 은 이 질문과 답변 및 이 게시물 을 참조하십시오 .

그러나 상급 프로그래머가되면 코딩을 적게 할 것이지만, 애자일 팀에서는 더 많은 기술 사양을 작성한다는 의미가 아니라면 관리 및 개인지도에 더 많은 시간을 할애한다고 생각합니다. 팀원과 코드에 대한 아키텍처 결정을 내립니다.

네 가능합니다. 그러나 훌륭한 소프트웨어 엔지니어 나 소프트웨어 아키텍트가되고 싶다면 높은 수준의 계획을 세우십시오. 나에게 프로그래머와 엔지니어의 주요 차이점은 큰 그림을 볼 수있는 능력이었습니다.

훌륭한 프로그래머가 될 수 있습니까?

잠시만 요 이것을 오랫동안 할 수 있습니까? 아니.

오늘날 많은 고용주들과 함께 생활 산업 경쟁력을 높이는 것이 표준 운영 절차 입니다. 자신을 개선하지 않고 더 크고 어려운 문제를 해결하려고 시도하지 않으면 업계 경쟁이 치열한 인상으로 5 ~ 10 년 안에 시장에서 가격이 책정됩니다. 이것을 유지하면 고용주는 결국 당신을 제거해야 할 이유를 찾기 시작하고 다른 곳에서도 고용률이 급격히 떨어질 것입니다.

물론 프로그래머의 관점에서 보면 좋은 프로그래머가 될 수 있습니다. 경영진의 관점에서 보면 완전히 다른 질문입니다. 내 경험상 계획 프로세스에 참여하는 것이 1) 더 흥미로운 프로그래밍 과제를 얻고 2) 원하는 방식으로 수행하는 가장 좋은 방법입니다.

즉, 일단 단기 계획으로 넘어 가면 많은 옵션이 제공되지 않습니다. 원하는 솔루션이 6 주가 걸리지 만 예산이 2 주 밖에 안된다면 그들이 결정한 바에 얽매이게됩니다. 장기 계획에서 이미 논의한 사항에 대해 우려가있는 경우에는이를 다시 해시하지 않을 것입니다.

당신이 그 상태에 만족한다면, 당신에게 더 많은 힘을 줄 것입니다. 대부분의 사람들은 경험이 많을수록 만족도가 떨어집니다.

더러운 작은 비밀은 장기 계획 및 평가에 매우 좋은 사람 은 없습니다 . 더 나은 플래너는 자신의 한계를 알고있는 사람들입니다. 그러므로 믿거 나 말거나, 당신은 곡선보다 앞서 있습니다. 추정 불확실성에 대한 회계 교육을받습니다. 증거 기반 일정 또는 스크럼과 같은 기술을 살펴보십시오.이 데이터는 과거 데이터를 바탕으로 견적의 정확성을 보여줍니다. 일에 대해 더 큰 말을하면 장기적으로 더 행복해질 것입니다.

훌륭한 프로그래머가 될 수 있습니까?

짧은 답변 : 네 가능합니다.

그러나 관련된 프로젝트 유형에 대한 경험이 많을수록 계획 아이디어가 더 좋습니다. 이상적으로 프로그래머로서 우리는 문제를 해결하는 방법에 대한 접근 방식을 찾거나 찾는 방법이 있습니다. 따라서 접근 방식을 알고 있다면 계획에 대해 생각해 볼 수 있습니다.

또 다른 가능한 경로는 좋은 계획을 세우는 프로그래머가 결국 프로젝트 관리를 향하고 있다는 것입니다. 따라서 프로젝트 관리에 관심이있는 경우 해당 방향으로 추가 노력을 기울일 수 있습니다.

예, 아니오는 당신의 대답입니다.

한편으로, 당신은 프로젝트 관리에 대해 애 쓰고 있습니다. IMO, 모든 훌륭한 프로그래머는 어느 정도의 프로젝트 관리 기능을 가지고 있지만 기술은 다릅니다. 장기 계획 기능은 실제 프로젝트 관리와의 의사 소통 능력을 향상시킵니다. 따라서 "아니오"는 장기적인 계획을 세우는 능력 없이는 훌륭한 프로그래머가 될 수 없습니다.

이미 말했듯이 프로젝트 관리는 프로그래밍과는 관련이 있지만 다른 측면에 호소하는 다른 기술 세트입니다. 여기에 "예"가 등장합니다. 훌륭한 프로그래머가되기 위해 프로젝트 관리자 일 필요는 없습니다.

특정 상황에 따라 회사가 필요로하는 것과 귀하가 즐기는 것을 더 객관적으로 만드십시오. 귀하의 질문에 자아가 너무 많이 반영되어 있어이 상황을 볼 수있는 능력을 왜곡하고 있습니다. 여전히 즐기는 일을하면서 고용주에게 더 ​​많은 기여를 할 수있는 방법을 찾을 수 있다면,이를 고려하여 상사와상의해야합니다.

계획과 번지 보스

딜버트는 번지 보스에 대해 많은 스트립을 가지고 있습니다. 계획에 대한 우리의 도전과 기대는 지도력의 원인이자 결과 일 수 있습니다. 포춘지 선정 100 대 기업에서 일한 경험은 1 년 만에 프로젝트 리더로 1 년을 시작한 모든 사람이 퇴사 한 것입니다. 아마도 이것은 계획 문제 때문일 것입니다. 전직 책임자가 이런 이유로 떠났는지는 확실하지 않지만, 귀하의 역할에 따라 약속으로 계획을 세워야 할 때, 약속을 지키지 않으면 마감일 관련 종료가 종종 발생합니다.

계획의 조직적 맥락

계획이 불편한 경우 해결해야 할 문제를 문서화하거나 이해하기 전에 마케팅 또는 기타 이해 관계자에 대한 약속에 대해 책임을지는 것이 불편할 수 있습니다. 이것은 좋은 본능입니다.

계획은 중요한 도구입니다. 그것을 무시하지 마십시오. 오해하지 마십시오.

계획은 약속, 책임 및 협상력과 필수적으로 연결됩니다. 민첩한 계획에는 많은 장점이 있습니다. 계획된 방법론의 기술뿐만 아니라 그 기술을 알아야합니다. 귀하의 조직은 자체 접근 방식을 가지고 조언을 받고 많은 프로젝트의 리더십을 유지 한 사람과 협력하는 것이 놀라 울 정도로 도움이 될 수 있습니다.

간단한 계획 예-소프트웨어에 관한해서는 안됩니다 ...

지붕 회사가 교체를 위해 입찰하기 위해 우리 집에 왔을 때, 너무 낮게 입찰하면 일자리를 잃을 수도 있지만, 너무 높게 입찰하면 전혀 일자리를 얻지 못합니다. 어느 쪽이든, 그들은 사업에서 벗어났습니다. 새 역할에서 너무 낮 으면 책임이 시작될 때까지 프로젝트를 실행하면 문제가 발생합니다. 마감 기한까지 성공을 보장하기에 충분한 패딩이있는 프로젝트를 추정하면 많은 사람들이 다른 사람을 선택하기 만하면됩니다. 키커는 당신이 루 퍼와 다르다는 것입니다. 그는 지붕이 얼마나 큰지 알 수 있고 그 크기의 지붕이 얼마나 오래 걸리는지에 대한 역사적 데이터를 가지고 있습니다.

더 나은 플래너되기

어떤 종류의 훈련을 고려할 수도 있습니다. 민첩한 방법론과 가장 최근에 계획된 방법론에서 추정은 팀 전체의 활동입니다. 따라서 팀에 대한 교육을받는 것도 고려해야합니다.

경험상 팀 구성원으로부터 견적을 얻거나 요구 사항이나 기능 설명 또는 기존 코드를 참조하지 않고 작업 이름을 기준으로 2 분 안에 견적을 제공하는 것이 실망 스럽다고 말할 수 있습니다. 과거 프로젝트가 비슷한 문제에 몇 주를 보냈지 만 몇 가지 작업을 하루에 몇 분 안에 완료 할 수 있다고 주장합니다.

다양한 프로젝트 관리자 교육 과정과 인증이 있지만 독립적으로 공인 된 과정을 볼 것입니다. 애자일 팀 (또는 다른 방법으로)과 함께 작업 할 계획 인 경우 계획된 방법론에 기반한 접근 방식으로 인증을 선택하기 전에 다시 생각할 가치가 있습니다.

SLIM은 1970 년대 GE와 다른 회사에서 DoD 프로젝트를 수행 한 후 Putnam이 발명 한 방법입니다. SLIM은 영향력이 있으며 그의 회사 QSM은 그들이 만든 도구에서 나오는 것처럼 보이는 인증 을 제공합니다 . 회사에서 도구를 채택했는지에 따라 가치가 없거나 높을 수 있습니다.

Steve McConnell (Code Complete의 저자)은 소프트웨어 평가에 관한 책을 저술했으며, 그의 회사 Construx는 프로젝트 관리 연구소 (Project Management Institute)를 통해 인증 된 PDU 학점에 대한 두 가지 클래스를 가르칩니다 . 나는 그의 책을 가지고 있으며, 교실 훈련을 통해 주제에 대해 배우고 싶다면 Construx를 선택했을 것입니다. 또한 Scrum 교육을 수행하고 Scrum.org를 통해 인증 된 다양한 스크럼 평가를 관리합니다.

소프트웨어 프로젝트 추정에 대한 훌륭한 학문적 훈련을 제공 할 수있는 또 다른 출처 는 USC의 Barry Boehm 그룹으로 , NASA 및 기타 대형 계약 업체에서 매우 큰 프로젝트를 추정하는 데 사용 된 COCOMO 및 COSYSMO 건설 비용 모델링에 대한 광범위한 작업을 기반으로합니다. 나는 COCOMO의 진정한 신자라고 확신하지 못하지만, 일정 기간 동안 규모 및 비용 동인의 효과를 상관시키기 위해 수행 한 경험적 작업을 좋아합니다.

또한 O'Reilly가 출판 한 교재에서 Watts Humphreys PROBE 및 Kent Beck의 계획 게임을 포함한 주요 소프트웨어 평가 방법에 대해 간략하게 설명 하는 장을 찾았 습니다. PROBE에는 엔지니어가 자체 생산성에서 메트릭을 추적 한 다음 새 프로젝트의 할당 부분에 적용한다는 개념이 포함됩니다. 플래닝 게임은 개발자와 다른 이해 관계자간에 매우 협력 적입니다.