전사적 개발자 안내서 작성


17

저는 소규모 회사에서 일합니다. 내가 고용되기 전에 회사의 소프트웨어 개발 부서는 자율적으로 과로 한 사람으로 구성되었습니다. 몇 년 동안 회사의 소프트웨어를 작성해 왔으므로 회사 전체의 소프트웨어 개발 관행을 수립하는 일을 맡았습니다. 현재 가이드 라인이 없습니다.

코드를 작성하고 테스트 한 후 .zip 파일에 넣고 클라이언트로 보냅니다. TDD 및 버전 관리를위한 보너스 포인트.

상사는 업무를 수행하는 데 사용하는 일반적인 프로세스, 프로토콜, 도구 및 지침을 정의하는 소프트웨어 개발자 핸드북을 작성하려고합니다. 다시 말해서, 그는 "우리가 여기서하는 일"책을 원합니다. 신입 사원이 우리가하는 일에 익숙해지고 내 상사가 그의 부하들이하는 일과 그들이하는 방식을 이해하도록 돕기 위해 그것.

내가 보는 방식으로 기초를 세우고 있으며 올바르게 수행해야합니다. 그러한 안내서에 대한 주제를 어떻게 선택하겠습니까? 몇 가지 예제 주제를 제공 할 수 있습니까?

참고 : 중요한 경우 Microsoft는 주로 Microsoft .NET 상점입니다. XP 및 Scrum과 같은 민첩한 관행을 검토하고 있지만 회사에서 제대로 작동하도록하려면 크게 수정해야 할 수도 있습니다.


3
현재 프로세스가 매우 열악합니다. 현재 프로세스를 변경하는 데 회사 지원이 있습니까, 저렴하지는 않으며 필요한 변경 유형에 돈이 필요합니다. 주제에 관한 많은 책이 있으며, 그 실용 대부분은 많은 노력을 필요로하지 않는 방식으로 구현 해야하는 도구가 있습니다.
Ramhound

핸드북 주제 쇼핑 ?
gnat

1
@gnat 좋은 지적. 편집을 참조하십시오.
Phil

좋은 편집 (당신은 분명히 링크를 따랐다). 나는 또한 변경 것 주제의 종류 ... 당신이 생각 할 중요한 무엇 처럼 뭔가 당신이 주제의 중요성을 측정 할 방법 ... - 그런 식으로, 그것은 제프의 지침보다 인라인 것 내가 알고 멀리로
gnat

1
나는 이미 그렇게 할 수 있다고 생각하기 때문에 주제의 중요성을 측정하는 방법에 대해 실제로 걱정하지 않습니다. 오히려 예제를 찾고 있습니다. 나는 예제와 함께 할 때 항상 추상적 질문에 대한 대답이 더 나은 것으로 간주했습니다. 편집을 참조하십시오. BTW, 내 질문을 개선하는 데 도움을 주셔서 감사합니다.
Phil

답변:


20

나는 그것을 같은 섹션으로 나눌 것이다.

  • 현재 직원-이름과 직함 (이상적으로 사진과 함께)
  • 응용 프로그램, 응용 프로그램에 대한 로그인, 알아야 할 데이터 및 제출 요청
  • 회사 사이트 및 비즈니스와 관련된 주요 외부 사이트에 대한 책갈피
  • 회사가 통신, 이메일, 회의실 예약, 공유 화면에 사용하는 응용 프로그램
  • 영수증, 예약 여행 등 회사 관련 활동 절차
  • 개발자 머신 설정. 새로운 개발자 머신을 설정하는 과정을 자세히 설명하십시오. 이것은 보통 하루 만 걸릴 것으로 예상되지만, 실제로는 3-5 일이 걸립니다.
  • 개발 프로세스, 작업 추적, 할당 및 업데이트 방법 및 사용되는 도구
  • 테스트 방법, 테스트 대상, 테스트시기, 테스트 위치
  • 파일 명명 규칙 및 언어 별 표준을 포함한 코딩 표준.
  • 버그 처리 방법, 문서화 위치, 수정 방법
  • 배포 프로세스, 프로덕션 푸시에 대해 알아야 할 주요 사항은 무엇입니까?
  • 문서화 방법, 문서화 대상, 문서화시기.
  • 코드, 데이터, 표준, 문서, 링크 및 기타 자산의 위치와 같은 물건이있는 위치.

또한 모듈 식으로 만들면 직원이나 직원이 개별적으로 업데이트 할 수 있습니다. 예를 들어 직원의 이름과 직책은 사람들이 갈수록 자주 변경됩니다.

각 섹션마다 '초보자'관점에서 작성하려고 노력했습니다. 가장 중요한 것은 초보자에게 실제로 의미가 있는지 확인하는 것입니다. 당신의 상사는 분명히 하지 그가 의도 된 청중 아니므로이 문제를 검토 할 권리 사람입니다. 그는 단지 확인 내용이 테스트되고 결국하지 않습니다 수 있도록, 원하는 것이 맞다 그. 또한 '초보자'는 모두 초보자로서 "1 주일"만 있으며 한 가지 관점 만 가지고 있습니다. 따라서 새 직원마다 문서를 다듬을 가능성이 높습니다 (권장). 실제로 첫 번째 주 (예 : "초보자 매뉴얼 업데이트")에 할당하는 것도 좋은 작업입니다.

민첩 / 스크럼의 경우 :

애자일과 스크럼의 가장 어려운 부분은 '실제로'하는 것입니다.

읽기 위해 나는 http://agilemanifesto.org/ 에서 시작하여 거기에서 갈 것입니다.

또한 잘 알려진 http://www.halfarsedagilemanifesto.org/ 를 읽어 보면 실제로 작동하려면 모든 측면을 수용해야한다는 사실에 무게를 더합니다. 조직의 Agile을 심하게 수정해야하는 경우 올바른 프로세스를 사용하지 않고도 사람들이 혜택을 원할 가능성이 높습니다. 이 사실 자체 는 반쯤 아시지 못하도록해야한다.


6
나는 당신이 이것을 얼마나 자주 편집하는지 좋아합니다. 어떻게 ... 민첩 합니다. :)
Phil

민첩한 원칙을 일반적으로 수정하고 싶지는 않습니다. 필요한 역할을 모두 구현할 인력이 없기 때문에 XP와 같은 특정 관행을 수정하기 만하면됩니다. 그것은 또 다른 하루에 대한 또 다른 질문 일 수 있습니다.
Phil

죄송합니다. 질문이 수정되었으므로 지금 답변을 삭제했습니다.
Phil

1
당신은 설정 보너스 포인트 경우 회사 위키를 이 정보를 보유 ...
스펜서 Rathbun

스펜서 안녕하세요, 흥미 롭습니다. 나는 또한 마크 다운과 함께 github wiki를 사용하기 시작했습니다. 그들이 어떻게 비교되는지에 대한 생각. 분명히 많은 사람들이 코드에서 github을 알고 SO에서 마크 다운하므로 쉽게 채택 할 수 있습니다.
Michael Durrant

4

문서화하기 전에 몇 가지 사례를 소개해야 할 것 같습니다.

a) 소스 제어-소스를 저장하고 수정하는 방법

b) 릴리스 관리 및 추적-빌드를 수행하고 릴리스 번호를 지정하며 현재 릴리스 후보를 이전 릴리스와 비교하는 방법

c) 문제 관리-릴리스에서 버그를 어떻게 추적합니까?

이것들은 매우 기본적인 것들이지만 구현하는 데 많은 시간과 비용이 소요될 수 있습니다.


2
간단하게 유지하고 중요한 문제에 집중하여 +1합니다. 코딩 스타일에 대한 "큰 정부"명령이 실제로 필요하지 않습니다.
kirk.burleson

3

개발자 핸드북에 포함시킬 주제 :

  • 부서 내 역할 / 직책 및 해당 책임
  • 개발자 머신 소프트웨어 요구 사항 (즉, 필요한 개발 환경)
  • 소스 코드 저장소에 액세스하는 위치 및 방법
  • 사용중인 개발 도구 (예 : IDE)
  • 코딩 스타일 / 표준
  • 문서화 표준
  • 테스트 과정
  • 빌드 프로세스
  • 배포 프로세스
  • 지원 및 문제 관리 프로세스
  • 이 핸드북의 최신 버전을 구할 수있는 곳

이 핸드북에는 회사 전체 정보 (직원 핸드북에 있어야 함)가 아닌 개발 관련 항목 만 포함되어야합니다.


2

소스 컨트롤 사용

  • 사용중인 소스 제어 도구
  • IDE의 공통 명령 / 도구 구문
  • 분기 / 병합 전략.
  • 커밋 단위는 무엇입니까? 파일을 체크 아웃하거나 커밋하지 않는 데 시간이 얼마나 걸립니까?
  • 커밋 / 체크인은 어떤 수준의 "완료"를 나타 냅니까? 컴파일? 단위 테스트를 통과 했습니까? 검토 했습니까?
  • 커밋 / 체크인 노트에 포함될 것으로 예상되는 것.
  • 롤백 절차.
당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.