프로젝트의 소프트웨어 프로세스를 어떻게 만듭니 까?

다른 질문에 대해 쓴 것처럼 현재 작업중 인 프로젝트에는 소프트웨어 프로세스가 없습니다. 즉 , 문서 (하드 카피 요구 사항 또는 사양 포함) , 소스 제어 , 버그 데이터베이스 , 버그 수정 (고정) 및 새 코드가 동시에 추가되고 공식적인 테스터가 없음을 의미 합니다. Joel 테스트에 실패 합니다. 너무 안좋아, 재미 없어

어제 관리자는 이러한 단점을 해결하는 방법에 대한 문서를 작성해달라고 요청했습니다. 저는 6 개월 동안 인턴 일뿐입니다. 11 월에 추수 감사절을 떠나 학교로 돌아갈 것입니다. 그러나 나는이 프로젝트를 올바른 방향으로 움직일 수 있다고 생각하지만 어디서부터 시작 해야할지 확실하지 않습니다. 저는 현재 CiteSeer 와 Wikipedia 를 사용하여 소프트웨어 프로세스와 구현 방법을 설명하는 논문과 그와 같은 논문을 찾으려고 노력하고 있지만, 조언, 개인적인 경험 또는 블로그, 논문, Wiki 기사 또는 기타 항목에 대한 링크는 대단히 감사하겠습니다.

Agile 프로그래밍을 살펴 보는 것이 좋습니다.

많은 변종이 있지만 공통점이 몇 가지 있습니다.

• 기능을 정기적으로 검토하고 우선 순위를 정합니다.
• 지속적인 통합 및 자동화 된 단위 테스트.
• 문서를 통한 커뮤니케이션에 중점을 두십시오 (실제로 이것은 미리 작성된 거대한 유연하지 않은 사양을 검토 할 때 위키 스타일의 문서를 의미합니다).
• 유연한 추산으로 번 다운 차트 및 속도 메트릭이 생성됩니다.
• 사인 오프와 함께 200 페이지가 넘는 페이지 사양을 검토하는 일반 프로토 타입
• 소스 품질 또는 가능한 한 가까운 품질.
• 정기적 인 이해 관계자 검토-고객에 대한 이해 확대.
• 최대한 빨리 시장에 출시하십시오.
• 가능한 한 직접 통신하십시오.

시작하기에 좋은 곳은 MSF Agile 또는 Scrum 입니다.

상황이 6 개월 만에 끝나고 팀이 프로세스를 시작하지 않고 시작한 경우, 나는 당신이 도입 한 시간을 합리적으로 구현하고 유지할 수있는 하나 또는 두 가지로 소개하는 범위를 제한합니다. 그것이 내가 있다면 소스 제어 도구와 버그 추적기를 살펴볼 것입니다.

내가 시작하는 이유는 이러한 도구를 갖추면 팀의 현재 성과에 대한 기준을 설정하고 반복되는 문제를 식별하는 데 도움이되기 때문입니다. 프로세스 변경은 훌륭하지만, 기본 기초 항목이 먼저 있어야합니다.

우리 는 프로젝트 관리 프로세스에 Prince2 를 사용 하며 매우 잘 작동합니다. 그래도 프로젝트 관리가없는 회사에게는 참담하게 보일 것입니다!

TeamCity를 CI 서버로 사용하여이 비디오에 요약 된 개발 파이프 라인을 자체 요구에 맞게 조정했습니다.

http://channel9.msdn.com/shows/ARCast.TV/ARCastTV-Tuning-The-Development-Process-at-Spot-Runner/

TC는 내가 아는 유일한 CI 시스템으로 풀이 아닌 리포지토리 푸시를 수행합니다. 이는 이론적으로 더 이상 깨진 빌드가 없음을 의미합니다!

위의 일부의 감정을 반영하기 위해 구조가없는 팀은 민첩한 구조에 더 적합합니다. 오늘 소스 제어를 받으면 SVN에 변경 사항을 적용하기 시작하고 버그 사냥시 일부 개발자에게 차이점을 보여줍니다. 개정 로그 추가를 시작하십시오. SVN의 이점과 사용 편의성을 볼 수 없다면 파산됩니다.

MSBuild, CruiseControl.NET, FxCop, NUnit, NCover 및 Subversion을 사용한 .NET 프로그래밍을위한 Continuous Integration에 대한이 기사를 확인하십시오.

소프트웨어 개발 참호에서