はじめてのPHPプロフェッショナル開発 ch11 チーム開発の現場
個人開発とチーム開発の違い
- 独りで完結しない
- 「見える化」の必要性
- コミュニケーションの必要性
- 1+1=3以上になったり2未満になったり
- 良いチームとは
- 「見える化」がうまくできていること
- よいコミュニケーションがとれていること
- 便利なツールや仕組みに「乗っかる」ことで一定程度のチーム開発の質を担保できる
個人 | チーム | |
---|---|---|
ドキュメント | なくてもあまり困らない | ないと必ず困る |
進捗 | 自分がわかればOK | 他人に見せる必要がある |
コミュニケーション | 存在しない | 避けられない |
不確実性 | 低い(1+1=2) | 高い(1+1=?) |
ブルックスの法則
- 人月の神話で有名なやつ。
遅延のリカバリのためにメンバーをアサインしても逆効果- タスクの並列化には限界がある
- 妊婦が9人いても赤子を1ヶ月では出産できない
- 人をアサインすることによるコスト
- 学習コスト
- コミュニケーション(nC2)
- タスクの並列化には限界がある
GitHubを使った課題の「見える化」
- Gitのホスティングサービス
- コード管理以外の機能が充実
Issueの作成
- 「問題」「課題
Issueの基本的な書き方
- md記法使える
新機能の書き方の例
- ゴールデンサークル理論をベースに記載するとよい
- 「なぜから始めよう -- 優れたリーダーはいかに行動を奮い起こさせるか」
Simon Sinek (2009) - Why -> How -> What
- 「なぜから始めよう -- 優れたリーダーはいかに行動を奮い起こさせるか」
- なぜやりたい
解決したい課題(Why)- 質問と投稿以外のコミュニケーション手段を増やしたい(いいね)
- 解決する方法・手段(How)
- 質問にいいねが出来るようにする
- 実装する仕様(What)
- 質問をいいねすることが出来る機能
- KPIなどの目標数値
- DAU(Daily Active User)2%増加
- スケジュール
- 3末リリース
不具合修正の書き方の例
- 不具合の詳細
- 投稿ボタンをタップしても何も起きないことがある
- 再現手順
- 質問一覧画面から質問投稿画面へ遷移する
- どうのこうの
- OSやバージョン
(環境依存ならば) - 発生時期
- 3月上旬のリリース後の発生するようになりました
フォーマット
- Issueのフォーマットをつくれる
- リポジトリ直下の
ISSUE_TEMPLATE.md
- リポジトリ直下の
Issueの発展的な使い方
Assign機能
- 担当者指定
- ボールがこぼれ落ちて誰も対応していない…という自体を防ぐ
Label機能
- 分類
- bugとかfeatureとか
Milestone機能
- 期限設定
- Label同様、分類に使用できる
コメント機能
- Issueに関する不明点を質問するなど
GitHubを利用するメリット/デメリット
- メリット
- コード管理を一体となって課題管理できる
- デメリット
- GitHubの課題管理機能は、他ツールと比べて決して豊富ではない
- バーンダウンチャートない
- ストーリーポイントない
- GitHubの課題管理機能は、他ツールと比べて決して豊富ではない
- コード管理をGitで行っていないならメリット薄い
- コード管理をGitで行っているならぜひ
Slackを使った日々のコミュニケーション
Slack | メール | |
---|---|---|
即時性 | 高い | 低い |
同報性 | 手軽 | やや手間 |
拡張性 | 高い | 低い |
コミュニケーション | カジュアル | フォーマル |
よりSlackを使いこなすために
- リマインダー
- 外部サービスとのインテグレーション
- GitHub
- CircleCI
- etc.
ツールの選定方法
- ツールに溺れぬよう
- 手段が目的にならぬよう
- テキストコミュニケーションはあくまで対面よりも情報量に劣る
- リモートワーク等で、非同期でコミュニケーションを取らざるをえないならば積極的に使おう
- 今fitしているツールが未来永劫そうとは限らない
- チームに必要なツールを見極める技術が肝要