個人開発とチーム開発の違い
-
独りで完結しない
- 「見える化」の必要性
-
コミュニケーションの必要性
- 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やバージョン
(環境依存ならば)- iOS 12.1 Safari
-
発生時期
- 3月上旬のリリース後の発生するようになりました
フォーマット
-
Issueのフォーマットをつくれる
- リポジトリ直下の
ISSUE_TEMPLATE.md
- リポジトリ直下の
Issueの発展的な使い方
Assign機能
- 担当者指定
- ボールがこぼれ落ちて誰も対応していない…という自体を防ぐ
Label機能
- 分類
- bugとかfeatureとか
Milestone機能
- 期限設定
- Label同様、分類に使用できる
コメント機能
- Issueに関する不明点を質問するなど
GitHubを利用するメリット/デメリット
-
メリット
- コード管理を一体となって課題管理できる
-
デメリット
-
GitHubの課題管理機能は、他ツールと比べて決して豊富ではない
- バーンダウンチャートない
- ストーリーポイントない
-
- コード管理をGitで行っていないならメリット薄い
- コード管理をGitで行っているならぜひ
Slackを使った日々のコミュニケーション
| Slack | メール | |
|---|---|---|
| 即時性 | 高い | 低い |
| 同報性 | 手軽 | やや手間 |
| 拡張性 | 高い | 低い |
| コミュニケーション | カジュアル | フォーマル |
よりSlackを使いこなすために
- リマインダー
-
外部サービスとのインテグレーション
- GitHub
- CircleCI
- etc.
ツールの選定方法
-
ツールに溺れぬよう
- 手段が目的にならぬよう
-
テキストコミュニケーションはあくまで対面よりも情報量に劣る
- リモートワーク等で、非同期でコミュニケーションを取らざるをえないならば積極的に使おう
- 今fitしているツールが未来永劫そうとは限らない
- チームに必要なツールを見極める技術が肝要