문제가 발생했을 때 다른 기능을 사용하기 위해 뛰어 다니는 것이 프로젝트 실패의 원인입니까?

개인 프로젝트 (또는 작업)에서 문제가 발생하거나 문제에 대한 해결책을 찾기 위해 대기하는 경우 코드의 다른 섹션으로 이동하면 응용 프로그램이 좋은 이유라고 생각하지 않습니다. 버그가 있거나 더 심해지지만 아직 완료되지 않습니까?

git을 사용하지 않고 각 기능을 특정 브랜치에 코딩한다고 가정하면 작업중 인 3 가지 기능이 있고 각각에 해결되지 않은 문제가 있기 때문에 문제가 발생할 수 있습니다.

따라서 작업을 마치면 이러한 중단 문제와 반 구운 코드가 남아 있기 때문에 스트레스를받습니다.

이 문제를 피하는 가장 좋은 방법은 무엇입니까? (만약 있다면)

git과 같은 것을 사용하고 기능 당 분기를 만드는 것이이 나쁜 습관을 피하는 가장 안전한 방법입니다.

다른 제안?

이것은 문제가되지 않습니다. 당면한 문제에서 일시적으로 벗어나는 것은 그러한 문제를 돌파 할 수있는 가장 좋은 방법 중 하나입니다 .

항상 소스 제어 분기를 올바르게 사용하고 코드의 절반 솔루션에 대해 걱정할 필요가 없습니다. 어떤 사람들은 휴식을 취하지 않지만 개인적인 선택 일뿐입니다. 그래도 다른 사람들과 나누기 위해 휴식을 취해서는 안됩니다.

smp7d가 언급했듯이 주위를 뛰어 다니면 현재 문제에서 정신적으로 벗어날 수 있습니다. 그러나 작업중 인 코드가 여전히 불완전하다는 것을 잊지 않는 것이 중요합니다. 어디에서 멈췄는지 확인하십시오.

smp7d에서 언급했듯이 소스 제어 및 분기는 새 기능 코드를 분리하고 기본 코드 기반과 어떻게 다른지 확인할 수있는 좋은 방법입니다.

내가 가진 제안 중 하나는 특정 방법으로 작업하는 경우 해당 방법에 대해 잘 알려진 단위 테스트 가 있는지 확인하십시오 . 당신이 다음 일 / 주 / 월 / 년 그 코드 작업을 그런 식으로, 당신은 분명히 방법이 무엇 말할 수 있어야 가정 은 현재 테스트를 통과하지 않는 경우에도 수행 할 수 있습니다.

이게 문제가 되나요? 구현하려는 기능의 10 %가 발생하면 그렇지 않습니다. 때로는 다른 일을 할 때 마음이 더 명확 해집니다.

분명히 구현하려는 기능의 90 %를 고수 할 때 문제가됩니다. 그런 다음 다른 사람들의 도움이 필요하거나 상사로부터 약간의 킥 아웃이 필요합니다. (물론 후자는 실제 기술적 인 문제로 인해 막힌 경우 비생산적이어야합니다.)

이 경우 가장 좋은 방법은 작업중인 기능을 더 작은 하위 기능 또는 "기능 조각"으로 분할하려고 시도하는 것입니다.이 기능은 하나씩 구현, 테스트 및 디버깅 할 수 있습니다. 나를 위해, 그것은 기능 조각을 작성하고, 공개 된 이슈를, 목록에 내려야 할 부분을, 우선 순위를 부여하고 (A, B, C이면 충분 함) 가장 우선 순위가 높은 것들에 대해 작업하는 데 도움이됩니다.

"점프를 뛰어 넘다"또는 더 명확하게 "무작위를 뛰어 넘다"는 잘못 언급 된 목표 중 하나 인 더 시급한 문제의 증상이라는 것이 저의 경험이었습니다.

모니터 측면의 포스트잇 메모 나 선택한 이슈 트래커에 첨부 된 공식 사양인지 여부에 대해 매우 명확한 아이디어가 있다면 거의 다음 에 무엇을해야하는지 정확히 알 수 있습니다. 당신이 항상 그 다음 일 중 하나에서 일하고 있다면, 당신은 프로젝트에 성공할 수있는 좋은 기회를 갖게 될 것입니다.

반면에 다음으로 가장 중요한 것이 무엇인지에 대한 아이디어가 흐리면 실제로 해결해야 할 문제를 찾아 내기가 훨씬 어렵습니다. 실제로 프로젝트에서 해결하려는 문제를 해결하는 것이 훨씬 더 어렵습니다. 이 특정 변경이 완료 되고 특정 문제를 해결 하기로 결정할 때 건조 합니다.

"UI를보다 쉽게 ​​사용할 수 있도록"과 같은 목표가 있다면, 다음 수정이 무엇인지, 또는 "UI 수정"을 마치고 다른 것으로 넘어갈 수 있다고 말하는 것은 거의 불가능합니다. 반면에 '자동 완성 기능을 사용하여 검색 창에이 드롭 다운 메뉴를 결합'하고 ''foo '를'Fooly Brand Baring '에 자동 완성해야합니다'와 같은 목표를 가지고 있다면 그 문제.

언제 중지 해야하는지에 대한 명확한 아이디어가 생길 때까지 코드를 작성하지 마십시오. 명확한 아이디어 가 없으면 일반적인 기능을 위해 다른 브랜치를 시작하는 대신 그 중 하나를 가져 오십시오.

만약 당신이 (개인 프로젝트에도) 좋은 작업 사양을 가지고 있다면, "뛰어 오르는 것"은 완전히 훌륭하고 안전하며 유용합니다.

문제에서 벗어나면 문제를 해결하는 데 도움이 될 수 있지만 컨텍스트 전환에는 비용이 발생합니다. 진정으로 고착되었거나 미션 크리티컬 한 작업 (예 : 고객이 다운 된 경우)이 발생한 경우에만 그렇게해야합니다.

작업간에 지속적으로 전환하는 경우 몇 가지 반제품 기능과 많은 시간이 낭비 될 수 있습니다. kan-ban과 같은 관행이 진행중인 작업 제한을 설정하도록 권장하는 이유입니다. 이 방법으로 최대 한 번에 몇 개의 작업 만 완료하는 데 집중할 수 있으므로 처리량이 증가합니다.

병렬로 구현되는 기능의 수를 제한하는 것이 도움이 될 수 있습니다. 다른 기능이 완료 될 때까지 한도를 초과하면 추가 기능 구현을 시작하지 마십시오. 이 방법을 칸반 이라고 합니다