リモートワークとプロジェクトマネジメント
TOC
リモートワーク下のプロジェクトでの課題
- 詰まった時に一人で抱えてしまうメンバーの「困ってる」が見えづらい
- 専門外の技術の話を聞ける機会がない
- 議論されないまま、仕様や設計が決まってしまう
プロジェクトの進め方
目標
- リモートワークで見えづらい進捗の遅れを改善する
- 全員がプロジェクトのコードに触れる機会を作る
- 仕様決定の属人化を防ぐ
どうするか
- ペアプログラミングを行う
- ペアは1日ごとに変える
- 個人ではなくペアがタスクを担当する
- ペアのメンバーは1日単位で変わるので、引継ぎのためドキュメント作成を行う
ペアプログラミングとは
- 2人で同じ画面を見ながら、プログラムを組む
- リモートワーク下では、1人がエディタを表示、その画面を画面共有する
- エディタ以外にも視覚的にツール
- もう1人は、共有された画面を見ながら、設計や周辺調査・コード指示をする
分担例
ペアごとの役割分担の最適解を見つける
項番 | メンバー1 | メンバー2 |
---|---|---|
ペア1 | コードを書く | 設計をする |
ペア2 | コードを書く & 設計する | レビューする |
ペア3 | コードを書く | 設計する & コードを詳細に伝える |
ペア4 | コードを書く & 設計する | ドキュメントを作成する |
ペア5 | コードを書く& 設計する & 詳細に説明する | レビューする |
ペア5 | コードを書く | テストを書く |
メリット
- 仕様が全体共有され、欠員リスクが低い
- 常にコードを確認しあうので、レビュー時間の短縮ができる
- 進捗の出せないタスクを抱え込まない
デメリット
- 慣れるまで進捗がでない感覚が辛い
- 疲れる
- 相性がよくないメンバーがいる
デメリット問題にならないよ
慣れるまで進捗がでない感覚が辛い
- 慣れればでスピードが出てくるので、それまでは経営層に理解してもらいます
- 仕様の認識違い減少・良い設計・レビュー工程のスキップなど
疲れる
- ペアで自由に休憩とってOK
- 自分が疲れてきたらペアも疲れてると思って、休憩を提案しよう
相性がよくないメンバーがいる
- 毎日ペアが変わります
- 今日はうまくできなくても、明日はうまくできるはず
行動指針
- 常にどちらかの画面を共有し、コミュニケーションの補助にしよう
- 小休憩をこまめにとろう
- 昼休憩を一緒に取らざるを得ないので、相手のスケジュールを確認しよう
- プロジェクト外のタスクがある時には、相手に伝えてからやろう
- 話しかけても、レスポンスがないと心配になります
ツール
通話 & 画面共有
- Slack 通話
- screen.so
ホワイトボード
ドキュメント
esa
ペアがいない時
休暇や他のタスクをやっているなどペアがいない時には…
やらないほうがいいこと
-
コードを書き進める
- レビュー工程を軽くするためにペアを組んでいる
- 仕様の属人化を回避するためにペアを組んでいる
-
当日中にペア内で共有できる場合に限り、1人でタスクを進めてOK
- ペアが作れなかった場合は、朝時点で共有する他ペアを決める
何ができるか
-
仕様を検討する
- ドキュメントを作成して、後で合意を取れるようにする
-
ドキュメントを整理する
- 決定した仕様を抜け漏れチェック、テキストに起こせていないことを補足する
- 既存コードとの関連を追記する
- クラス図、アクティビティ図などのUMLを書いておく
-
リファクタリングの検討をする(TODO: FIXME: などのコメントを書いておく)
- 自分たちが書いた箇所
- 周辺の既存コード
-
他ペアに参加する -> 3人になるとうまくいかないかも
- 仕様を事前に把握しておく
- レビューに参加する
- 小休憩タイミングなどのタイムキーパーをする