소규모 팀을위한 프로그래밍을 계획하는 가장 좋은 방법은? [닫은]

저는 소규모 스타트 업 조직의 이사입니다. 현재 웹 응용 프로그램 플랫폼을 구축하는 두 명의 프로그래머 (한 명은 경험이 적고 한 명은 경험이 적음)가 있습니다.

지금까지 가장 큰 과제 중 하나는 계획 프로세스입니다. 프로그래머는 일반적으로 자체 작업 계획을 담당하지만 자체 마감 기한을 계속 초과합니다. 예를 들어, 그들이 추정하는 작업은 2 일이 걸리고 8 일이 걸립니다.

특정 작업이 얼마나 오래 지속 될지 정확하게 예측할 수있는 기술적 노하우가 없기 때문에 계획을 세우는 데 도움이되지 않습니다.

어떤 아이디어가 있습니까?

1. 이것에 대한 이유는 무엇입니까, 이것이 프로그래머에게 공통적입니까?
2. 계획에서 그들을 지원하기 위해 무엇을 할 수 있습니까? 소규모 팀의 프로그래머에게 유용한 방법이나 도구가 있습니까?

일반적인 기술은 다소 상식적이며 알아야 할 중요한 기술은 많은 기술 전문 지식이 필요하지 않다는 것입니다.

계획의 출발점은 해결해야 할 정확한 문제를 식별하고 명확하고 명확한 요구 사항을 갖는 것입니다. 당신이 그것을 가지고 있지 않으면, 추정치가 정확하지 않을 것입니다. 코드 작성을 시작하기 전에이 기능 문서에 어떤 종류의 기능 사양이 문서화되어 있으면 코딩이 시작되기 전에 요청해야하는 모든 질문이 수행되었음을 의미합니다. 이것은 놀랍도록 효과적인 타임 세이버입니다. 돌아가서 요구 사항을 명확하게하면 프로그래머가 응답을 기다리면 진행 상황을 차단할 수 있으므로 흐름이 깨집니다.

요구 사항을 식별 한 후에는이를 해결하는 데 관련된 작업 태스크를 식별해야합니다. 이것은 고전적인 분열 및 정복 운동입니다. 추가로 나눌 수있는 모든 작업은 더 세분화해야합니다.

더 큰 팀에서는 추정 포커를 사용하여 관련된 모든 사람의 경험을 기반으로 견적을 얻을 수 있습니다. 소규모 팀에서는 잘 작동하지 않지만 개발자 모두로부터 독립적 인 견적을 얻고 자신의 의견을 포함하는 것이 여전히 유용합니다. 특정 전문 지식이 부족하면 여기에 도움이 될 수 있으므로 작업의 관점에서 볼 때 개발 팀은 문제를 더 잘 파악할 수 있습니다.

팀 규모가 작을수록 각 작업에 대해 최상의 / 예상 / 최악의 사례 추정값을 얻는 데 도움이 될 수있는 다양한 범위의 값을 얻을 수 있지만 많은 오버런 추정값을 얻으면 개발자가 최악의 상황으로 기울일 수 있습니다. 더 정확하게 추정하는 법을 배웁니다.

소규모 상점에서는 개발자가 종종 시스템 관리자, 지원 팀 및 심지어 테스터로 두 배로 증가합니다 (수행 할 수있는 모든 작업에도 불구하고 테스트는 모든 비용을 피해야하는 테스트 임). 개발자가 실제로 새로운 기능을 수행하는 데 얼마나 많은 시간을 소비하는지 파악하고 추정치에 반영하십시오. 작업이 2 일로 추정되었지만 개발자가 60 %의 새로운 개발 작업 만 수행 할 수있는 경우 작업을 마치려면 4 일이 필요합니다. 긴급하지 않은 관리자 또는 지원 작업을 임시로 처리하지 않고 다소 일괄 처리 할 수 ​​있도록 처리해야하는 다른 작업의 파이프 라인을 제어하여이 작업에 도움을 줄 수도 있습니다. 많은 프로그래머 (확실히 저를 포함해서)는 훌륭한 시간 관리자가 아닙니다. 그런 점에서 손을 빌려 줄 수있는 모든 것이 도움이 될 것입니다. 싱글 태스킹은 멀티 태스킹보다 프로그래머에게 항상 더 쉽습니다. 낮에 시간을 차단하는 것도 도움이 될 수 있습니다.

기록 유지 , 당신이 계획 세션을 가질 때마다 추정치와 실제 데이터를 기록 -. 그런 다음이 a)를 계획하는 동안 추정치를 얼마나 부풀 릴지에 대한 지침으로 사용하고 b) 추정 기술을 개선하는 데 도움을 줄 수 있습니다. 각 반복이 끝날 때마다 (또는 그에 상응하는 작업을 수행 할 때마다) 전체 팀은 수행 한 작업을 검토하고 향후 예상에 통합 될 수 있도록 예상보다 오래 걸린 이유를 파악해야합니다. 이것은 뻔한 일이되어야합니다. 당신은 여기에 올바른 태도를 가지고있는 것처럼 보이지만이 답변은 잠시 쯤있을 수 있으므로 관찰하겠습니다. 누군가가 "여기서 실수를했다"고 말하면 "무엇을 더 잘할 수 있 었는가"로 바꿀 수 있지만 사람들에게 너무 느리거나 잘못되었다고 말하는 것은 문제를 악화시킬뿐입니다.

나는 이런 유형의 문제에 대한 은총 알이 없다고 알고 있지만 가장 큰 요소는 의사 소통입니다. 이는 소규모 팀에서는 실제로 쉬우 며 피드백을 사용하여 집단 기술을 향상시킵니다.

[2 일간의 추정 8 일 소요]이 프로그래머에게 공통적 인 이유는 무엇입니까?

다음과 같은 경우입니다.

• 실제로 무엇을해야하는지 명확하지 않기 때문에 시간이 좀 더 걸립니다 (그런데 시간이 얼마나 걸리는지 추측하지 말아야합니다)
• 그들은 당면한 과제에 익숙하지 않다 (그들은 언급하고 추정에 연구를 포함시켜야한다)
• 완성 된 작업을 더 큰 제품과 통합하는 데 예상보다 시간이 오래 걸립니다 (제품 아키텍처가 열등 할 수 있음)
• 개발자는 바퀴를 재창조하는 것을 좋아하며, 그렇게하면 다른 사람이 해결 한 문제를 우연히 발견 할 수 있습니다.
• 작업을 구현하는 동안 제품 소유자가 변경 사항을 도입하므로 다른 접근 방식과 이미 수행 한 작업 재실행이 필요합니다.
• 개발자들은 생산적인 환경에서 일하지 않습니다 (따라서 집에서는 2 일이 걸리 겠지만, 직장에서는 모든 방해 요소를 보상하기 위해 8이 필요합니다)

몇 가지를 말하십시오.

어쩌면 개발자에게 견적이 잘못되었다고 생각하는 이유를 물어 보는 것이 가장 좋습니다. :-)

개발 시간을 계획하는 가장 좋은 방법을 찾기 위해 오랫동안 노력한 것은 아닙니다. 이것은 실제로 당신이 실제로 볼 수없는 것을 정량화하는 것이 어렵다는 사실과 신화적인 man-month에 기인합니다. 이것은 프로그래머가 2 명이라면, 프로그래머가 1 명있는 것보다 2 배 빠릅니다.

아마 이미 알고 있듯이, 그것보다 훨씬 더 복잡합니다. 소프트웨어 개발과 관련하여 자격을 갖춘 개인 그룹을 반올림하여 개발 시간을 예측하는 한 가지 방법은 프로젝트를 완료하는 데 걸리는 시간을 추정하도록 요청하는 것입니다 (가능한 한 상세하게 설명). 모든 추정값 중 가장 높은 값을 취하여 두 배로 늘 립니다. 예, 당신은 올바르게 읽습니다. 당신은 두 배가장 높은 견적과 합리적으로 정확한 견적이 있어야합니다. 시간이 지남에 따라 내가 상사에게 무언가를하는 데 시간이 얼마나 걸리는지 정확하게 알 수 있었기 때문입니다. 나는 동료 프로그래머와 내 자신의 의견을 수집하고 가장 높은 추정치의 두 배입니다. 이 값이 너무 높은 것 같으면 새로운 기능을 테스트하는 것이 중요하며 나중에 잠재적 인 버그 수정을 고려하면보다 합리적인 수치처럼 보일 것입니다.

프로그래머로서의 개인적인 경험으로 프로젝트를 이정표로 세분화하는 데 도움이된다고 말할 수 있습니다. 이정표 1, 이정표 1에서 이정표 2, 이정표 2에서 이정표 3 등에 도달하는 데 얼마나 걸립니까? 이와 같이 분류하면 전체 프로젝트를 전체적으로 추정하는 것보다 대답이 훨씬 정확합니다. 이상하게도,이 모든 이정표의 추정치를 요약하면 일반적으로 전체 프로젝트의 원래 추정치보다 커집니다 (프로그래머가 자신에게 정직한 경우). 그러면 세부 사항이 핵심이라고 생각하게됩니다. 여기.

아마도 당신은 기술적 인 노하우가 부족하지만, 여전히 일반적인 수준으로 따라 가려고 노력해야합니다. 프로그래머는 반복에 문제가 없습니다. 프로그램을 개발할 때 항상 차지하는 것은 비틀기입니다. 따라서 포함하고자하는 기능이 많을수록 프로그램이 더 복잡해지고이 새로운 기능이 이전에 구현 된 코드 섹션에 영향을 미치지 않는다고 가정하면 개발 량은 작업량에 따라 선형으로 나타납니다. 완료하십시오. 아마도 새로운 기능 은 이전에 구현 된 섹션에 큰 영향을 미치기 때문에 새로운 기능을 구현할뿐만 아니라 기존 코드를 수정하여 개발 시간을 기하 급수적으로 개발해야합니다.

프로그래머에게 작업을 수행하는 방법을 알려주지 않고 프로그램이 일반적인 수준에서 어떻게 작동하는지에 대한 핸들링을 시도하면 새로운 기능이 해당 동작을 어떻게 수정하여 제공 할 수 있는지 곧 알 수있을 것입니다. 소요 시간에 대한 합리적인 추정. 이것을 추정치와 결합하고 (최고의 두 배) 개발 시간을 추정하는 방법에 대한 더 나은 아이디어를 얻습니다.

도움이 되길 바랍니다.

추정이 자주 중단되는 이유 중 하나는 추정이 실제로 매우 어렵고 시스템에 대한 경험과 지식을 변경해야하기 때문입니다. 대부분 큰 단계를 작은 단계로 나누는 것이 도움이됩니다.

이제 두 가지를 언급 ​​할 가능성이 많이 있습니다.

• 포커 계획
• PERT (프로그램 평가 및 검토 기술)

포커 계획

이것은 소규모 애자일 팀에서 잘 작동합니다.

위키 백과에서 발췌 :

• 경기를하지 않을 중재자가 회의를 주재합니다.
• 제품 관리자는 간단한 개요를 제공합니다. 팀은 가정과 위험을 명확히하기 위해 질문을하고 토론 할 수있는 기회가 주어집니다. 토론 요약은 프로젝트 관리자가 기록합니다.
• 각 개인은 자신의 추정치를 나타내는 카드를 뒤집어 놓습니다. 사용 된 단위는 다양합니다. 기간, 이상적인 날 또는 스토리 포인트 일 수 있습니다. 토론하는 동안 고정을 피하기 위해 피처 크기와 관련하여 숫자를 언급해서는 안됩니다.
• 모든 사람은 카드를 뒤집어서 동시에 전화합니다.
• 추정치가 높고 추정치가 낮은 사람들에게는 추정치에 대한 정당성을 제시 할 수있는 비누 상자가 제공되며 계속 논의됩니다.
• 합의에 도달 할 때까지 추정 프로세스를 반복하십시오. 결과물을 소유 할 가능성이있는 개발자는 "컨센서스 투표"의 상당 부분을 차지하지만 중재자는 컨센서스를 협상 할 수 있습니다.
• 계란 타이머는 토론이 구성되도록 보장하는 데 사용됩니다. 중재자 또는 프로젝트 관리자는 언제라도 에그 타이머를 넘길 수 있으며, 시간이 지나면 모든 토론이 중단되고 다른 포커가 진행됩니다. 대화의 구조는 비누 상자로 다시 소개됩니다.

여기서 중요한 부분은 설명, 논의, 동시에 추정치를 호출하여 바이어스가 발생하지 않도록 합의하는 것입니다.

건방진

하나의 정확한 견적을 내리는 것은 종종 어려운 일입니다. 더 쉬운 것은 가능성을주는 것입니다. PERT는 추정값으로 3 개의 값을 사용합니다.

• 가장 낙관적 인 완료 시간 (예상보다 문제가 덜 발생하는 경우)
• 가장 비관적 인 마무리 시간 (모든 것이 잘못되면 큰 재앙을 제외하고)
• 완료 될 가능성이 가장 높은 시간 (모든 것이 예상대로 진행되는 경우) <-개발자가 지금 예상 할 가능성이 가장 높습니다

이 세 가지 추정치에 가중치를 부여하면보다 안정적인 추정치를 얻을 수 있습니다.

t_expected = (t_opt + 4 * t_likely + t_pes) / 6

그리고 / 또는이 세 가지 값을 사용하여 실제 세계의 불확실성을 훨씬 더 반영 할 확률 분포를 구성 할 수 있습니다. 베타 분포 와 삼각 분포 는 눈에 띄는 선택입니다. 이를 사용하여 이제 "현재 추정치가 주어진 날짜 x 시점에 완료 될 가능성"또는 "95 % 확실성을 원하는 경우 완료 시점"과 같은 통계를 적용 할 수 있습니다.

실제로 PERT는 여기에 언급 된 것 이상으로 구성되어 있으며, 간결성을 위해 생략했습니다.

기록 메트릭을 유지하지 않으면 합리적인 수준의 정확도로 합리적인 견적을 제공 할 수 없습니다. 그리고 다른 회사 / 사람에게 시간이 얼마나 걸리는지 묻는 것도 도움이되지 않습니다. 문제는 각 회사와 개발자가 각자의 방식으로 작업을 수행한다는 것입니다. 따라서 모든 회사는 동일한 작업을 수행하는 데 걸리는 시간이 다릅니다. 각 개발자는 동일한 작업을 수행하는 데 걸리는 시간이 다릅니다.

최선의 행동 과정은 시간을 추적하기 시작하고 어떻게 든 과제의 난이도를 분류하는 방법을 알아내는 것입니다. 일부 회사는 코드 라인을 사용하고 일부는 기능을 사용하며 일부는 직감에 따라 움직입니다. 또한 개발자가 이미 구축 한 것과 유사하거나 새로운 기술, 팀이 이전에 만든 적이없는 새로운 기능과 같은 새로운 기능과 유사한 지 여부도 고려해야합니다. 시간 시스템은 복잡성을 상당히 증가시킵니다.

실제 데이터를 수집하지 않는 한 개발자가 몇 번이나 견적을 제공하더라도 실제로는 요청할 때마다 뒤에서 숫자를 가져 오는 것입니다. 예, 실제 데이터를 수집하는 것은 고통스럽고 처음에는 유용한 정보를 많이 제공하지 않지만 시간이 지남에 따라 합리적으로 정확한 견적을 제공하기 시작합니다.

또한 추정치는 일반적으로 큰 그림에 대해서만 좋고 단기 측정에는 적합하지 않다는 점을 지적하고 싶습니다. 예를 들어, 개발자는 2 일을 추정하지만 8 일이 소요됩니다. 개발자는 테스트 환경을 설정하고 시뮬레이터를 개발할 필요가 없었거나 완전히 배워야하거나 버그에 갇힌 완전히 새로운 기술이 있다고 설명하지 않았습니다. 그들은 파악할 수 없었거나 기능이 기존 시스템의 리팩토링을 필요로했다. 작은 작업에 대해 이런 종류의 것을 항상 예측할 수는 없습니다. 그러나 전체 프로젝트를 진행하는 동안 6 일이 더 걸리는 다른 작업으로 인해 6 일이 더 소요될 수 있습니다.

저는 저만의 소규모 프로젝트에 대한 유일한 개발자였으며 ​​대규모 팀과 함께 일한 산업 경험이 있습니다. 대기업에서 사용하는 기술이 소규모 팀에게는 반드시 필요한 것은 아닙니다. 어느 시점에서 나는 코드를 작성하는 것보다 더 많은 계획과 문서를 작성하고있었습니다. 다른 기술 (다른 답변은 큰 통찰력을 제공함)과 도구를 시도하여 먼저 일하는 좋은 방법을 찾으려고 노력하면 시간과 노력이 들지만 나중에 도움이 될 것입니다. 내가 찾은 유용한 도구 / 기술은 다음과 같습니다.

-Pivotal Tracker-스토리를 추적하고 작업을 중단하도록 장려하는 훌륭한 프로그램입니다. 스토리를 빠르게 입력하고 속도를 자동으로 추론합니다. https://www.pivotaltracker.com/ .

-여러 사용자가 동시에 편집하고 토론 할 수 있으므로 문서화를위한 Gdocs.

-내가 일했던 회사에서 우리가 시작한 모든 이야기에 대한 회의를 가졌었다면,이 회의에는 작업이 얼마나 오래 걸리는지 판단하는 것이 더 좋기 때문에 수석 프로그래머를 포함시켜야했습니다. 또한 어려운 과제가 무엇인지 판단하는 것이 더 나을 것입니다.

요약하면 저는 소규모 팀에서 일하는 열쇠는 빠르고 유동적 인 견고한 계획 체제를 갖는 것입니다. 또한 이야기와 관련된 어려움을 조기에 파악하여 과제를 계획 할 때이를 염두에 두어야합니다 (이로 인해 무언가 다르게 구축 될 수 있음).

도움이 되었기를 바랍니다