이 소프트웨어 개발 프로젝트 점검 목록에 무엇을 추가 하시겠습니까? [닫은]

나는 체크리스트를 좋아합니다. 이 여행 체크리스트 , 체크리스트 이동 심지어 스크럼 점검 사항 .

배경 : 대기업이 고용했으며 전체 소프트웨어 개발 환경, 프로세스, 팀 등을 설정하는 임무를 맡았습니다. "카테 블랑쉬"가 있습니다. 소프트웨어의 작업 증분 작성에 대한 책임은 귀하에게 있습니다. 프로젝트 규모 : 2000 명 / 일

다음 (의도적으로 작고 불완전한) 체크리스트에 추가 할 항목 :

• Continuous Integration Server 설치
• DoD 작성
• 한 페이지 코딩 가이드 라인 작성
• 제품 백 로그 작성
• 버그 추적 시스템 설치
• 정기적 인 얼굴 시간 예약

* 1.) 개발자에게 실제로 필요한 것을 알아보십시오! *

2.) 여러 환경을 실제로 빠르게 구현할 수있는 솔루션을 조사합니다 (버즈 워드를 준수하지 않는 경우 퍼블릭 또는 프라이빗 클라우드 인스턴스 또는 구식 가상 머신을 고려하십시오).

3.) 소스 / 버전 제어

4.) 코드 검토 시스템 (Crucbile / Fisheye)

5.) 칸반 벽 (또는 비슷한 것)

6.) 커뮤니케이션 프로토콜 (실시간 채팅은 큰 장점), 위키는 또한 협업을 장려합니다. 여기에는 내부 홍보도 포함됩니다. 비즈니스 소유자, 기술 지원 직원 및 기타 그룹과 어떻게 관계를 맺고 있습니까?

7.) 전자 화이트 보드

8.) 개발자를위한 편안한 환경 (쿠치, 테이블, 냉각 구역, 우수한 WiFi 등)

9.) 좋은 커피 !!!

• 툴체인 설정 -IDE, CI 서버, 코드 품질 서버, 소스 제어, 웹 서버, 데이터베이스, 이슈 트래커 등
• 백업 -팀의 각 사람은 어떤 역할을합니까? 그는 어떤 프로세스 / 모듈을 '소유'하고 누가 백업합니까?
• (사용자 동의) 테스트 환경 설정-지속적인 통합뿐만 아니라 w. 단위 테스트, 통합 테스트는 실제로 나쁜 것, 여러 플랫폼, 응용 프로그램 서버, VM 등을 포괄합니다.
• 성능 테스트 설정- "성능이 어느 정도 떨어 졌습니까?"
• (최종 사용자) 설명서 개요 - 설명서에 어떤 내용이 포함됩니까? 어떤 종류의 문서가 필요합니까?
• 마케팅 채널 -내부 마일스톤 및 외부 릴리스는 어떻게 발표됩니까? 소프트웨어, 로고, 색상, 문구 등의 멋진 이름이 있습니까?
• 내부 커뮤니케이션 -다른 팀의 동료들에게 변경 사항에 대한 정보를 어떻게 알 수 있습니까? 협업은 어떻게 이루어지고 있습니까? 위키? 액세스 권한?
• 품질 보증 인력 및 프로세스-누가, 얼마나 자주, 어떤 기준으로 테스트합니까?
• 릴리스 프로세스 -언제, 얼마나 자주, 어떻게, 누가하고 있는지, 누가 릴리스를 받고 있는지 등
• 위험 관리 -최악의 시나리오 (프로젝트 관리 및 POV 및 런타임 POV) (예 : '모듈 X에서 소프트웨어가 실패하여 고객이 비용을 잃고 있습니다. 백업 계획은 무엇입니까?)
• 핵심 개발 환경 확보 ( 예 : 에스크로 가상화)
• 위치 공식 및 비공식 회의
• 모든 사람을위한 교육 또는 소개를 통해 모든 설정이 무엇인지, 각 부분이 무엇인지, 어떻게 사용하는지 알 수 있습니다.
• 관리인을 식별하고 상황이 나빠질 때 실제로 관리하는 데 필요한 모든 것 (예 : 권한)을 부여하십시오

사후 검토 -블록 단위로 작업하고 있기 때문에, 팀 규모에 따라 1-2 시간의 검토 일정을 잡고 모든 사람들이 돌아 다니며 올바른 일을 말하는 면담을 할 수 있습니다 (가능한 경우). 더 잘할 수 있었고 필요하지 않은 것을 개발 프로세스에서 실수로 실수를 배울 수 있다는 것은 나중에 작업 할 시간이 없을 때 실수를 피할 수 있다는 것을 의미합니다.

프로젝트에 적합한 전문가들로 구성된 훌륭한 팀을 고용하십시오. 일반적인 비즈니스 앱에서는 최소한 데이터베이스 개발자와 dba, QA 담당자, 시스템 관리자, 비즈니스 분석가, 응용 프로그램 개발자, UI 전문가 및 팀 리더를 고용해야합니다. DBA, 시스템 관리자, 비즈니스 분석가 및 QA는 개발 팀과 별도의보고 체인에 있어야합니다. 개발 데이터베이스 전문가는 응용 프로그램 개발자 및 UI 전문가와 동일한 기술 책임자에게보고해야합니다.

사무실 공간을 설정하십시오. 개인 사무실은 얻을 수 있다면 좋습니다 (이것으로 많은 운이 좋기를 바랍니다). 최소한, 책상, 전화, 컴퓨터, 화이트 보드 및 두 개의 전용 회의실이 필요합니다. 점심 시간, 냉장고, 청량 음료, 간식 및 커피를 이용할 수있는 장소가 있는지 확인하십시오. 무료 청량 음료와 커피가 더 좋습니다.

응용 프로그램 및 데이터베이스 모두에 대해 dev / qa / staging 및 prod 서버를 설정하십시오. 데이터베이스는 응용 프로그램과 동일한 서버에 있지 않아야합니다. 프로젝트의 규모와 범위에 따라 각 환경마다 여러 개의 서버 나 SAN 등이 필요할 수 있습니다.

서버가 설정 되 자마자 파일 시스템, 데이터베이스 및 데이터베이스 트랜잭션 로그의 백업을 예약하십시오. 일이 시작되는 첫날에 이것을하십시오. Iron Mountain과 같은 회사를 고용하여 매주 오프 사이트 백업을 수행하십시오.

소스 제어 시스템을 설정하고 사용 방법을 설명하는 문서를 작성하십시오. 조회 유형 테이블에 대한 모든 데이터베이스 구조 변경 및 데이터 삽입은 소스 제어의 스크립트에 있어야합니다. 이렇게하면 배포가 쉬워집니다.

모든 관련 사용자에 대한 라이센스와 함께 사용하기로 결정한 툴셋에 대한 상용 소프트웨어를 구입하거나 오픈 소스 소프트웨어를 다운로드하십시오.

빠르게 비명을 지르고 모니터가 두 개인 개발자 기계를 구입하십시오. 느리고 신음이 나는 테스트 사용자 컴퓨터를 하나 이상 구입하십시오.

새로운 개발자가 원하는 방식으로 교육하십시오. 주니어 개발자를 보유 할 수있는 충분한 규모의 팀이있는 경우 추가 교육을 예약하고 프로젝트 계획에 시간을 포함 시키십시오. 3 개월 이상 후배를 면밀히 모니터링하십시오. 첫 달 동안 모든 신입 사원을 면밀히 모니터링하십시오. 가능한 빨리 데드 우드 및 불량 개발자를 제거하십시오.

어떤 순서로 수행해야하는지 결정하십시오 (중요 경로). 의존하는 작업이 완료 될 때까지 중요 경로의 끝에 작업을 할당하지 마십시오.

테스트 계획 및 요구 사항을 작성하십시오.

고객과 정기적으로 예약 된 진행 회의를 설정하십시오. 그들은 당신이하는 일과 장애물이 무엇인지 알아야합니다. 상황이 늦어지는시기를 알려주지 마십시오. 마감 기한이 3 주 남았는데 이미이를 놓치게된다는 것을 알고 있다면 고객에게 알리기 전에 그 적자가 마술처럼 사라지지 않을 것입니다. 고객은 추가 된 요구 사항이 추가 비용과 시간을 의미하고 추가 된 모든 요구 사항에 다른 작업이 없어지거나 마감일이 새 작업의 시간에 따라 변경된다는 것을 고객에게 알립니다. 처음부터이를 명확하게하면 고객이 아닌 그룹이 흡수하는 많은 고통과 초과 근무 시간과 비용 초과가 줄어 듭니다.

한 사용자의 속도뿐만 아니라 예상되는 동시 사용자 수를 테스트 할 수있는 환경을 성능 테스트 환경으로 설정하십시오. 라이브 전날까지이 테스트를 기다리지 마십시오.

프로젝트 계획에서 QA가 버그를 발견하고 수정하는 데 시간이 걸린다고 가정합니다. 마지막 하루에 QA를 예약하지 마십시오.

데이터베이스가 생각할만한 크기의 테스트 데이터를 만듭니다. 모든 개발자가이 크기의 데이터베이스에 대해 코드를 테스트하도록하십시오. 개발자가 개인 컴퓨터의 작은 데이터베이스에 대해서만 개발하도록 허용하지 마십시오. 이것은 코드가 생산에 나올 때까지 잘 작동하는 빈번한 원인입니다.

예산에 대한 보상을 계획하십시오. 그들은 몇 달 동안 엉덩이를 벗을 때 사람들에게 동기를 부여하고 관리자 만 보너스를 얻습니다. 또한 자주 그리고 서면으로 감사합니다.

추적해야 할 사항을 추적하려면 프로젝트 관리 시스템이 필요하거나 스프레드 시트를 설정해야합니다. 프로젝트 계획을 세울 때 계획에 하루에 6 시간을 넘지 않아야합니다. 이는 휴가, 병가, 휴일, HR 회의, 성과 검토 등과 같이 프로젝트에 사용되지 않는 시간을 설명하는 데 도움이됩니다. 프로젝트를 사용할 수없는 기간 (예 : 실행중인 프로젝트) 미국에서는 11 월 1 일부터 1 월 1 일까지), 휴가 및 휴가 시간을 늘리려면 추가 수당이 필요할 수 있습니다. 개발자가 휴가와 휴가를 포기하고 병가, 배심원 의무, 사별 시간 등과 같은 일이 언제 일어날 지 아무도 예측할 수 없다고 예상하는 것은 불공평합니다. 그들이이 프로젝트에서 당신의 팀에게 일어날 것이라고 가정하자.

질문과 후속 답변에서 볼 수없는 몇 가지 사항 :

• 재난 복구 계획. 개발자 박스, 스테이징, 테스트 등을 어떻게 백업합니까? 모든 개발자는 가끔 눈이 오는 날 집에서 일해야하는 것을 가지고 있습니까? 기타.

• 훈련 계획. 몇 주 동안의 훈련이 날카롭게 유지되어야합니까? 누구든지 추적하고 있습니까? (대부분의 팀은 스프레드 시트로 충분할 수 있습니다.)보고 할 수있는 메커니즘을 갖습니다 ( "무엇이든"에 대해 2 시간 동안 웹 캐스트를 시청했다는 이메일을 누군가에게 이메일로 전송). 올해 컨퍼런스.

• 공구 위치. "모든 MSDN 구독을 제공합니다. 업무용 컴퓨터에 다른 것을 설치하지 마십시오"또는 "코드를 원하지만 코드를 편집, 컴파일 및 테스트하는 데 사용하는 내용은 신경 쓰지 않습니다" "종류의 장소. 결정을 내리고 기록하십시오.

• 서 있거나 감당할 수있는만큼의 통합 ALM 일반적으로 "임피던스 불일치", 이중 입력, 공구 오버랩 및 회전 의자 응용 프로그램 통합의 이유는 시스템이 비트와 조각 단위로 증가했기 때문입니다. 처음부터, 당신은 당신의 사람들이 사이클 내내 하나의 도구로 머물 수 있음을 보여주고 자합니다. X로 코드를 입력하지 않고 Y로 컴파일, Z로 테스트, A로 작업 항목 / 태스크 상태 변경, B로 보낸 시간보고, 대기중인 사람에게 C로 진행할 수 있음을 알리고 D로 다음에 무엇을할지, E로 전반적인 진행 상황을 확인하십시오.

더 많은 사람의 일을 절충하십시오.

사람들이 처음에 충분한 양을 할당하는 경우는 드물다.

[나중에 ... 다시 네오 티에이 팅 ...]

타사 라이브러리 및 사용법에 가장 문제가있는 것으로 보았습니다.

1. 사용할 라이브러리와 버전을 결정하십시오.
2. 라이브러리 업데이트를 프로젝트에 통합하는 프로세스를 작성하십시오.
3. 개발자가 모두 라이브러리를 선택해야합니다.
4. 사용중인 기술에 대한 공개 토론을위한 유익한 채널을 만듭니다.

왜? 제 3 자 라이브러리 (독점)가 헨리 버그를 가졌던 횟수를 말할 수는 없습니다. 또는 개발자에게 "어떤 버전을 사용 했습니까? 더 이상 사용되지 않는 것으로 표시된 기능을 사용한 이유는 무엇입니까?"

조직에 막대한 비용이 발생하면 개발 수명주기 내내 예산을 보안에 할당하지 않습니다. 즉, 일반적으로 보안이 효과가없고 값 비싼 활동이나 제어 세트가 너무 늦어서 많은 일을하기에는 너무 늦게 시작된 후에 보안이 종료됩니다.

개발의 다른 모든 측면에서와 마찬가지로 주요 이정표로 초기 프로젝트 계획에서 보안을 구축하고 반복적 인 프로세스를 사용하여 보안 지침을 최신 상태로 유지하십시오. 보안의 최종 승인은 설계에 따라 모든 보안 제어가 구현되었음을 확인하는 놀라운 일이 아닙니다.

그렇지 않으면 구현 후 보안을 실행하게됩니다. 가트너, IBM 및 기타 업체의 그림이 8-10 배나 많은 비용으로 기능에 영향을 줄 가능성이있어 사람들을 화나게 할 수 있으며 악용을 막기에는 너무 늦을 수 있습니다 그리고 손상.

1. 팀에 가져 가라

프로그래머에게 물어보세요! 실제로, 그것은 가장 중요한 것입니다. 개발자가이 변경에 직접 관여하지 않으면 많은 저항을 만날 수 있습니다. 결국,이 방법에 관하여 그들이 , 당신이하지 작동합니다. 말할 것도 없지만 사람들에게 방법과 도구를 강요하려고 시도하는 것은 대개 끔찍합니다.

2. 검사 및 적응

팀이 자신의 경험을 사용하여 선택한 트랙을 완만하게 돕도록 최선의 작업 방법을 찾도록하십시오. 그런 다음 정기적으로 협력하여 프로세스 수행 방식을 되돌아보고 프로세스를 개선하여 프로세스를 개선하십시오.