나는 유일한 개발자, 프로젝트 관리자, 디자이너, QT 담당자 (예, 알고 있습니다 ... 나쁘다!)이며 때로는 클라이언트이기도 한 프로젝트에서 많은 시간을 보냅니다.

나는 단지 앉아서 일하는 자유형에서부터 프로젝트가 오래 걸리는 시간까지 끝까지 일인당 버전의 스크럼에 이르기까지 프로젝트 계획 및 관리를 위해 모든 것을 시도했습니다. -남자는 매일 아침 차트를 태 웁니다 (농담 아님).

혼자 일하는 데 많은 시간을 할애하는 사람들에게는 자신을 조직하고 대규모 (한 사람의) 프로젝트를 관리하며 생산성을 최대한 높이는 가장 좋은 방법은 무엇입니까?

목표의 명확한 목록을 유지하는 것이 중요합니다. 기능 크리프가 자체 관리 프로젝트를 쉽게 인수 할 수 있습니다. TDD "작동 할 때 완료"접근 방식도 도움이됩니다. 이것은 당신이 완벽 주의자가되는 것을 막습니다.

실제로 저에게 도움이되는 것은 주어진 상황에서 다른 엔지니어 나 프로젝트 관리자가 할 말을 상상하는 것입니다. 종종 나쁜 코드에서 "나 자신을 부끄러워"하거나 일정이 미끄러지면 다시 돌아올 수 있습니다.

여기 당신은 간다 ... http://xp.c2.com/ExtremeProgrammingForOne.html

XP는 소규모 초점을 맞춘 팀에 최적이므로 XP가 크게 축소됩니다.

• 기능 요청의 스프레드 시트를 작성하고 우선 순위를 정하고 최상위 요청을 선택할 수 있습니다.
• 수락 기준을 정의하고 (어떻게 보이는지) 실행 가능한 테스트로 코드화
• 다음으로 수행 할 엔지니어링 작업을 정의하십시오.
• 단위 테스트를 작성하고 가장 간단한 작업 (YAGNI)을 수행하고 항상 리팩터링하십시오. 목표는 외부 합격 시험을 통과시키는 것입니다
• 각 세션의 타임 박스. 효과적인 시간 관리를 위해 Pomodoro 기술을 볼 수도 있습니다 .
• 버전 관리 및 CI 서버 / 배치 파일 설정을 사용하여 소프트웨어 설치 또는 zip 생성
• 자주 데모하십시오. 피드백을 원본 스프레드 시트로 라우팅하고 우선 순위를 정하십시오.

한 팀으로 할 수 없었던 유일한 것은 PairProgramming입니다.

혼자 일하고 있다면. 조언은 다음과 같습니다.

1. 가능한 한 낮은 수준의 작업을 수행하십시오. 쉽게 코딩 할 수 있다고 생각되는 것을 포함하여 최대한 많은 라이브러리와 도구를 사용하십시오 (하지 말고 라이브러리를 사용하십시오).
2. 하향식 접근 방식을 취하십시오. 실제로 필요한 것만 코딩하십시오.
3. 추상적 용어로 문제가 발생하면 Google을 검색하여 이미 입증 된 학술 커뮤니티의 연구 논문을 사용하십시오. 알고리즘 만 코딩하면됩니다.
4. 가능한 한 자유롭게 변경할 수 있도록 시스템을 설계하십시오. (여기에서 일부 코드를 복사하여 붙여 넣기 포함). 실수를했다는 것을 알게되면 시간을 절약 할 수 있습니다. 실수를 할 때 버려야 할 일의 양을 최소화하십시오. (여기에서 복사하여 붙여 넣기 대신) 버려야하는 코드 조각은 해당 코드 작성에서 잃어버린 시간과 같습니다.
5. 자동 테스트를 많이 수행하여 변경할 때마다 정기적으로 회귀 테스트를 수행 할 수 있습니다.
6. 디자인의 책임을 분리하십시오 (즉, 커플 링 감소). 가능한 모듈 식으로 만들기
7. 디버거를 사용하여 디버그하고 바이너리 검색을 사용하여 결함을 찾으십시오.
8. 코드를 지속적으로 리팩터링하여 (명시 적) 커플 링 및 공개 메소드 노출 (암시 적 커플 링)을 줄입니다.
9. 실제로는 없습니다. 이것은 새로운 것을 생각해 낼 수 있도록 여기에 있습니다 : P

코드 검토

동일한 프로젝트에서 일하지 않은 사람에게 코드를 설명 할 때 특히 유용하므로 작동 방식에 대한 가정이 없습니다.

또한 회사 주변에서 지식을 공유 할 수있는 추가적인 이점이 있으므로 다른 사람이 다른 곳에서 바쁘거나 병든 사람, 사임 또는 해고로 인해 프로젝트를 수행해야하는 경우 처음부터 시작할 필요가 없습니다. .

스토리, 많은 고객 상호 작용, 빈번한 릴리스 및 테스트 중심 개발에 의존하는 고유의 민첩한 버전을 출시했습니다. 나는 위키를 사용하여 스토리를 추적하고, 고객이 글을 쓰는 데 최대한 참여하게하고, 고객이 나와 함께 우선 순위를 정하고 릴리스로 구성하도록합니다. 디자인과 구현을 위해 TDD를 사용합니다. 고객이 빈번한 릴리스 (때로는 새로운 기능이 개발됨에 따라 매일)를 시도하여 피드백을 빠르게받을 수있는 QA 서버를 설정했습니다. QA에 릴리스하지 않고 3 회 이상 반복하는 경우는 거의 없습니다. 고객은 QA 버전에 출시 할 기능이 충분한 지 결정하고 목록에서 더 이상 기능을 개발할 필요가 없는지 결정합니다.

우리 회사에서 우리 그룹은 모두 동일한 프로젝트에서 작업하지만 상대적으로 독립적 인 부분에서 작업합니다. 우리가 여기에서 많은 일을하는 것은 당신이하고있는 일이 조금 까다로워 보이거나, 무언가를 구현하는 여러 가지 방법으로 길을 갈 때 다른 사람을 잡고 전에 찬반 양론을 논의하는 것입니다 당신은 진행합니다. 코드 검토가 완료 될 때까지 기다리는 경우 코드 검토에서 많은 결함이 발견되었지만 일반적으로 주요 아키텍처 변경을 고려하는 데 너무 많은 시간을 투자했습니다.

또한 Test Driven Development는 최근 포화 상태가 된 약간의 유행어라는 것을 알고 있지만 테스트를 진행할 때 품질 검사를 제공하기 때문에 솔로 개발자에게 큰 도움이 될 수 있습니다. 암호. 또한 나중에 유지 보수 담당자가 실수로 코드를 감지하기 어려운 방식으로 중단하지 않도록 도와줍니다.

나는 당신에게 다음을 제안합니다 :

1. 테스트 주도 개발
2. 즉시 수행 할 수없는 작업을 볼 때 코드에 "TODO : note here"를 많이 사용하고 대신 클라이언트가 다시 전화하기를 기다리는 페이스 북에 머물러있을 때 다시 방문하십시오.
3. 고객이 코드를 구매할 때 코드를 작성하십시오. 결과 만 아니라 코드를 검토하십시오. 고객을 코드 검토 의장으로 상상하십시오.
4. 어설 션 코드 작성

나는 내가 시간의 100 %를 전파하는 것을 연습 할 수 있다고 말할 수 있었으면 좋겠지 만 BDD는 당신의 상황을 취하는 좋은 접근법 인 것 같습니다.

자세한 정보가있는 링크는 다음과 같습니다. http://en.wikipedia.org/wiki/Behavior_driven_development

나는 매우 비슷한 보트에 있습니다. 나는 가능한 한 민첩한 원칙을 이해하려고 노력한다. 아마도 "정확하게"일을하지는 않지만 민첩한 원칙을 따르려고 노력함으로써 프로젝트에서 큰 성공을 거두었습니다. 바로 가기를 시작하지 않도록 팀이 없기 때문에 엄청난 양의 훈련이 필요합니다.

ReSharper와 같은 코드 형식 도구를 사용하면 최소한 시각적으로 다른 개발자가 코드를 쉽게 찾을 수 있습니다.

실제 방법론의 관점에서 단일 개발자는 특정 개발자를 고수하기가 어렵습니다. 저는 일반적으로 혼자 일하는 컨설턴트이며, 본인과 고객 모두가 민첩한 프로세스를 사용하는 것이 가장 쉽다는 것을 알게되었습니다. 나는 일반적으로 고객이 Trac와 같은 도구에 요구 사항을 직접 입력하도록 노력합니다. 이것은 다른 개발자들이 코드의 목적을 식별하는 데 도움이 될뿐만 아니라, 3 개월 동안 스스로를 도와줍니다!

철학 : XP / TDD + GTD

일반적인 개요 :

• 인터뷰 이해 관계자
• 스크린 모형, 연습, 종이 프로토 타입 (필요한 경우)
• 기능 / 스토리 브레인 스토밍 (이해 자와 관계없이)
• 테스트 사례 브레인 스토밍 (이해 자와 관계없이)
• 전반적인 디자인 / 아키텍처 씽크 타임 (필요한 경우)
• 반복 계획 (이해 자와 함께)
• 반복
• 프로세스 검토, 교육, 유지 관리 계획 등 (필요한 경우)

프로젝트의 인원 수에 관계없이 적절한 방법론이 도움이 될 것입니다. 한 번에 하나씩 선택하여 어떻게 도메인에 적용하고 매핑 할 수 있는지 확인하고 성공 여부를 측정하십시오.

아마도 더 흥미로운 것은 프로젝트에서 일하는 사람이 1 명뿐이므로 어떤 방법론을 버리지 않는지 묻는 것입니다.

그리고 나에게 눈에 띄는 핵심은 소스 제어입니다 (예, 도구이지만 작업 흐름의 일부이므로 프로세스이기도합니다). 사람들은 "동시에 코드를 편집하는 여러 사람들을 지원할 필요가 없기 때문에"합격을 원할 수도 있습니다.

아이러니하게도 SVN과 같은 개인에게는 GIT와 같은 배포 버전 제어 솔루션이 더 좋습니다.

코드를 버리는 경우 방법론에 약간의 문제가 생길 수 있지만 중요한 것은 한 사람과 팀 프로젝트로 처리하는 방법이 매우 훌륭하고 훈련되어 있다고 말하고 싶습니다.

다음 사람이 읽을 수 있도록 코드를 작성하십시오. "버려지는"코드조차도 영원히 유지됩니다.

기민한

기능, 스토리 및 테스트 사례는 공식 문서보다 훨씬 더 유익하며 일련의 작업 테스트는 죽은 나무 수보다 무언가를 사용하는 방법 또는 작동하는 방법을 시연하는 데 더 좋습니다

또한 반복간에 작업을 전달하는 것이 더 쉽습니다.

컨설턴트로서 저의 임무에 항상 최소 두 명의 개발자가있을 수있는 방법을 찾아 보시기 바랍니다.

나는 민첩하게 행동하고 다른 사람들이 따를 수있는 민첩한 이야기와 테스트를 남기는 것에 동의하지만, 사람들이 혼자서 일하는 동안 또는 다른 프로세스 나 방법론이 고수 될 것이라고 믿지 않습니다 .

코드 검토는 좋은 시작이라고 생각하지만 특정 문제 / 문제 또는 개선 사항을 해결하기 위해 페어 코드 검토 또는 페어 프로그래밍 (예 : 새로운 코딩 표준을 충족하도록 레거시 코드 변경)을 수행하는 것과 같이 비공식적이고 재미 있으면 좋았습니다. ). 때로는 두 세트의 눈이 하나보다 낫고 재미도 있습니다. 공유하고 토론하는 것이 더 열린 것처럼 보입니다. 또한 공식 / 비공식 점심 식사를하고 개인적으로 또는 그룹으로 한 일에 대해 이야기하는 세션에 대해 토론 할 수 있습니다.