アジャイルを学ぶの巻
アジャイル・・あじゃいる・・agile・・
IT業界に身を置いてると意識せずとも聞こえてくるWord・・
形容詞なのに、ちまたでは、動詞や名詞として使われがちです・・
そして勤めているSIerではアジャイルは禁止されています。
これまでアジャイルな開発(でも実態はそもそも最初から入札、請負契約というアジャイル風だった…)に手を出しては、もはや顧客の奴隷のようになり、赤字という顛末のPJが多かったからです (｡´Д⊂) ｳﾜｧｧｧﾝ
このツイートが身に染みる、そんな状況です。
なのでスキーム変えられないうちは「禁止」という判断は正しい気がします。
最近とても勉強になってるんですが、ウォーターフォールのスキームの一部にアジャイルいれても赤字になるのです、黒字にしたいならスキーム変えないとだめなのよ
— Yasuko Ohbaさん (@nay3) 2013年4月25日
でもやっぱり気になっていたところに、ちょうど開発者ではなくとも学べる「LEGO®ではじめるスクラム入門」というイベントがTLに流れてきたので、参加してきました！
ちょうど@kakutaniさんに「アジャイルプラクティス」をご恵贈して頂きましたので、
こちらを読んでから臨みました。（レビュー書かせて頂きました♪）
※有料の研修ですので、内容に関しての公開レベルはDoorkeeperレベルに合わせたいと思います。
ザックリ言うと複数班に分かれて、顧客と開発を相互に担当し、
スプリント→顧客レビューを4回繰り返します。
テーマは「街作り」！
当然ながらLEGOで作るのですが、最初は顧客側の要求イメージも、その要求を聞いた開発側も、頭の中はこんなイメージ。
LEGOと言えばという・・・
でも、最終的にはこんな感じ。
写真は@publichtmlさんにお借りしました♪
想像と実際の違いはなかなかのものですよね？
実践して感じたスプリント開発のメリットを挙げてみます。
①開発側
顧客のOKレベルがわかり、力の入れどころ、見せ方、そして手の抜きどころがわかる！
スプリントを重ねるにつれ、顧客のOKの判断レベルがわかり、簡易なものになっていきました。なので最初に機能の見積もりを行いましたが、現実とは相違がありました。
また、班での話し合いが短時間でありながらも何度もあるので、徐々に会話が増えていき、楽しかったです。更に同じ班にスクラム認定マスターの@irohirokiさんがいらっしゃったので、より本格的な方法を学べました。ありがとうございます(人´ω｀)
②顧客側
開発班のレベルがわかる。得意不得意分野がわかる！
例えば他の参加者の方のブログ、うちが顧客として開発をお願いした班の方だと思われるのですが、引用させて頂きます。
「スプリント後に顧客からの追加要望が出てきても、
実際に顧客に既存の要望と一緒に並べ替えると、
新規の要望は大体下の方に来ている、というのが多かった。
これは結構意外で、実務で同様のことが起きているかと思うと結構ゾッとする」
確かに実際形になっているものの追加要望は順位として低めでした。
もう一応形になってるので、他の未着手のものを先に進めて欲しかったからです。
確かにゾッとします。。実務では顧客の優先度の確認は必須ですね( ﾟДﾟ)b
そしてスプリントを重ねるに連れ、この開発班の得意分野がわかったので、その分野を上位に繰り上げたのも追加要望の順位が低めになった理由のひとつです。
（商業施設分野が素晴らしかったです。）
なんとなく例えるなら、
- ウォーターフォール開発→「メール」
一方的なターンを相互に繰り返します(こじれやすい)
- スプリント開発→「会話」(対面or電話)
顧客側、開発側互いに反応を見ながら進めます。
(お互い小さな軌道修正を繰り返す為、こじれにくい)
確かにメールより会話の方が最初大変のように思えますが、結果的に最悪な大変さは回避出来ます。
最初のLEGOの固定イメージのまま取り掛かった自宅。
結局完成しなかったのですが、これSIerの作るものを象徴している気がします。。。
この生真面目さ、中途半端さ・・・
レビューすることなく続けていたら、ただの家作りで終わっていたことでしょう(そして望む家だったのかな(ﾟ⊿ﾟ)？)
それでも街にしようと思えば、膨大な時間とお金がかかったことでしょう。。。恐ろしいっ！！
主催者の@kdmsnrさんが途中おっしゃっていた言葉が印象深く、
「普通の人のためのもの」
「顧客から却下されたからと言ってPJが失敗な訳ではない」
「アジャイルは普通の人のため」と感じていた私の考えを確実にしてくれ、一発OKを狙うウォーターフォール開発は人間にとっては非現実的な手法だと確信しました。
楽しかったです＼(*´▽｀*)／！