Notionを使ってリモートで少人数スクラムで研究を進める
- Notionを使ってリモートで少人数スクラムで研究を進める
- アジャイルとは
- Agile の１２原則
- Agileの効果
- 研究になぜアジャイル？
- SCRUM（スクラム）とは
- スクラムの実践方法
- いざ実践！
- 研究内容について（どんなプロジェクトに対してアジャイルを実施するのか）
- 少人数✖️リモートのアジャイルは何が違うか
- チーム戦略
- 個人戦略
- 振り返りメモ
- ~12/14 Sprint 4 まで行った感想
- Q&Aメモ
- 作業時間を合わせた方がよいのか？
- 作業時間は決めた方がいいのでは？
- 少人数ならペアプロを採用した方が良いのでは？
- 参考文献
アジャイルとは
- 必要なモノを、全員で協力して試しながら、最速で開発・リリース・運用していくこと
- 競争的に変化するスペックや変化する顧客のニーズに対応してプロジェクトが進行するので完成した時には最新の成果物を提供できるような開発方法
- 不確実と上手く付き合う開発手法
- 人々が協働する力を最大限に活かして価値のあるソフトウェアを作り続けるための活動およびその方法論
筑波大学 Enpit ゲスト講義 「アジャイル開発概要&モブプログラミング」株式会社アトラクタ 永瀬 美穂 より
Agile の１２原則
The Agile Manifesto より
- 顧客満足を最優先し、価値のあるソフトウェアを早く継続的に提供します。
- 要求の変更はたとえ開発の後期であっても歓迎します。変化を味方につけることによって、お客様の競争力を引き上げます。
- 動くソフトウェアを、2-3週間から2-3ヶ月というできるだけ短い時間間隔でリリースします。
- ビジネス側の人と開発者は、プロジェクトを通して日々一緒に働かなければなりません。
- 意欲に満ちた人々を集めてプロジェクトを構成します。環境と支援を与え仕事が無事終わるまで彼らを信頼します。
- 情報を伝えるもっとも効率的で効果的な方法はフェイス・トゥ・フェイスで話をすることです。
- 動くソフトウェアこそが進捗の最も重要な尺度です。
- アジャイル･プロセスは持続可能な開発を促進します。一定のペースを継続的に維持できるようにしなければなりません。
- 技術的卓越性と優れた設計に対する不断の注意が機敏さを高めます。 （不断の注意..＝ずっと意識することが重要）
- シンプルさ（ムダなく作れる量を最大限にすること）が本質です。
- 最良のアーキテクチャ・要求・設計は、自己組織的なチームから生み出されます。
- チームがもっと効率を高めることができるかを定期的に振り返り、それに基づいて自分たちのやり方を最適に調整します。
Agileの効果
研究になぜアジャイル？
Wikipediaによれば、研究とは物事についての事実あるいは真理を追求する一連の過程のことです。分からない状態をわかる状態にする、と考えれば知識の不確実性を下げる行為であり、これはアジャイルにかなり近いです。
最近の情報系（特に機械学習やVRなど先端技術を使ったもの）の応用研究はエンジニアリング部分がかなり多いので、純粋に研究＝エンジニアリングのプロジェクトとして考えることもそこまで間違ってるとは思いません。
下記の図では不確実性の大きさを「論文が書けるまでの期間」として見ています。エンジニアリングヘビーな研究プロジェクトでは、計算実験を通して効率よく不確実性を減らしていけるのかが重要です。
SCRUM（スクラム）とは
不確実なことを減らすためには、1番不確実なことから確かめていくことです。そうすれば、早く解決できるので、1番早く問題解決できます。... それは「言うは易し行うは難し」の典型例 ... 人間には、恐怖から逃げる仕組みが用意されているので、なかなか抗うことができません。
「1人でできないのであれば、複数人でやれば良い」と考えると少しだけこのことが簡単になります。現実を直視し、不安に向きあえるようにチーム全体が個々人をサポートしていく状態になれば、仕事における不安に向き合うことができるようになります。...
スクラムはいつどのようにチームが課題と不安に向き合うのかを規定して、改善を行うためのタイミングを強制するためのフレームワークである ... つまり、... 「不安への向き合い方」をチームが学習するための方法論です。
エンジニアリング組織論への招待 広木大地 より抜粋
スクラムの実践方法
スクラムの具体的な実践方法は以下のスクラムガイドに全て書いてあります。
アトラシアンのウェブサイトも参考になります。
実践方法を詳しく知るためにはスクラムガイドの全文をぜひ読んで頂きたいですが、ここではイメージを掴むために概要を書きます。
- スクラムマスター
- スクラムイベントのファシリテーション
- 不安の解決を促す
- プロダクトオーナー
- プロダクトバックログの作成
- 何を作るかの決定権
- 開発チーム
- プロダクトバックログの要件をどのように作るべきかの決定権
- スプリント
- 作業する期間
- スプリント計画
- タスクの分解
- 実現方法の検討
- 課題点の洗い出し
- デイリースクラム
- 作業を始める前に前日までの課題を簡潔に話す会議
- 全員が立った状態で会話するのが望ましい
- スプリントレビュー
- プロダクトオーナーが中心となる振り返り
- レトロスペクティブ
- ちょっと時間をかけてチーム全体が振り返りを行う
- 開発チームが中心
以下のブックマークより引用
いざ実践！
研究内容について（どんなプロジェクトに対してアジャイルを実施するのか）
少人数✖️リモートのアジャイルは何が違うか
アジャイルは基本的には3人以上で実施するのが普通であるが、このプロジェクトでは2人で実施していく。
少人数×リモートチームの特徴
- コミュニケーションコストが低い
- 非同期で作業しやすい → 非同期で作業することが多くなる
- マンパワーが少ない
Agileについての宝庫→Henrik Kniberg
チーム戦略
実行するスクラムイベント
- デイリースクラム
- スプリント・レトロスペクティブ
- スプリント・プランニング
個人戦略
自分は２つのバイトと大学院の課題でホワイト企業に勤めている社会人と同じくらいのスケジュールでやってます。大体9:00~18:00を除く時間をこのプロジェクトに割くことなります。
自分は月・火・水・木の4日、19:00~22:00の時間を使うことにしました。火曜日は研究室のオンラインゼミが18:15~20:00まであるので、エフォートは50%程度だと考えています。頑張れば12時間以内には終わる量のタスクを自分で割り振って、終わらなければ金土日で延長戦って感じです。
月
19:00 ~
Sprint Review
Retrospective
Sprint Planning
🍅 20:00 ~ 20:40
🍅 20:45 ~ 21:25
🍅 21:30 ~ 22:00
⇨ review commit etc.
火
18:15 ~ 20:00
ゼミやりながら作業
🍅 20:00 ~ 20:40
🍅 20:45 ~ 21:25
🍅 21:30 ~ 22:00
⇨ review commit etc.
水
19:00 ~ Daily Scrum
🍅 20:00 ~ 20:40
🍅 20:45 ~ 21:25
🍅 21:30 ~ 22:00
⇨ review commit etc.
木
19:00~ Daily Scrum
🍅 20:00 ~ 20:40
🍅 20:45 ~ 21:25
🍅 21:30 ~ 22:00
⇨ review commit etc.
鬼のようなハードスケジュールを自分に課すので以下の工夫を凝らしました。
- Leverage Momentum
Keep track of my velocity.
- Pomodoro Timer
年39ドルと値は張るけどこちらのアプリはほとんどのiOSデバイスに対応に対応していて使いやすかったです。
- Look after myself + Acknowledge Burnout
振り返りメモ
~12/14 Sprint 4 まで行った感想
- タスクベースかつ、時間を合わせないとタスクが毎回終わらないと不満が溜まりやすい
- 作業時間に不確定要素を含む場合は、サボってるのか、本当に時間がかかっているだけなのかが判別しにくいので、（残念ながら）作業した時間が分かるようにする必要がある。
- 始めはチームの学習が足りない状況であったり、開発環境に急な変更が多くて、どのタスクも不確定要素が大きいのでスクラムがワークフローに適していないと思った。
- ある程度プロジェクトが進み、いわゆる叩き台ができるまでは、書き直し覚悟でとにかくコーディングを進めていくべき。コードベースが複雑になる手前から一旦整理してから、コードを書くようにすれば良い。Formatter, Linter, Documentationなら所要時間の予測がつきやすいし、スクラムはそこから始めれば良さそう。
- githubを使うと良さそう。
- NotionからGithubに移行して使っていくようにしてみる。
以下を参考にしてみた。
Keep track of my health with various health trackers.