当日は、台風接近中という状況にもかかわらず、ほぼキャンセルなく参加して頂きました。
ご参加頂いた皆様有難うございました！

イベントページ

http://connpass.com/event/7562/

開催理由

京都アジャイル勉強会Lightで行っていた「アジャイルサムライ」読書会（第２回目）の卒業イベントを兼ねて、一日アジャイル体験イベントを行いました。

また、アジャイルもかなり経験者が増えてきているかと思うのですが、京アジャの周りではまだまだ座学やプラクティスだけという方もいるため、少しでもアジャイルの素振り経験を増やすお手伝いができればという思いもありました。

概要

makedoという子供向けなんだけど大人も本気になってしまう工作キットを使用して、「宇宙基地開発」をプロダクトにして行いました。

詳細は、またやるかと思うのでここでは省くとしてw
１年前に行った同イベントから主催者が得たフィードバックを受けて、今回工夫した点を記載します。

前回からの変更点

ユーザーストーリーの作成

経緯

前回のイベントではユーザーストーリーの作成を各チームで行いませんでした。
理由は、ユーザーストーリーをINVESTな状態に持っていくのは、非常に時間がかかるため、アジャイル初心者で、しかも限られた時間内に当日初めて聞いた宇宙基地開発のユーザーストーリーをPOの意思をくみつつ作成するのは難易度高すぎると考えて、宇宙基地開発に必要なタスクを出して下さいということにしていました。
そのため、単なる作業リストが出来てしまいPOの価値に直接紐付かなかったため、別途時間を取ってやり直すチームが出てしまいました。

Try

今回は、ユーザーストーリーは事前に主催者が作成しました。
でも、一度は経験してほしいということで、各チーム一つだけユーザーストーリーを作成してもらうことで、少しだけれどもユーザーストーリー作成の素振りをしてもらうことにしました。

気付き

各チーム同じユーザーストーリーでプロダクトを作成してもらったので、出来上がったプロダクトに各チームごとの特色が出ていた。通常のプロジェクトだと、同じユーザーストーリーで複数チームがプロダクトを作るとか贅沢すぎて出来ないと思うので、プロダクトの比較をするという良い経験ができた。

事前に、各チームごとにPOとユーザーストーリーの中身や優先順位について話し合っていたため、第一スプリントから出荷可能なプロダクトが出来ていた。

ただ自分たちで作成したユーザーストーリーから着手したチームは、プロダクトについての理解が浅い状態で作成したユーザーストーリーだったため、そこにPOの意思が見えずに苦労していた。

ユーザーストーリーの内容に、チームとして理解できるているか（なぜ必要なのかを含めて）がスプリント中に混乱が起こるか起こらないかに、かなり影響するということを経験出来たのではないかと感じました。

完了の定義(Difinition of Done)の導入

経緯

前回のイベントでは、完了の定義を設けなかったため、スプリントレビューの際にチームがプロダクトオーナー(PO)からの質問にそれなりに答えられていれば、レビューOKという流れが何となく出来てしまいました。
そのため、終了時間が差し迫った後半のスプリントに作成したプロダクトの出来がちょっと雑になってしまう傾向がありました。

Try

その反省を踏まえて、予め用意したユーザーストーリー全てに完了の定義を設定しました。
POは、スプリントレビューの際に、この完了の定義を確認することで明確に完了と判断することが出来ました。

気付き

予め完了の定義を与えられているとチームはスプリント内に検証環境（デモ用に用意されたテーブル）に作成途中のプロダクトを持って行き、完了の定義を満たしているか自分たちでチェックを始めました。

これは、前回のイベントでは無かった行動でした。
完了の定義を設定し事前にチームに共有しておくことで、チームは作成途中のプロダクトを使って常に完了の定義をクリアしているかをチェックしながらプロダクトの作成を行っていました。

実際のプロジェクト開発でも、チームの成熟度に応じた完了の定義をチームで作成＆共有することで、コミットされたソースコードの品質を一定に保つことが出来るということの擬似体験が出来たのではないかと感じました。

最後に

参加者の方に、振り返りを兼ねてコメントを頂いたのですが、その中でも
* プロダクトの内容が面白かった（社内でパクらせて下さいw）
* ユーザーストーリーのボリューム感がちょうどよかった
* 時間の関係なんだけど、前半のユーザーストーリーの作成までをもう少しじっくりやりたかった
などの意見を頂きました。
２回目ということで主催者側としては、１回目の反省点をフィードバックした内容に出来たかなと。
３回目を行うなら、ユーザーストーリーのところをもう少し厚めにできる工夫を凝らしたい。

当日の風景

さて、６/２２に京都アジャイル勉強会第６回を行いました。

期待すること

実践した内容

この辺りが、結構不安だった。

結果

ワークショプが完成してもしなくても、自分たちがアジャイラーとして出荷可能となる為に選んだストーリーの知識・経験・気づきを得られるワークショップを考えるということは、それだけそのストーリーについて考え・知る必要があり、ワークショップを考えるワークショップを行うことで実は既に、知識・経験・気づきが得られているのではないかと感じた。（メタワークショップになっていた感じ）

３チーム中２チームがワークショップが出来たので、実際にやってみたり、やってもらったりしたけれどかなり楽しめたし、気づきが得られた。

まとめ

今回考えたワークショプもブラッシュアップして行きつつ、ワークショップを考えるワークショップは引続き行って行きたい。

次回は、第７回

隔週で行っている甲斐あってか大分リズムが感じられるようになってきた。

出荷可能な製品が出来上がっている感じがして面白い！

5/11に京都アジャイル勉強会を開催しました。

京都アジャイル勉強会#3

今回は、完全に反省。

正直開催前から一抹の不安はあったのですが、それを解消できないまま開催してしまいました。

反省点。

1. 京都アジャイル勉強会の運営者側の仕事を参加者にもしてもらっている感が否めない
2. ぱらぱらと集まるため、時間通りに参加される初参加の方が時間を持て余す
3. アジャイル知っている前提で進むことに疑問を抱いていない

主催者MTGで@Posauneともう少し当日の絵の擦り合わせが出来ていれば良かったのですが、それができないままだったことに深く反省。

勉強会の前提として、アジャイルサムライに書かれてあるプラクティス（主にインセプションデッキ）をもう一度やり直そうというのが大きくあり、アジャイルサムライ読書会のときにはインセプションデッキの内容を続きで行えなかったので今回はインセプションデッキ〜実際に物をつくるところまでを通しでやってみようという続き物に途中から変わっていきました。

それはそれで問題ないのだけれど、そうなった段階で読書会から参加して頂いているほぼ運営メンバーと呼べる人たちだけを参加者として行えば良かった。

一般参加を募っているいじょう今回の進め方は完全に身内話に巻き込んでしまった感が否めませんでした。

インセプションデッキしているのに、バスに乗っていない人が多数いるみたいな。

既に第４回の募集を行っているので、今回の反省を生かしつつ全員バスに乗って出発できる勉強会にしていきたいと思います。

#xpfes12

TDDとスクラムの事例がお目当てでXP祭り関西に参加してきました。

アジャイル開発における計画と管理〜アジャイルのプロジェクトマネジメント〜

システムインテグレーター　梅田弘之氏

概要は、アジャイルでもプロジェクトマネジメントは必要だという話。
ご自身が取締役社長ということで経営者からみてアジャイル開発がどう見えているのかという内容でした。

ウォーターフォールを敵視するな

基幹業務などでは、ステークホルダも多く色々な調整を行ったりしていれば、要件定義に３ヶ月かかってしまうこともあるわけで、その辺りを理解する必要がある

たしかに、基幹業務などでは億単位の金額が扱われたり関係する部署がとても多かったりでヒヤリングするのにも結構時間がかかると思う。実際、中には色々な人がいて（そもそも利用者が物理的に遠かったり）すんなりヒヤリングできるわけでもなかったりするし。

ただ、要求を決めるためにかかった３ヶ月がどういった内容かにもよるかなとも思いました。

一度に要求を決めようとすると要求を決める関係者それぞれが少しずつ返信が遅くなるだけで結構な待ち時間ができて、それが積もるとそれなりの時間になり結果的に要求の決定が遅れるという事態の原因の一つになるのかなと。

ウォーターフォールの場合、フェーズ毎に作業が進んでいくため後工程になればなるほど手戻りの発生する箇所が増える。
それを意識するあまり、仕様の決定が遅れかつ、納期がまだまだ先なため決めきれないというのがあると思う。
そこに、タイムボックスを適用することで要求を決める人も全ての要求を要求定義のフェーズで決めきらないと駄目だと思っていたのが、この機能についてだけ決めてくださいに変わるので、要求分析やヒヤリング対象が絞られて要求が決めやすいのではないかと思う。

ただ、適用が難しいかなと感じるのは、実際のリリースはずいぶん先なのに１イテレーション（スプリント）の終わりを本当のリリースと同じように扱えるかというところ。
要求を決める人が今回はスクラムを行うと同意している場合は協力的になってもらえる（もらえないと困る）と思うが、要求を決める人が加えられずにスクラムを行う際のリスクはこのタイムボックス内に要求を確定してもらえないというところかなと思う（アンチパターンだけど）。

ウォーターフォールは、売れる物を作るのが苦手

梅田さんのところでは、パッケージ製品の開発が主な開発でその際パッケージ作成とそのパッケージをお客さんに導入する開発は別と仰っていた。

パッケージ作成は、内部の開発だからハンドリングがすべて会社でできるためアジャイル開発向き
ウォーターフォールは売れる物を作るのが苦手

たしかに自社製品を作るのに、ウォーターフォールでは作れない。

お客さん向けの仕事にどうアジャイルを取り入れるかが最大の課題でありチャレンジ
アジャイルでやっても作るものによって犠牲にすることが異なる。
プロダクト開発は、スコープを犠牲にできる。
請負開発は、コストを犠牲にするしかない

請負開発とプロダクト開発で犠牲にするものの違いは全くその通りだと思う。

この違いは、

プロダクト開発はスコープを犠牲に出来るけれど、犠牲にしたスコープによって製品が売れるかどうかのリスクを自社で追う必要がある。

逆に請負開発はコストを犠牲にするけれど製品が売れるかどうかへのリスクは自社で追う必要はない（発注側で仕様を決めてしまうから。作った物は売れてほしいけれど）。

どのリスクをどちらが負うかによって、犠牲に出来る物と出来ない物が変わってくる。

請負の際にいつも確認するのは
「納期は最大どこまでのばせますか？」

ここを聞いておかないと仕様変更・追加に対してコストをかけたとしても残業や休出、過剰なメンバ追加しかコストをかける時間がとれなくなってしまうため、プロジェクトが遅れ始めるとひどい生活が始まってしまう。
請負開発では、コストを犠牲にするしかないけど生活は犠牲にしたくないというのを、死守できるかどうかは納期が最大どこまで延ばせるかにかかっていると思う。ここで見積もりも合わず、納期も絶対延ばせない案件だと受けないか最悪工数ベースの契約に持って行く場合が多い。

TDDサイクルを加速する技術たち

@irof氏

irofさんのセッションに参加するのは初めてで今回一番楽しみにしていた。
最初にしっかり「京都アジャイル勉強会」の告知もして頂いた。ありがとうございます。

以前アジャイルサムライ読書会in京都の懇親会で、テスト版９７のこと（あのときはこっちが本編だったな）を教えて頂いてそれ以来自分の中でのTDDへの最初の壁が取り払われた。それから、テストと並走してプログラミングする毎日を送ってます。

前後のテーブルと会話する形式だったので、メモしきれなかったのだけれど残ったポイントは

変化しつづけるものは変化に強い

テストと合わせてjenkinsを使っているとこの言葉は自分的には納得。実際救われたことは何度もある。

思った通りにうごくコードをかく技術がTDD

通常は、書いた通りに動く。だけど、思った通りにうごくを実現するためには、テストが必要。

リファクタリングの終わりどころは次のRedが一つになったら終わり

仮に一つ修正加えたらRedになる箇所が、複数ある場合はまだリファクタリングできるとのこと。

どれも禅問答のような言葉だけど、話を聞いているとストンときます。

きっと自分で気づかないと意味がないから自分で気づきやすいように考えてもらって結果を共有して、自分の意見を述べるというセッションにしたのかなと思った。

例え悪いかもしれないけれど、倒幕するときにも草の根運動のようにこのような議論の場が持たれて最後は大きな仕事に結びついたように感じた。

なので、チームへの啓蒙の第一歩は、自分がテストを書き続けて周りにその良さを広めることでしか実現できない（もしくはirofさんのセッションを受ける!?）と思うので、やっぱり自分が書き続けて周りにTDDの良さを感染させるしかないのかなと思いました。

大規模なゲーム開発をスクラムで

田口 昌宏氏

大規模なゲーム開発で実際にスクラムを取り入た際の事例紹介でした。

面白さを見積もり時に組み込むことは難しい

スクラムに取り組んだ際の動機だったと思う。

午前の梅田さんのお話ともリンクするのだけれど、試行錯誤する開発についてはスクラムはとても適用しやすい。

１スプリント２週間で隔週水曜日にスプリントプランニング
火曜日にレビュー、お菓子付きショーケース

懇親会に参加できなかったので、聞けなかったのだけど水曜日にスプリントプランニングを設定したのはなぜか聞きたかった。

田口さんのお話を聞いていて一貫して思ったのが、まずやってみる。
それで問題が出たら、その問題を解決するために対処する。それがスクラムのツールでカバーできるところはツールを導入し、その導入もただ入れてみるのではなく実際にチームに適用するように随所に工夫が施されていた。
（コミュニケーションに問題出たので朝会導入。ただし２チームで朝会の開始時間をずらして実施。それぞれの朝会の内容を共有できるようにしたなど）
スライドの写真を見ていて思ったのは、参加している皆が本当に楽しそうにやっているところ。

朝会やタスクボードでかしこまったミーティングがなくなった。

確かに、かしこまったミーティングがあるところは日常的にコミュニケーションに問題がある。
プロジェクトが遅延してくるとミーティング多くなるのはこのせいかなと感じる。日頃からコミュニケーションがとれていれば、遅延してきたからといってミーティングを増やす必要はないはず。

３〜４時間のプランニングで制度の高いものが出来る

これは、プランニングポーカーしているととてもよく思う。自分はそこででた意見を実際に見積もりや開発時のチェック項目としてあげたりしている。
京都アジャイル勉強会でもプランニングポーカーをしていると、自分が考えていなかった意見がぽんぽん出てくるのですごく参考になる。

10名超えると朝会で話す内容が薄くなったので、チームを分割。スクラムマスタも２名に導入
壁は情報発信継続力がすごいし、壁は解像度が高い
ショーケース時の品質は、落ちたらアウトぐらいにしている。全テストを通らないと駄目とかではない

などなど。

参考になることばかりだし、すぐに自分も取りいれて自社ではどうなったのかを共有したいと思うことばかりでした。

もっと色々聞きたかったのだけれど、懇親会には参加できなかったのでまたどこかでぜひお話を聞きたい。

まとめ

スクラム開発を取り入れている人の話を聞いていると、「巻き込み力」とでもいうのか回りの人をその気にさせるのがとてもうまいなと感じた。

スクラムに限らずだけど、知→無知への提案はなぜか上→下のような関係になりやすい気がする。普段からの関係性がとても良好なので提案しても上→下の関係にならず対等に論じあえるのだと思う。

日頃から傾聴することが大事だとつくづく感じた。

京都アジャイル勉強会について

アジャイルサムライ読書会in京都が終わり、引続きアジャイル導入を考える方達（自分も含め）のための勉強会を京都で行うということで、そのまま「京都アジャイル勉強会」という名前で、人も内容もほぼそのままに始まりました第一回。

アジャイルサムライは読んで終わりでなく、実践して経験値を積むときの指南書となる本だと思うので「京都アジャイル勉強会」では、アジャイルサムライにでてくる数々の手法を本番前に何度も経験し失敗し、本当に身体で覚えるまでやって本番は楽に乗り切ろうという試みのもと行っています。

もちろん既に本番をやっているけれど、経験値を積みたいという方も大歓迎(実際に数名参加されています）。

第一回となる今回は、「色々試そうプランニングポーカー」と題してプランニングポーカーで色んなことを試して、試した結果を皆で考え共有しようということで行われました。

実践

参加者が、１１名だったため、５名、６名の２チームに分かれて各藩で、プランニングポーカーの見積もり対象となるシステムを決めてそのユースケース出しから入りました。

私の藩は、「オンライン上の年賀状作成ソフト」です。

そこから、１０こ程度のユースケースを考えて、そのユースケースに対して見積もりを行いました。

最初に手持ちのカードは、１、３、５、？の４枚。

３を基準値として「仕様が大きくぶれにくく規模が大きくも小さくもないユースケースを３としました」。

その後、それ以外のユースケースの見積もりを皆で行いました。

４枚で見積もりした内容を今度は、１、２、３、５、８、？の６枚にして行い枚数が増えることによって、結果や思考がどう変わるのかを試そうという試みでした。

実際は、１回目の見積もりの内容が本当にシステムを作るかのように議論が熱くなり２回目の見積もりは駆け足となってしまったため詳細に比べることが出来なかったのですが、１回目で見積もりできたユースケースに対してのみ２回目の見積もりを行ったとところ面白い結果になりました。

１回目で同じ３を出していた人同士が、２回目では、２、５になる。

１人は、２が入ったことで１よりは大きいけど３よりは小さいから３を出していたのが、２が出来たことで２に変わる

もう１人は、８が入ったことにより３よりは大きいけど５よりは小さいが５をだすとそれ以上大きい値がなくなるため３としていたけれど、８が入ったことにより５に変わる。

ということを考えていました。

だしたカードが同じだからといって同じ判断でそのカードを選んだとは限らないということが分かる。
ということは、見積もり時のユースケースの粒度によってはカードの枚数を６枚程度で行いあえて意見が割れるようにしてみることで、チーム内の意見を引き出し安いと感じた。

あと面白かったのは、説明しているうちに意見が変わってしまうことが多々あったこと。

考察

実際の見積もりだと見積もりが合わない場合に、各機能についてどうしてこんなにかかるのかということを延々と話し合い結果数人日とかひどいときには数時間の削減を迫られたりするのだけれど、実際数ヶ月前に数人日や数時間の想定をしたところでいざ作業に着手したとたんに、あれが必要これが必要とかであっという間に数人日オーバーになっていく。

相対見積もりだと議論になる箇所が、見積もり工数ではなく仕様や前提条件になるため不毛な工数削減に合いにくくそもそも、詳細ではないくせに詳細な話になることが防げるということを改めて実感した。

また、今回ユースケースについてはあまり時間をかけずに作成したため、内容についての前提条件が確定していなかったこともあり、実際にカードを出し合ってからの議論が長くなった。

見積もりを行う前に、ユースケースの前提条件や理解度を合わせておいた方が工数の決まっている本番では良いと感じた。

余談

CSMの研修でプランニングポーカーを行った際も、仕様について１５分ほど話し合う時間がさかれたと思う。

ただ、その時面白かったのは出された仕様をチームで検討する時間を与えるので、仕事を受けるかどうか答えてくれというもので、検討後チームの代表が前に言って講師に仕様を受けるかどうかを聞かれた際にチームの代表の仕様についての質問はいっさい受けずに、とにかくYesと言わせようとしていたこと。
で、あまりの講師の圧力になし崩し的に大半がYesと答えてしまっていた。

ここでは、絶対に圧力に屈しては駄目で即席の見積もりや、安請け合いは結局交渉の条件に使われてしまうという教訓だったと思う。詳しくは「リスバーガー」で検索すると分かる。

次回も引続き「色々試そうプランニングポーカー」をやります。