대규모 개발에 관한 프로젝트 관리

많은 사람들이 개발할 때 PM으로서 몇 가지 학습과 방법이 있기 때문에 ROM을 저장한다.
관리자 수가 너무 많으면 이곳의 기초 지식력과 운용력의 육성과 수출의 품질 관리가 매우 어렵다.
임무 입도의 통일화와 사전 조사의 질을 높이고 평론가들이 개인 성과의 질을 쉽게 확인하며 QA의 재작업을 줄여 교류의 부담을 덜어주기 위한 것이다.
포인트는 티켓과 Github의 운용에 집중된다.

도구

・ JIRA/Backlog 등
・Github

조작하다

어음의 운용은 디지털화를 기본으로 한다

프로젝트 관리자는 부모 표를 끊은 후에 분자 임무를 분해하여 작은 표를 끊는다.
엔지니어가 필요한 조건과 작업 내용을 작성하기 위해서는 엔지니어가 스스로 입장권 내용을 작성하는 것이 가장 좋다.
쓸모없는 스타일북을 쓰지 않는 개발에서 입장권의 기재 내용이 모두 바뀌기 때문에 서열도와 API의 INPUT/OUTPUT도 사전에 상세하게 정의해야 한다.
이번에는 Rails를 이용한 예를 들겠습니다.
그리고git의 요청에서

# 要件
  このチケットで何を実現したいのかを明確にします。
  例: 顧客管理CMSの〇〇の機能を追加

# 対応内容
  実際に発生するタスクを箇条書きにします。
　例: 1. モデルの作成
　例: 2. コントローラーの作成
　例: 3. 設定項目をyml化

# 仕様
  例: 
  - ER図 (画像やファイルへのリンク)
  - シーケンス図 (画像やファイルへのリンク)

# テスト要件
  テストコードを記載するための定義をします。

# 影響のでるスコープ
  コードを洗いざらい調査して今回の修正にたいする影響範囲を記載します。
  例: 顧客管理CMSの〇〇画面: http://sss/hohoge
  例: 顧客管理CMSの〇〇画面: http://sss/hohoge

Github의 운용에 관해서는 두 가지가 있다.

모든 지점을 관리하고 코드 심사, 통합 및 배포를 관리하기 위해 RM(스토리지 라이브러리 주체) 직무를 설정합니다.
저는 이 RM을 아웃소싱해 왔지만 RAILS에 대한 지식이 풍부하지 않은 엔지니어와 GIT에 익숙하지 않은 사람이 들어가면 충돌하고 반복적으로 논평을 하기 때문에 RAILS의 체계 구조를 이해하거나 없어도 조사할 수 있는 전제에서 하는 것이 좋습니다.
댓글에 대한 RM의 부담이 커지기 때문에 대등한 댓글 등에서 어느 정도 파괴가 전제된다.

A. 각 제품의 활용

　　master > develop > productname_base
                            └　TicketNO
　                            └TicketNO
　                            └TicketNO

1) 마스터에서 개발자 지점 만들기
2) 개발자 지점에서 온 productname_베이스 브랜치 만들기
3) productname_기본 파일에서 티켓 기능 지점 만들기
4) 제품 개발 과정에서 항상 PULL base 브랜치를 티켓 브랜치에 반영
5) Ticket 소화 후 base 브랜치에 병합
6) 각 QA 기능에 대한 base 분기 배포

B. 각 이정표의 활용

중요한 것은 이정표에 너무 많은 기능을 채우지 말라는 것이다
주로 오류 수정과 단순 수정 등 유지보수 개발에 사용되는 모델이 좋다.

　　master > develop > v1.2_base
                     └　TicketNO
                     └　TicketNO
                     └　TicketNO

1) 마스터에서 개발자 지점 만들기
2) develop 분기에서 v1.2_베이스 브랜치 만들기
3) v1.2_기본 파일에서 티켓 기능 지점 만들기
4) 제품 개발 과정에서 항상 PULL base 브랜치를 티켓 브랜치에 반영
5) Ticket 소화 후 base 브랜치에 병합
6) 각 QA 기능에 대한 base 분기 배포

C. 라식 요청

표에 기재된 내용에 관해서는 플루릭에 써서 레비와 QA가 무엇을 했는지 알려 주십시오.
단원 테스트 방법(rspec의 실행 명령과 결과 등도 명확하게 써야 함)
증거를 남겨두면 수중의 질을 최대한 높일 수 있다.
실제로 상기 표를 바탕으로 아래의 플루릭을 제작해 주십시오.
Input와 Output의 일치성을 얻었기 때문에 쉽게 논평할 수 있습니다.

## Original Ticket
https://app.asana.com/0/1135737104421279/1135753753843125

## 要件
- [ ] 1. モデルの作成
- [ ] 2. コントローラーの作成
- [ ] 3. 設定項目をyml化

## 対応内容
- [ ] 1. AaaModel,BbbModelを作成しアソシエーションの設定をしました
- [ ] 2. XXXコントローラーの作成、CCCヘルパーの追加と、Concernの追加
- [ ] 3. 表示項目AAをyml化

## テスト方法
- [ ] 1. 作成したModelのテスト結果
- [ ] 2. 画面のフィーチャーテストの結果

## テストエビデンス
スクリーンショット/APIレスポンスなど

## コメント
上記の対応方法で問題ないかご確認お願いします。

## 影響範囲
http://hoooogeg/page/index
http://hoooogeg/page/confirm