アジャイル開発手法あれこれ
アジャイルソフトウェア開発宣言と開発手法
さて、以前の記事で、
アジャイルとは、原理原則
スクラムとは、開発手法
ということを書いた。そして開発手法はスクラムに限らず色々ある。
スクラム
代表的な開発手法のひとつ。おそらく最も普及しているものだと思う。こちらの記事を参照させていただくと、その多さの一端が垣間見えるかもしれない。実際、ウェブで検索しても、書店で見て回ってもアジャイルといえばスクラム、というくらいの普及度合いかもしれない。
うちのチームでもスクラムを基本とし、複数チームなのでLeSS（Large Scale Scrum）のエッセンスを取り入れている。
特徴は何かとボトルネックになりがちなプロジェクトマネジメント領域をプロダクトオーナーとスクラムマスターと役割を明確に分けて、開発者と連携したチームを編成し活動するところだろうか。
スクラムについては、スクラムガイドを読んでいただくのが一番良い。
XP（エクストリーム・プログラミング）
スクラムと肩を並べる2大巨頭といった感じだったが、最近では影が薄いような気がする（ちなみに自分はスクラム以外は未経験なので的を外したことを書いているかもしれません）。
スクラムはソフトウェア開発の考え方から大きく飛躍し、研究者、アナリスト、科学者、その他さまざまな専門家が利用するようになり、それを意識したガイドになりつつある。
対してXPはソフトウェア開発にかなりフォーカスしたものに見受けら、テスト駆動開発、ペアプログラミング、リファクタリング、YAGNIといった開発プラクティスが提唱されている。開発者向けのプラクティスの他、管理者向け、顧客向けといったものもあり、「顧客もチームの一員」という考え方を持っていることが特徴的かもしれない。
かんばん
トヨタのジャストインタイム生産システムに影響を受け生まれたもの。ジャストインタイムとは、
生産過程において、各工程に必要な物を、必要な時に、必要な量だけ供給することで在庫（あるいは経費）を徹底的に減らして生産活動を行う技術体系。
というもの。似たような思想・方法論ではリーン生産方式、リーン思考、リーン・スタートアップなどがある。ようは顧客の価値の最大化のために最低限必要なことは何か？ ということを突き詰めることで無駄を極限まで削るという考え方と思っていいと思う。
そういう思想のもと扱われる手法だが、画像で見てもらったほうが「あーあれか」とわかりやすい。
他にもあるけど……
キリもないのでここらへんで。色々と異なる点がそれぞれの開発手法にはあるものの、アジャイルソフトウェア開発宣言の思想が色濃く反映されおり、共通した考え方もかなり多い。
シンプルなものが大半だが、エンタープライズアジャイルというアプローチもある。先ほどチラッと名を上げたLeSSもそれに付随する。
エンタープライズアジャイルとは
スクラムやXPなどは基本的に小さい規模のチームが対象であることがほとんどだ。複数チームや組織にまで広げた言及はほぼない。
大企業が小規模なプロジェクトやチームでアジャイルを行う分にはスクラムなどをシンプルに取り入れやすい。しかし、膨大な人数を抱える大規模なプロジェクトでアジャイルをやりたいであるとか、組織構造や機能そのものをアジャイル化したいとなった場合に活用される（らしい。これも自分は未経験）
どんなものがあるのか、ちょっと列挙してみる
Scrum@Scale
Large Scale Scrum
Scaled Agile Framework（SAFe）
Disciplined Agile Delivery(DAD)
自分の場合、人数規模的に10人は確実に超えるプロジェクトにアサインされ、アジャイルでやりたかったもののシンプルにスクラムを扱おうとするとコミュニケーション負荷増大を懸念したため、色々検討した結果LeSSの考え方を取り入れるようになった。
なぜLeSSを採用したのか
だいたいのことは下記の「何故LeSSなのか？」に記載されている。
何故 LeSSなのか? - Large Scale Scrum (LeSS)
自分たちの状況的には、
1チーム編成でスクラム開発をしていたところ、途中少し人数が増え、10人を超え、内部的に2つに分かれていた
このまま続けるとコミュニケーション等で問題が起こりそうだし、今後スケールさせる展望が見えなかった
そこで、まずは2チーム編成の活動を上手くいかせて、学びながら徐々にスケールさせるアプローチを取りたかった
という2考え方を持ち、色々と探した結果LeSSを採用した。その他の手法はなかなか難しそうに思えて避けた。
例えばScrum@Scaleは比較的導入しやすそうであったが、EATの定義と運用が難しそう、SAFeはDADは組織全体に波及しすぎていてボトムアップの導入が難しそう、と感じた。
LeSSは8チーム程度の規模感のものと、LeSS Hugeと呼ばれるさらに多い規模感のものに分かれた考え方となっていて、2チームでまずは学びながらというアプローチが取りやすいのでは？ と思った。
もうひとつ「LeSSにしてみよう！」と思った大きな理由は下記。
Large-Scale Scrumはスクラムである ー決して新しい物でも改善版でもない。LeSSはスクラムの目的、原理原則、要素を大規模開発で適応する為の物である。複数チームのスクラムであり、複数スクラムチームでは無い。
日本語の書籍があるのも嬉しいポイント。
非常にシンプルだし、従来のスクラムから置き換えるものではないので、スクラム経験のある人には馴染みやすいものだと思う。
すべてが完璧に扱えているわけではないが、参考にして日々少しずつ開発プロセスをアップデートしている。
この記事が気に入ったらサポートをしてみませんか？