2021_1か月という短期間開発におけるスクラムの有用性

2021年3月に開催されたAgile PBL祭りでの登壇資料です。

Transcript

1. Agile PBL 祭り 1か月という短期間開発における スクラムの有用性 公立はこだて未来大学 野間 直生, 鈴木 利武, 久末 瑠紅 ※本資料を無断複製・使用する行為を禁じます
2. 自己紹介 • メンバー ◦ 野間　直生（naoki） ◦ 鈴木　利武（TomSuzuki） ◦ 久末　瑠紅（Hisa） • 所属 ◦ 　 公立はこだて未来大学 システム情報科学部
3. 私たちについて アジャイル・スクラムの定義 スクラムガイドに使われてみた場合 私たちの活動を振り返って まとめ 目次
4. 所属プロジェクト • 正式名称 ◦ ビーコンIoTで函館のまちをハックする - Beacon FUN 4 • 目的 ◦ ビーコンを函館のまちの様々な場所に設置し，そのビーコンを 活用したサービスを開発 ◦ それにより，新たな価値を生み出し，利用者にこれまでにない 体験や魅力を提供 • ビーコンとは ◦ スマートフォンで受信可能なBluetoothで通信を行う小さなデバイス ◦ バッテリー消費の少ないBLE (Bluetooth Low Energy) を採用 ◦ ビーコンから受信端末までの距離の計測、個体の識別が可能
5. ビーコン実機 @金森倉庫 in 函館
6. 開発したサービス
7. https://beaconfun4.github.io/Final-Movie/ プロジェクトの紹介サイト
8. なんとなく プロジェクトの雰囲気 は 分かってもらえましたか？
9. 私たちについて アジャイル・スクラムの定義 スクラムガイドに使われてみた場合 私たちの活動を振り返って まとめ 目次
10. アジャイルとは 私たちは、ソフトウェア開発の実践 あるいは実践を手助けをする活動を通じて、 よりよい開発方法を見つけだそうとしている。 この活動を通して、私たちは以下の価値に至った。 プロセスやツールよりも個人と対話を、 包括的なドキュメントよりも動くソフトウェアを、 契約交渉よりも顧客との協調を、 計画に従うことよりも変化への対応を、 価値とする。すなわち、左記のことがらに価値があることを 認めながらも、私たちは右記のことがらにより価値をおく。 - アジャイルソフトウェア開発宣言より
11. チームにとって最善の環境で サービスを作り続けたい
12. スクラムとは • 複雑な問題に対応し、価値を生み出すためのフレームワーク • チームは、経験主義とリーン思考に基づいて活動 ◦ 経験主義：知識は経験から生まれ、意思決定は観察に基づく ◦ リーン思考：無駄を省き、本質に集中する • チームは自己管理型であり,「誰が」「どのように」「何の」 作業をするかを選択できる - スクラムガイドより
13. 私たちについて アジャイル・スクラムの定義 スクラムガイドに使われてみた場合 私たちの活動を振り返って まとめ 目次
14. 各スプリントの取り組み Sprint 0 • チーム内での目標と目標への取り組み方の統一 • MET.のMVP(Minimum Viable Product)と機能を決定 • プロダクトバックログの作成 Sprint 1-4 • 1週間を1スプリントとして開発に取り組んだ • Sprint 4の途中でMVPが完成
15. 通常のスクラムと異なる部分 • バックログ項目が、通常より詳細である ◦ MVPまで計画を立てた ◦ メンバーが経験不足だったため、先の見通しが定かでなかった ◦ バックログ項目を詳細にすることで不安を取り除きたかった
16. 振り返って 達成できたこ と • 期限内にMVPを完成させることができた ◦ 完成できるかわからないという不安は緩和された ◦ メンバーが3人であり、仕様変更に対応しやすかった 課題 • 計画に時間がかかった ◦ MVPまでの計画に1週間を要した（1日2時間） • 仕様変更が高頻度で発生した ◦ 計画を立て直すために時間を使った 解決策 • 目前のバックログ項目のみを詳細化することで解決できたかも？
17. フレームワークに使われるのではなく 自分たちにあった形で開発を行う ことができた
18. 私たちについて アジャイル・スクラムの定義 スクラムガイドに使われてみた場合 私たちの活動を振り返って まとめ 目次
19. スクラムガイドに使われてみた 課題 • 経験主義をする上で私たちは未熟である • 期限が決まっている課題に対し、バックログ項目(タスク)が 詳細化されてないことは不安 結論 • バックログに修正がなければ完成する？ • MVPがもう少し小さくできるのであれば完成する？
20. 私たちについて アジャイル・スクラムの定義 スクラムガイドに使われてみた場合 私たちの活動を振り返って まとめ 目次
21. まとめ • スクラムは、経験主義で意思決定を行う →メンバーが知識や経験を持っていることが前提条件 • 期限が決まっている課題に対し、バックログ項目 （タスク）が詳細化されてないことは不安 知識や経験が不足し、期限が決められた開発において スクラムは有用ではない のかもしれない 重要なのは 自分たちに合ったスタイルで活動すること
22. 通常のスクラムと異なる部分 • バックログ項目が通常より詳細 ◦ MVP (Minimum Viable Product) までは，ほぼ計画を立てた ◦ 開発経験が豊富ではない ため，先の見通し が難しい ◦ 多少ウォーターフォール的 に行わないと，不安だった
23. 細かくしてみた結果 • 振り返ると，詳細にしすぎた感があった ◦ 計画に時間がかかった ◦ 途中で数回仕様変更が発生 ▪ 計画を立て直す必要性 がうまれた ▪ バックログの粒度を粗くし，詳細化をこまめに行うべき だったかもしれない？　　 • 不安をなくすためには良い策であったとも考えられる ◦ どれが正解かは分からない フレームワークに使われるのではなく， 自分たちにあった形で開発を行うことができた
24. 各スプリントの取り組み Sprint 0 • 自己組織化 チーム内での目標と目標への取り組み方の統一 • ユーザーストーリーの作成 MET.のMVP(Minimum Viable Product)と機能を決定 • バックログの作成 バックログ項目が通常より詳細なバックログの作成 Sprint 1-4 • 1週間を1スプリントとして開発に取り組んだ • Sprint 4の途中でMVPが完成