「正しいアジャイル」でなくてもいい

「正しいアジャイル」でなくてもいい

Agile Japan2013 四国・愛媛サテライト

2013/05/25

13年5月26日日曜日

荻野浩史　おぎ　　　　の　　　　　ひろ　　　　　し

認定スクラムマスター認定スクラムプロダクトオーナー


http://d.hatena.ne.jp/ogin_s57/




http://d.hatena.ne.jp/ogin_s57/13年5月26日日曜日



アジャイルプロセス協議会四国支部13年5月26日日曜日



アジェンダ正しいアジャイル？

アジャイル開発事例のご紹介

まとめ




まとめ


「正しいアジャイル」と聞いてどんなことを思い浮かべますか？


スプリントが２～４週間で、最後にふりかえりを実施

かんばんで見える化

毎日朝会を実施（デイリースクラム）

ペアプロ

テストは全て自動化されていて継続的にCI環境でビルドされる

正しいアジャイル？

：：


スプリント


TODO In Progress DONE

かんばん


朝会（デイリースクラム）

１.昨日やったこと２.今日やること３.困っていること

毎朝１５分


ペアプロ

ドライバー

ナビゲーター

（なるほど。そういう風に書けばいいんだな。）

ココはStrategyパターンで実装して・・・


テスト自動化とCI環境

開発者SCM

CI環境

コミットコミットを検知してCI環境にてビルド





ペアプロ



：：

問１：これらを実践しないとアジャイルじゃない？





ペアプロ



：：

問２：これらを実践すればうまくいく？


後ほどこれらの問いにお答えします。




まとめ


こんなシステム開発オンラインで大容量ファイルをやり取りするSaaSの開発

既存システムのリプレイス期間：６ヶ月


�A�&�#B�&"5'*:%��$��

�&!./37�

A�&� B�&�./37�

�

��

+)://,9<�

�

�

--------- ---------

--------- ---------

�

� A�&�� >B�&?%�� 5'*:%(26;=4�� ./37�#B�&5'*:��8=:�� B�&�./37�#5'*:%1+<;=4�� ./37�#A�&"5'*:� 8=:�

SSL

(-0/��


こんなチーム人々（合計：６人）

プロダクトオーナー（顧客）：１人

１０年戦士：２人

５年戦士：３人

アジャイル開発経験者：０人


こんなチームとりあえず「開発～テスト」を繰り返せばアジャイルって言えるんだよね？


こんなチーム

アジャイル偏差値：低

とりあえず「開発～テスト」を繰り返せばアジャイルって言えるんだよね？


プロジェクトスタ～ト


スケジュール

先行開発チーム

仕様策定チーム

開発チーム

１ヶ月２ヶ月３ヶ月４ヶ月５ヶ月６ヶ月

顧客

１０年戦士

５年戦士


０～１ヶ月


スケジュール



開発チーム


▼プロセス考察

メンバーが今まで実践してきた様々な開発手法についてに議論し、どんなプロセスでシステムを構築してゆくのが自分たちにとって一番良いのかをみんなで話し合った

顧客

１０年戦士

５年戦士


とにかくみんなで話し合いを重ねました


そこで決定した２つのこと


(1)テストファースト



テスト仕様書

SCM開発部隊

コミット

各々担当の機能を実装＆テスト

(1)テストファースト

テスト仕様書を先に作成し、それを元に開発する

顧客

１０年戦士

５年戦士


(2)先行開発チーム


必ずしも解決することが目的ではなくて、早期に取り組む事が目的だった。

暗号化

(2)先行開発チーム

ベースラインアーキテクチャの策定技術的難易度の高い問題に早期に取り組む

顧客

１０年戦士

５年戦士

？ウィルススキャン

？認証・認可？

技術的難易度の高い問題に取り組む

ベースラインアーキテクチャの策定先行開発チーム


１～３ヶ月


スケジュール



開発チーム


▼先行開発

ベースラインアーキテクチャの策定やコア機能を先行で開発。何度となくハマったが、難易度の高い部分に取り組んだことによって早期に多くことを学習できた。

顧客

１０年戦士

５年戦士


スケジュール



開発チーム


▼既存システム調査

既存システム要件／機能を分析し、随時「仕様策定チーム」と連携。テスト仕様書に積極的にフィードバックし、仕様書の精度を上げていった。

顧客

１０年戦士

５年戦士


スケジュール



開発チーム


▼テスト仕様書作成（仕様策定）

コア機能に関するテスト仕様書を作成。どの程度の情報量をテスト仕様書に載せれば開発が可能なのか？を推し量る素振り（試行）の意味も含んでいた。

顧客

１０年戦士

５年戦士



テスト仕様書の作成（システム仕様の策定）

開発部隊

「もっと××な情報を仕様書に盛り込んでください」というフィードバック

フィードバック顧客

１０年戦士

５年戦士


「既存システムには△△な機能があります」「その場合、既存システムでは○○のように動作します」というフィードバック

既存システム


チームは失敗を繰り返しながら学習し、改善していった➡経験を重ねるということが大事


３～６ヶ月


スケジュール



開発チーム


▼開発＆テスト

仕様策定チームの作成したテスト仕様書を元に開発＆テストを実施。プロダクトに集中。。。

顧客

１０年戦士

５年戦士


スケジュール



開発チーム


顧客

１０年戦士

５年戦士

▼テスト仕様書作成（仕様策定）

テスト仕様書を作成する。既存機能を取り込むか否かや新規機能を盛り込むか否かは全てココで管理。以前と同様に、絶えずフィードバックを受けながら仕様書を作成していった。


こうやってプロジェクトは無事遂行されました


常に動くものが手元にあった（動くソフトウェア）

誰でもコードを修正出来る状態だった（コードの共同所有）

必要性を感じたタイミングですぐに話し合いを始め、必要性を感じたタイミングで資料を作成していた（Just In Time）

利害関係者が顧客１人だけだったため、素早く決定／方向転換出来た（オンサイト顧客）

チームが能動的にプロジェクト／プロダクトを改善していった（自己組織化）

良かったところ


朝会がなかった

スプリントがなかった（本番リリースは１回だけ）

ふりかえりもなかった

ペアプロはやってないしテスト自動化もCIもなかった

イマイチだったところ


どうもアジャイルの王道は外しているようですが・・・このプロジェクトはうまくいったのでしょうか？


アジャイルは正しく実践出来なかったかもしれませんがうまくいったと思っています。


なぜなら価値あるシステムを構築出来たから

ここだけの話、結構売れてんすよww



（当時の考え方）

「正しい開発プロセスがあれば、開発者はもっとうまくやるだろう」


（宣言者たちの考え方）

「スキルのある優れた開発者がいれば、

彼ら自身が学習して開発プロセスを決めれば良いだろう」


開発プロセスは自分たちのもの自分たちで進化／深化させるもの


こんなチーム人々（合計：６人）

プロダクトオーナー（顧客）：１人

１０年戦士：２人

５年戦士：３人

アジャイル開発経験者：０人


こんなチーム

アジャイル偏差値：低

とりあえず「開発～テスト」を繰り返せばアジャイルって言えるんだよね？


みんなアジャイルに対して無知だったから、アジャイルを実践しようとしなかった


みんなアジャイルに対して無知だったから、アジャイルを目的にしなかった


プロセスを自分たちで定義して、自分たちに合った形を発掘していった。



テスト仕様書

SCM開発部隊

コミット

各々担当の機能を実装＆テスト

(1)テストファースト顧客

１０年戦士

５年戦士

ATDD・BDDという開発手法13年5月26日日曜日

必ずしも解決することが目的ではなくて、早期に取り組む事が目的だった。

暗号化

(2)先行開発チーム顧客

１０年戦士

５年戦士

？ウィルススキャン

？認証・認可？

技術的難易度の高い問題に取り組む

ベースラインアーキテクチャの策定先行開発チーム

早く小さく失敗するというアジャイルの定石13年5月26日日曜日


テスト仕様書の作成（システム仕様の策定）

開発部隊

「もっと××な情報を仕様書に盛り込んでください」というフィードバック

フィードバック顧客

１０年戦士

５年戦士


「既存システムには△△な機能があります」「その場合、既存システムでは○○のように動作します」というフィードバック

既存システム

早く小さく失敗するというアジャイルの定石13年5月26日日曜日

自分たちに合った形を発掘していった結果、知らず知らずにアジャイルなプロセスになっていました。


アジャイルに対して無知なことが武器になることがあるんです。




まとめ


最後に先ほどの問いに答えましょう。





ペアプロ



：：

問１：これらを実践しないとアジャイルじゃない？


そんなことどうでもいいと思います。


えぇぇぇぇぇ～～～

自分から振っといてそんなことってあるんすか。。


アジャイルは目的ではなくて手段です。なのでアジャイルかどうかなんてどうだっていいんです。


いいシステムを作りたいという想いが根底にあってそれを支えるものとしてアジャイルがあればいい


わたしはそう思います。





ペアプロ



：：

問２：これらを実践すればうまくいく？


そんなワケないですよね。


アジャイルを導入すれば問題が解決するなんてことはありません。


問題を解決するのはプロセスではなくて自分たちですから。


大事なのはプロセスに従うことやプラクティスを実践することではなく、自分たちで選択すること


何が価値を生み、何がムダなのか自分たちで考え抜くこと


それを実践し、実践した結果から学習し、改善すること


わたしはそう思います。




まとめ

ちょっと付け足し


決してアジャイルを正しく実践しなくてもいいと言っているわけではありませんよ(^^;)


アジャイルを正しく実践出来ればその効果は絶大です。


ただし正しく実践するというのはそんなに簡単ではありません。


その難しさ故に一歩間違えれば実践することが目的となってしまいがちです。


Don’t Do Agile,

Be Agile!!


アジャイルを目的としないためにはじめから「正しいアジャイル」を目指さなくていいということを言いたくて、こういうお話をさせて頂きました


ぜひどんどん間違った（？）アジャイルを実践して失敗しながら「正しいアジャイル」を発掘しましょう


No Agile, No Life!!


ご清聴ありがとうございました。


Documents

「正しいアジャイル」でなくてもいい