최근에 개발 프로젝트에 참여했으며 갑자기 수석 개발자의 직책을 맡았습니다. 저의 주요 책임은 프로젝트의 프로그래밍 부분을 작업으로 나누고이 작업을 다른 개발자에게 제공 한 다음 조각이 함께 작동하는지 확인하는 것입니다.

그러나 문제는이 작업을 수행하는 방법에 대한 실마리가 아닙니다. 나는 주말에 연필과 종이로 그것을 알아 내려고 노력했지만 병렬 작업 대신 순차적으로 작업해야 할 작업 목록을 계속 제공합니다. 필자는 파일을 기능으로 분할 할 것이라고 생각했지만 동일한 파일을 편집 해야하는 작업으로 끝납니다. 개발 초기에 전체 작업을 완전히 다시 작성해야 할 수도 있습니다. 일부 개발자가 프로그램이 좀 더 완벽하고 작업을 만들기가 더 쉬워 질 때까지 기다리도록 할 수 있었지만 몇 주를 아는 사람들을 위해 사람들이 앉아있을 것입니다.

나는 이것을 할 수있는 자격에 대해 상사와 대화를 나 and 다. 나는 내가하고있는 일을 모른다. 그래서 올바른 방향으로의 팁과 너지가 크게 감사하겠습니다.

질문에 대한 정답은 여러 권의 책을 채 웁니다 . 나는 이것에 대해 내 생각에 떠오르는 버즈 단어의 글 머리 기호 목록을 제시 할 것이고, 구글과 책은 당신을 위해 나머지를 할 것입니다.

1. 기초

   • 혼자 가지 마십시오 . 팀원을 최대한 참여 시키십시오.
   • 가벼운 여행 .
   • 민주주의, 그러나 너무 많이. 때때로, 그것은 가장 많은 수의 사람들을 만족시키는 것이 아니라 가장 적은 수의 사람들을 해치는 것입니다.
   • 무엇 유지 (수행해야 할) 방법 (가 이루어집니다) 별도 .
   • 에 대해 알아 스크럼 ( "무엇을"), XP (익스트림 프로그래밍, "어떻게"), 칸반 ( "얼마나"), 린 ( "어떻게하지") 및 개발 운영 ( "누구")를 사용하는 것입니다.
   • 린 (Lean) 도 흐름 에 관한 것입니다 : 전반적인 효율을 위해서는 흐름 효율 이 일반적으로 개별 효율보다 중요합니다.
   • 소프트웨어 기술 , 깨끗한 코드 및 실용 프로그래밍에 대해 알아 봅니다 .
   • 좋은 아키텍처는 취하지 않은 결정의 수를 최대화하는 것 입니다.
   • Scrum / XP / Lean / Agile은 완료되지 않은 작업량을 최대화하는 것입니다 : YAGNI .
   • 소프트웨어 의 기본 가치 는 쉽게 변경할 수 있다는 것입니다. 그것이해야 할 일을하는 것이 중요하지만 그것은 단지 2 차 가치입니다.
   • 반복 적이고 점진적인 접근 방식을 선호하고 , 거의 모든 회의, 특히 회의에 시간 상자 를 사용하면 Hofstadter의 법칙이 적용 되므로 Parkinson의 법칙 을 친구로 만들 수 있습니다.
   • Conway의 법칙 과 Tuckman의 팀 개발 단계를 이해함으로써 팀 구조의 균형을 유지하십시오 .
   • 프로그래밍은 사생아이며 동시에 과학 , 공학 , 예술 및 공예 이며 균형을 이루어야합니다.
   • 해서 스크럼 / XP / XYZ 사람에 대한 좋은 (나를 포함) 반드시 당신을 위해 좋은 의미하지 않는다 / 환경에 적합합니다. 맹목적으로 과대 광고를 따르지 말고 먼저 이해하십시오.
   • 검사하고 적응하십시오! (스크럼 만트라)
   • 복제 방지 -한 번만! (XP 만트라) 일명 DRY - 자신을 반복하지 마십시오 일명 진리의 단일 포인트 - SPOT

2. "어떤 세상"작업 분석 프로세스

   • 같은 요구 사항 수집 사용자 스토리 / 작업 이야기 에 제품 백 로그를 .
   • Role 과 비슷한 Persona 와 유사한 Actor (UML)와 유사한 User (User Story) 입니다.
   • INVEST (독립, 협상 가능, 가치 평가, 추정 가능, 소규모, 테스트 가능)를 기반으로 팀의 준비 정의를 충족 할 때까지 사용자 스토리를 세분화 하십시오 . (스크럼 회의 : 백 로그 개선 )
   • 비즈니스 가치 별로 제품 백 로그 를 정렬합니다 .
   • 준비 완료 (준비의 정의에 따라 준비 됨)가 되기 전에 스토리에서 작업을 시작하지 마십시오 .
   • 스토리 포인트 에서 스토리 의 노력을 추정 하려면 계획 포커 를 사용하십시오 . 삼각 측량 비교 를 사용 하여 추정값의 일관성을 보장 하십시오 .
   • 어제의 날씨 가 가장 좋을 것으로 예상됩니다.
   • 너무 큰 이야기를 나눕니다 .
   • Done 의 정의로 배달 문화를 개선하십시오 .
   • 완료 하기 전에 사용자 스토리 구현을 수락하지 마십시오 (완료 정의에 따라 완료).
   • 동일한 코드 기반의 여러 팀은 동일한 Done 정의 (특히 코딩 표준 )에 동의하고 공유해야합니다 .
   • 번 다운 차트로 진행 상황을 확인하십시오 .
   • 팀이 제공하는 것이 실제로 필요한지 이해 관계자와 정기적으로 점검하십시오. (스크럼 회의 : 스프린트 검토 )

3. 스토리 분석

   • 목록 및 설명 사용자 / 페르소나 / 배우 / 역할 (제품 소유자)
   • Epic-> 스토리 (사용자 스토리 또는 작업 스토리) (제품 소유자)
   • 스토리-> 승인 기준 (제품 소유자)
   • 스토리-> 하위 작업 (Dev 팀)
   • 합격 기준-> 합격 시험 (사양 : 제품 소유자, Impl : 개발자 팀)
   • 최소한의 End-to- (Half-End) 인 Walking Skeleton으로 시작하십시오 .
   • MVP 최소 실행 가능한 제품을 만듭니다 .
   • SMURFS, 특히 마케팅 가능하고 유용하며 릴리스 가능한 기능 세트를 사용하여 MVP를 확장하십시오 .

4. "어떻게 세계"실현

   • 사용 OOA / D , UML 및 CRC 카드 ,하지만 피할 큰 디자인 선행을 .
   • 프로그래밍 언어에 관계없이 가능한 한 객체 지향 , 구조화 및 기능 을 동시에 구현 하십시오.
   • 버전 관리를 사용하십시오 (바람직하게 분배 됨 ).
   • 수락 테스트로 시작하십시오 .
   • 적용 TDD를 시키는, TDD의 세 가지 법칙 관통 드라이브를 빨강 - 녹색 - 리팩터링 사이클 과, 단일 어설-규칙 , 4 A의 , GWT는 (하면 다음 감안할 때) 에서 BDD .
   • " 단위 테스트 는 빠르게 실행 되는 테스트입니다 ." — 마이클 페더스
   • SOLID 및 패키지 원칙 을 적용하여 커플 링 및 응집력 을 관리 합니다. 예 : SOLID의 S는 SRP = Single Responsibility Principle이며 편집 횟수를 크게 줄입니다. 팀의 병합 충돌.
   • 데메테르의 법을 알고 / 말하지 말라 .
   • 해당되는 경우 Continuous Delivery (DevOps)가있는 경우 Continuous Integration을 사용하십시오 .
   • 합의 된 공통 코딩 표준 ( 완료 정의의 일부 여야 함) 에 따라 집단 코드 소유권을 사용하십시오 .
   • 적용 지속적인 디자인 개선 (FKA 연속 리팩토링을).
   • 소스 코드는 디자인 입니다. 여전히 선입견은 필수 불가결 한 요소이며, UML 다이어그램을 명확하게 설명하는 사람은 없습니다.
   • XP는 하루가 건축의 날이 아니라는 것이 아니라 매일 건축의 날을 의미합니다. 디 포커스가 아닌 아키텍처에 중점을두고 있으며 코드에 중점을 둡니다.
   • 기술 부채를 낮게 유지 하고 4 가지 디자인 냄새를 피하십시오. 취약성 , 강성 , 부동성 및 점도 .
   • 아키텍처는 지속성 및 전달 메커니즘이 아니라 비즈니스 로직에 관한 것입니다.
   • 건축은 팀 스포츠입니다 (건축 에는 'I'가 없습니다 ).
   • 디자인 패턴 , 리팩토링 및 변환 우선 순위 전제 .
   • 프로젝트 코드는 다음 과 같은 우선 순위를 가진 ATP-Trinity 입니다. 1. 자동화 코드 , 2. 테스트 코드 , 3. 생산 코드 .
   • 팀원에게 정기적으로 팀 제공 방식을 개선 할 수 있는지 확인하십시오. (스크럼 회의 : 스프린트 회고전 )
   • 테스트는 FIRST -Fast, Independent, Repeatable, Self-Validating 및 Timely 이어야합니다 .

위의 목록은 확실히 불완전하며 일부 부분은 논쟁의 여지가 있습니다!

이 모든 당신을 무서워하는 경우 - 그것은 때문에 걱정하지 마십시오 한다 당신을 놀라게! 팀에서 소프트웨어 개발 프로젝트를 성공시키는 것은 쉬운 일이 아니며,이 기술을 제대로 교육하고 교육하는 사람들은 거의 없습니다. 이것이 당신을 두려워하면 직감이 제대로 작동하고 있습니다. 당신은 준비되기를 원합니다. 상사와 대화하고 시간과 훈련을 받으세요.

또한보십시오

• 스크럼에 기술적 인 '사용자 스토리'를 쓴 사람

추가 자료 (온라인)

• Ward Cunningham 등의 Portland Pattern Repository
• Robert "Uncle Bob"C. Martin 의 OOD 원칙
• 실용적인 프로그래머 팁

더 읽을 거리 (책)

• Robert C. Martin의 클린 코드
• 민첩한 소프트웨어 개발 : Robert C. Martin의 원칙, 패턴 및 사례
• 실용 프로그래머-Journeyman에서 Andrew Hunt와 David Thomas의 Master까지
• Michael Feathers의 레거시 코드로 효과적으로 작업
• 리팩토링-Martin Fowler의 기존 코드 디자인 개선
• Joshua Kerievsky의 패턴으로 리팩토링
• Steven Silbiger의 열 일 MBA (sic!)
• Eric Evans의 도메인 주도 디자인
• Mike Cohn이 적용한 사용자 사례
• Gray Booch et al.의 응용 프로그램을 사용한 객체 지향 분석 및 설계
• 4 명의 갱에 의한 디자인 패턴
• Kent Beck의 테스트 주도 개발
• Kent Beck의 익스트림 프로그래밍
• [Java의 경우] Joshua Bloch의 효과적인 Java

민첩하게

나는 다음을 제안 할 것이다 :

동일한 파일 편집

먼저 Git (또는 유사한 동시 버전 관리 시스템)을 사용하십시오. 동일한 파일의 다른 부분을 편집하는 한 충돌이 발생하지 않습니다. 충돌이 발생하면 명확하게 표시됩니다.

Git없이 멀티 개발자 프로젝트를 관리하는 것은 푸딩 보울없이 푸딩을 만드는 것과 같습니다. 가능하지만 꽤 지저분해질 것입니다.

의견에서 지적했듯이 Git은 만병 통치약이 아니며 자동화 된 테스트와 결합되어 확실히 큰 도움이됩니다.

모든 기능을 나열

둘째, 프로젝트를 사용자가 볼 수있는 기능으로 나눕니다. 예를 들어 "사용자가 가입 할 때 이메일을 받아야합니다"또는 "사용자가 항목을 추가 할 수 있습니다". 여기에 모든 이해 관계자를 참여 시키십시오. 방에있는 모든 사람을 데리고 모든 사람이 자신의 기능을 외치도록하십시오.

이들은 사용자가 볼 수있는 기능이어야하며 나중에 구현 전략에 대해 이야기 할 수 있습니다.

색인 카드, 심지어 멍청한 것들까지 모든 제안을 쓰십시오. 목록을 신속하게 합리화하여 중복을 제거하고 큰 카드 또는 바닥에 모든 카드를 배치하십시오.

필요한 추가 카드를 추가하십시오. 애플리케이션이 SMS 문자 알림을 전송한다고 가정합니다. 그렇게하는 방법을 모를 수도 있으므로 질문이 있습니다. 카드에 "SMS 포털 조사"를 작성하십시오. 다른 큰 미지의 경우에도 마찬가지입니다. 나중에 포장을 풀어야합니다. 이러한 기능은 아마도 첫 스프린트에 들어 가지 않을 것입니다.

이제 카드를 그룹으로 분류하고 섞어서 느낌 을 얻으십시오 . 이것이 프로젝트 범위입니다.

포커 계획

포커를 계획하십시오. 여전히 모든 사람과 함께 "1 점", "2 점"등의 모든 개발자 카드에 최대 "4 점"을 부여하십시오. 또한 "더 많은"카드. 포인트는 대략 1 시간과 같습니다.

기능 목록을 하나씩 살펴보십시오. 기능을 읽으면 모두가 카드를 재생해야합니다. 한 사람이 1을 재생하고 다른 사람이 4를 재생하면 통신 문제가 있습니다. 한 사람은 다른 사람과 다른 것을 의미하는 기능을 이해합니다. 토론하고 실제로 의미하는 바를 해결하고 카드에 적어 둡니다.

기능이 "추가"인 것에 동의하면 해당 기능이 너무 큽니다. 이 기능을 분해해야합니다. 이전과 같은 방법으로이 작업을 수행하십시오.

동의 한대로 카드에 다른 색 펜으로 숫자를 쓰십시오.

시간이 시간보다 낫다

시간 대신 포인트를 사용하면 개발자가 자주 참여하는 사소한 "코드 작성 속도"를 파악할 수 있습니다. 미묘한 차이가 있지만 실제로는 효과가 있습니다.

이제 스프린트를 작성하십시오

스프린트는 목표를 향한 빠른 파열입니다. 스프린트 길이, 아마도 5-10 일을 결정하십시오. 일 수에 개발자 수에 일일 포인트 수를 곱하십시오.

처음에는 개발자 당 하루 6 포인트를 가정합니다. 이것은 달성 가능한 숫자입니다. 5 명이 있다면 5 * 5 * 6 = 150 포인트입니다. 모든 개발자 및 관리와 함께 목록에서 최대 150 포인트까지 기능을 선택하십시오. 그게 당신의 스프린트입니다.

맞는 것보다 더 많이 짜내려고 유혹하지 마십시오. 지나치게 약속하면 장기적으로 모든 사람을 해칠 수 있습니다.

여기에서 종속성을 고려해야합니다. 예를 들어, 환경 설정은 분명히 첫 스프린트에 포함되어야합니다. 이것은 모두가 참석할 때 실제로 비교적 쉽습니다. 당신은 방에 6 개의 두뇌가 있고, "이것은 이것에 의존합니다"등을 말합니다. 그런 다음 카드를 뒤섞어 의존성을 보여줄 수 있습니다.

스프린트가 완료되면 아무 것도 추가 할 수 없으며 5 일 동안 잠 깁니다. 피처 크립은 팀에게 스트레스를주고 사기를 손상 시키며 모두를 느리게합니다. 결국 크리프는 프로젝트를 중단시킬 것입니다. 팀 리더는 팀을 피처 크롤링으로부터 보호해야합니다. 새로운 기능 요청이 들어 오면 다음 스프린트에 추가해야합니다. 다음 스프린트가 이미 가득 차면 다른 것을 꺼내야합니다.

엑스트라로 짜내려고 유혹하지 마십시오. 과잉 약속은 약 1 일 분량의 행복한 고객과 4 일 간의 팀 스트레스, 그리고 결국 팀이 제 시간에 전달할 수 없을 때 불행한 몇몇 고객을 제공합니다.

이제 가십시오.

카드를 나누어주고 누가 무엇을하고 싶은지 물어보십시오. 수행중인 작업을 완전히 파악할 수 있으며 점을 0으로 카운트 다운 할 수 있습니다. 매일 시작할 때 일어 서서 모든 사람이 누가 무엇을하고 있고 무엇을했는지 알 수 있도록하십시오.

명확하게 정의 된 관리 가능한 목표를 달성하기 위해 5 ~ 6 명의 동기 부여 된 개발자가 하나의 단위로 함께 작업하면 5 일 동안의 스프린트에서 꽤 많은 양의 물건을 얻을 수 있습니다.

가시성 유지

모든 사람이 프로젝트 상태를 확인할 수 있도록하십시오. 모든 카드를 벽에 붙입니다. 왼쪽에는 아직 작업하지 않은 카드가 있습니다. 오른쪽에는 카드가 있습니다.

개발자가 카드를 작업 할 때는 벽에서 꺼내 책상에 놓습니다. 이렇게하면 가시성이 유지되고 사람들이 발가락을 너무 밟지 않게됩니다.

색인 카드에 대한 기술적 대안이 있지만 벽에 프로젝트 상태를 대규모로 표시하는 것은 아무것도 아닙니다.

가능하면 프로젝트 기간 동안 모두 같은 방에 두십시오. 이해 관계자에게 가능한 한 매일 매일 이상적으로 의견을 제시하십시오.

타 버리다

번 다운 차트에서 0을 향한 점을 그래프로 표시 할 수 있습니다. 시간 제한에 도달하기 전에 가장 잘 맞는 선이 0을 넘어 가면 궤도에있는 것 같습니다. 그렇지 않은 경우 마감일에 너무 가까워지기 전에 지금 고객에게 알려야 할 수도 있습니다.

실패 할 경우 일찍 실패하십시오.

소프트웨어를 사용하여 번 다운을 할 수 있지만 벽에 큰 종이 조각을 선호합니다. 그 위에 모든 것을 그리고 쓰십시오.

자동화 된 테스트

여러 개발자가 동일한 작업을 동시에 수행하는 경우 때때로 서로의 코드를 손상시킬 수 있습니다. 의사 소통과 가시성에 도움이되지만 문제를 찾는 데 도움이되는 몇 가지 기술을 소개하려고 할 것입니다.

단위 테스트는 코드베이스의 각 개별 부분 (이상적으로 각 방법)에 대한 테스트를 작성하는 프로세스입니다. 가능하면 모든 저장과 함께 단위 테스트를 자주 실행해야합니다. Karma 또는 Rspec과 같이이를 도울 수있는 많은 도구가 있습니다.

엔드 투 엔드 테스트는 내부를 블랙 박스로 취급하여 프로젝트 전체를 테스트합니다. 이러한 테스트는 높은 수준의 비즈니스 요구 사항 (예 : "사용자가 가입 할 수 있음"또는 "사용자가 항목 목록을 볼 수 있음")을 기반으로합니다. 각도기는 엔드 투 엔드 웹 기반 테스트 프레임 워크의 좋은 예입니다.

테스트에 관한 책은 모두 있지만, 최소한 몇 가지 수락 테스트를 실시하면 프로젝트를 진행할 때 아무것도 깨지지 않도록 할 수 있습니다.

기술 부채 방지 및 완료

기술 부채는 나중에 정리해야 할 사항을 설명하는 개념입니다. 부채의 일반적인 원천은 완료된 것으로 표시되었지만 "완료"된 기능은 아닙니다. 완료된 기능은 Git에 체크인되어 이해 관계자가 승인했으며 테스트를 받았습니다.

완료 될 때까지 기능을 확인하지 마십시오. 그래프를 마사지하지 마십시오. 다시 말하지만, 이것은 당신을 포함하여 장기적으로 모든 사람을 해칩니다.

이것이 처음에 개발자 당 하루에 6 포인트 만 인용하는 이유 중 하나입니다. 완료 작업은 추가 작업이 필요하지만 기분이 좋으며 팀에게 힘을줍니다.

동일한 파일을 편집하는 것은 문제가 아닙니다. 동일한 기능을 편집하여 두 가지 다른 작업을 수행하는 경우에만 문제가됩니다.

기본적으로 내가하는 일은 프로젝트를 별도의 '기능'으로 나눕니다. 하나는 네트워크 프로토콜 처리와 관련이 있고 다른 하나는 구성 파일과 관련이 있고 다른 하나는 DB 처리와 관련이있을 수 있습니다. 기능은 큰 것입니다.

다음으로 이러한 기능을 작업 (스토리)으로 나누려고합니다. "사용자가 버튼을 클릭 할 때 프로그램이 파일을로드 할 것", "프로그램이 시작될 때 구성 파일을로드 할 것"등과 같은 간단한 것들이어야합니다.

일부 작업은 순차적으로 완료해야합니다 ( "프로그램은 구성 파일의 모든 필드를 구문 분석합니다"는 "프로그램이 구성 파일을로드 함"뒤에옵니다). 다른 사람들은 그렇지 않습니다 (DB와 네트워크에서 동시에 작업 할 수 있습니다).

그러나 아마도 당신은 그것을 잘못 할 것이고, 그것이 경험이 시작되는 곳입니다. 당신은 약간의 (또는 많은) 실패하고, 시간 추정을 잘못하고 프로젝트는 필요한 것보다 약간 더 많은 시간이 걸립니다. 다음에 더 나아질 것입니다.

또한 Kent Beck의 "Extreme Programming"을 읽는 것이 좋습니다. 프로젝트 관리자가 되려고했을 때 도움이 된 훌륭한 책.

응용 프로그램을 기능 모듈로 분류 한 다음 다른 모듈간에 계약 (인터페이스 및 데이터 계약)을 도입해야합니다. 그런 다음 각 모듈을 다른 개발자에게 전달할 수 있습니다. 모든 것을 다시 정리하면 계약서에서 이러한 모듈이 서로 올바르게 통신하는지 확인할 수 있습니다.

모듈이 모두 개별적으로 작동하도록하려면 개발자에게 TDD를 적용해야합니다.

내가 의미하는 바의 예를 들자면 :

개발자 중 한 명이 SQL 로거를 작성하기를 원한다고 가정 해 봅시다.

인터페이스를 정의하고 개발자 중 한 명에게 ( 또는 Agile을 사용하는 경우 스토리 작성 ) 다음 스펙에 따라 SQL 특정 로거를 원한다고 요청하십시오.

interface ILogger
{
    void Log(string message, int level);
}

그런 다음 개발자에게 기대하는 것은 다음과 같습니다.

1. 로거에 대한 SQL 특정 구현

   class SqlLogger : ILogger
   {
       private readonly SqlLogRepository _logRepository;
   
       public SqlLogger(SqlLogRepository _logRepository)
       {
           this._logRepository = _logRepository;
       }
   
       public void Log(string message, int level)
       {
           _logRepository.CreateLog(message,level);
       }
   }

2. 구현과 같은 모든 종속 코드 SqlLogRepository

3. 요청한 내용에 따라 단위 또는 모의 테스트. 위의 경우 (우리가 다른 외부 의존성이있는 경우) 모의 테스트 또는 예를 들어 간단한 유틸리티 함수 인 String.ReverseCharacters(string input)경우 몇 가지 시나리오를 테스트하는 단위 테스트를보고 싶습니다.

이것은 다음을 의미합니다.

귀하와 귀하의 팀은 이제이 인터페이스를 사용하여 개발을 계속할 수 있습니다. 예 :

class SomeModuleThatUsesLogging
{
    private readonly ILogger logger;

    public SomeModuleThatUsesLogging(ILogger logger)
    {
        this.logger = logger;
    }

    public void DeleteFiles()
    {
        logger.Log("user deleted files",1);
    }
}

그리고 코드를 작성하기 전에 코드를 실행 해야하는 경우 SqlLogger간단히 다음을 만들 수 있습니다 NullLogger.

class NullLogger : ILogger
{
    public void Log(string message, int level)
    {
    }
}

그리고 이것은 그 동안 테스트 할 수있는 방법입니다 (종속성 주입을 위해 ICO를 보는 것이 좋습니다)

void Run()
{
    var someModuleThatUsesLogging = new SomeModuleThatUsesLogging(new NullLogger());
    someModuleThatUsesLogging.DeleteFiles();
}

요약

나는 프로젝트의 규모에 대해 전혀 모른다. 그러나 이것은 어려운 작업이 될 수있다. 만약 당신이 이전에 개발 리드를 해본 적이 없다면, 당신은이 작업을 매우 진지하게 생각하고 다음 몇 주 동안 당신만큼을 읽는 것을 제안 할 것이다. 소프트웨어 디자인 및 아키텍처에 대한 수 있습니다. 그리고 매우 투명 작업 (약 등 소프트웨어 품질 ), 그렇지 않으면 당신은 빨리 나가 방법을 모르는 깊은 혼란에 자신을 발견 할 것이다.

또한 디자인과 객체 지향 패러다임을 읽으십시오. 이 프로젝트에서는 OOP에 크게 의존합니다.

다른 답변은 프로그래밍 측면에 대해 이야기했지만 프로그램 관리 측면을 언급하고 싶었습니다. 나는 면책 조항으로 시작할 것입니다. 저는 프로그램 관리자가 아닙니다. 프로그램 관리를 위해 대학원 수준에서 한 코스를 수강했으며, 업무 경험에는 보통 500 시간 미만, 1000 시간 미만의 소규모 프로젝트 입찰 시간이 포함됩니다.

그러나 2-4 개월 (파트 타임 및 풀 타임) 동안 2-3 명을 바쁘게 유지해야하는 실험실의 작업을 정의하는 데 도움이되었습니다. 실제로 Microsoft Project와 같은 프로젝트 관리 소프트웨어를 사용하는 데 도움이 된 한 가지 사항 (프리웨어 버전이 있는지 확실하지 않지만 고용주가 아마도 비슷한 것을 가지고 있습니다 ... 관리자에게 어떤 종류의 프로그램 관리 소프트웨어가 사용되는지 물어보십시오 회사에서). 특히, Gantt 차트를 꽤 많이 사용하는데 이는 Microsoft Project의 기본보기입니다. 모든 작업과 시간이 얼마나 걸릴지 정의함으로써 시각화 작업을 수행 할 수 있습니다.

간트 차트는 시각화 때문에 가장 도움이됩니다. 종이로 작업을 보는 것이 나에게 도움이되지는 않지만, 예쁜 그림과 차트를 보는 것이 확실히 도움이됩니다. 또한 Microsoft Project를 사용하면 선행 작업 및 시작 날짜를 설정할 수 있으며 "작업 X를 시작하는 데 필요한 최소 작업 수를 찾으십시오"라는 기본 개념이 있습니다. 최소한 나의 작은 프로젝트에서, '진정한'선행 작업의 양은 아주 적습니다. 사실, 한 프로젝트에서 거의 모든 것이 동시에 수행 될 수 있다는 문제가 있었고 다소 응집력이있는 두 개의 동시 경로를 합성해야했습니다. 예를 들어 개발자 A가 GUI를 만지면 GUI에 가까운 작업을 수행했는지 확인하려고했습니다.

펜과 종이가있는 한 이미 많은 일을하고있는 것처럼 들리지만 항상 Gantt 차트를 실제로 보는 것이 도움이됩니다. 순차적으로 정렬 된 작업을 살펴보면 "잠깐, 작업 X가 작업 Y보다 먼저 수행되어야합니까? (지금까지 경험상 얼마나 자주 대답이 '아니오'인지 놀랐습니다)"라고 생각하게합니다.

개발자에서 소프트웨어 엔지니어로 졸업 한 것 같습니다. 작업 관리는 디자인 연습이 아니라 두 사람이 함께 진행한다는 것을 인식하십시오. 수행중인 작업을 관리해야하며 이는 회사의 개발 방식에 따라 다릅니다. 시간과 자원이 있다면 민첩한 방법론을 사용하는 것을보십시오. 인터넷에는 수많은 서면 자료가 있습니다. 귀하에게 맞는 것을 찾으십시오. 그러나 다른 모든 것들과 마찬가지로 무료가 아닙니다. 모든 기술의 채택에는 성공하기 전에 교육, 학습 및 실패가 포함됩니다. 보다 포괄적 인 기술 채택을 처리 할 대역폭이 없다면 이정표 계획을 세우는 것이 답이 될 수 있습니다. 순차적 작업 목록이있는 경우 다음과 같은 시퀀스를 찾지 못한 경우가 있습니다.병렬화됩니다. 개발을 테스트 및 구현과 같은 일반적인 작업으로 분류하려는 경우도 있습니다. 그 자체만으로는보고 문제를 해결할 수 없지만 품질을 관리하고 있습니다. 귀하의 진행은 순차적 인 목록 일 수 있지만 귀하의 역할은 유사합니다. 그냥 제안입니다. 사람들이 수행 한 작업에 매핑되는 디자인을 작업 분석 구조라고합니다.

다른 사람들이 제안한 좋은 제안이 많이 있지만 작업을 관리하고 있음을 기억하십시오. 때로는 작업 개념을 디자인 / 아키텍처에 매핑 할 수 있으며 때로는 그렇게 쉽게 할 수 없습니다. 항상 작업을 추적 할 수 있도록 구조를 구성하는 방법이 있습니다. 관리자에게 돌아가서 프로젝트 상태를 알리는 데있어 무엇이 중요한지 물어보십시오. 그것은 당신이하고있는 일에 접근하는 방법을 알려주기 시작합니다. 일정이 일정하면보고 진행률에 집중하려고합니다. 품질이 좋은 경우 고려해야 할 일련의 측정 항목에 대해보고하려고합니다. 비용이 든다면 아마도 노력을 기울이기를 원할 것입니다. 이 모든 것들이 작업에 매핑되거나 작업에서 벗어날 수도 있습니다.