エンジニアとして仕事をしてから7〜8年立ちましたが、その間９割近くはいわゆるアジャイル開発でやってきたと思っていました。今は比較的大規模な開発をしておりますので、ウォータフォールですが・・・
が、先日ある本を読み、今までやってきたものが全然、アジャイルではないと実感しました(汗)。
自分の認識だと、
ウォーターフォール
要件定義〜設計〜実装〜テストなどのプロセスをしっかりへて、プロダクトを作っていく。
アジャイル
ドキュメントなどがあまり存在しておらず、スピード重視で、モックのプロダクト作成→フィードバックを繰り返して完成形に近づけている
のような認識でいました。
読んだ本は、「いちばんやさしいアジャイル開発の教本 人気講師が教えるDXを支える開発手法」 という本なのですが、すごく良くまとまっていていており、感銘を受けました。
以下にポイントを書かせていただきます。
- システム開発において、机上論だけで完成品を求めるのは難しい(機能の6割は使われない)
- アジャイル形式は上記のようなソフトウェア開発における不確かさを吸収し、変更を歓迎する手法である。プロダクトを成長させて、改善させていく思想。
- プロダクトの着地点を見失しなってしまうというリスクもある(永久に作り直しをするなんてことが・・・)
- 開発単位は「価値を提供できる最小限のプロダクト」を「小さく(インクリメンタル)すばやく(イテレーティブ)作ること」(要件定義〜設計〜実装〜テスト)フローを細かく回転させる。アジャイルの開発期間をスプリントといい、１〜4週間程度が一般的。
- そのために大事なのがチーム作り、タスクの見える化(やること、やっていること、やったこと)を行う、タスクを細かく最大でも1日単位にする。
- 細かい改善をしていく上でプロダクトの品質を担保していくのが、テスト自動化。細かく、頻繁なリリースを行うので、テスト自動化しておく必要がある。
- チーム内のフィードバックが最重要。日にち単位で会議を行う(細かいフィードバックする)必要があるが、会議などが形骸化し、「問題ありません」などの発言が出てくるようになったら危険。
- スプリントごとにKPTを設定する。Keepは良かったので継続すること、Problemは悪かったことで問題だと思ったこと、Tryは次に実行することをフィードバックし、チームを改善、成長させていく必要がある。
- モブプログラミング(複数の人の視点を受けながら、コードを書くこと。ペアプログラミングの多人数版)などもフィードバックを受ける手法の１つ。
- ドキュメントの不在などが言われることがあるが、あくまで手段なのでドキュメントがないわけではない。
- プロダクトを成長させるという思想から準委任契約(時間)の方が親和性がある。
振り返ってアジャイルの思想を全く理解してなかったなあ・・・と思いました。
アジャイルというか正直いうと低予算だったので要件定義〜設計の時間を端折った「低予算開発」というのが実態でしたね・・・
それはそれで楽しかったのですが・・・今後アジャイル開発をする場合は上記のような設計の思想をしっかりとり入れて行いたいと思います。
