Agile do ITに参加してきた - The Pragmatic Ball boy

Agile do IT! に参加してきました

Agile Japanには残念ながら業務優先で行けなかったので、こちらに参加。

Agile in a Nutshell
アジャイルサムライの筆者のジョナサンの講演。
タイトルの通りアジャイルの概要でアジャイルサムライの第一章の内容ほぼそのまんまだったので正直読んだ人にとってはあんまり役にはたたなかったんですが（失礼）、本人のお話聞けてよかったです！

ジョナサンのおすすめなアジャイル開発の進め方としては
まずXPのエンジニアリングプロセスを導入してみて、次にScrumとXPを組み合わせたものをやってみて、最終的にLeanの考え方を導入して改善していく方法がいいんでない？と言ってました。

また3つの重要なこととして

価値を毎週届けること
UnitTest、Refactoring、TDD、CI　は少なくともやる
３つの真実

全ての要求をかなえるのは不可能
要求は必ず変化する
時間と金は必ず予定を超過する

というところを最後にあげていました。

質問では、マネージャを説得するにはどうしたらいいんだという質問があり、回答としてはロジカルに説明するという方法と、顧客にどっちのやり方がいいか聞いたら顧客は毎週価値を届けてくれる方を選ぶと思うよといってました。

もう一つの質問では、チームがアジャイルを抵抗したらどうするんだという質問で、ジョナサンはアジャイル開発を強いるのは好きではなく、自分からはじめていくのがいいと思うと言っていました。

スクエニのプロジェクトマネジメント事例
スクエニのCTOの橋本さんの講演。
とてもよくアジャイルを理解しておられて、それをうまく工夫して自社開発に落とし込まれているなと思いました。（今回の中で一番参考になりました）

プロジェクトの予想はできないが制御は可能、予測できないことを受け止めなければならない。
事前対策と事後対策のバランスが重要。WFでは事前対策を重視しすぎて、なんちゃってアジャイルでは事後対策しかしていなかったりするから失敗するみたいです。

スクエニでは2点見積もりをしている。最小見積もりと最大見積もり（最小見積もり＋バッファ）で見積もって、さらに見積もり精度を指標として用いるなど、かなり厳密な測り方をしていて、納期に対する姿勢がとても感じられました。それぞれの見積もりにはプランニングポーカー的なやり方を導入しているそうです。

だいたい比率は　準備：実装：仕上げ＝１：１：１　になることが経験上得られているそうです。

橋本さんが強調しておられたのは、そのやり方をなぜ行うのか？ということを常に考え改善し続けることが最も重要であり、思考停止してはいけないというところでした。このあたりはまさにアジャイルの精神だなと感じます。

Yahooの事例
Yahooでは「標準」としてアジャイル（Scrum）が取り入れられているというのが驚きでした。どんな内容なのか詳細にはわからなかったのですが、狙いとしては、アジャイル開発を導入する際の導入コストの低減だそうです。「標準」とアジャイルというのはかなり相反する存在だと思っているのですが、そのあたりのバランスをどうコントロールしているのか今回は聞けなかったですが、今度是非聞いてみたいところです。

Scrumやってよかったことはコミュニケーションが円滑になったこと。
Scrumの準備としては、チームメンバーにスクラムガイドは読んでもらうことと、インセプションデッキはやったほうがいい。効果の定量的な評価は難しいが、導入前後の定性的な評価は行なっているそうです。

DeNAの事例
DeNAではプラットフォームのところでScrumを導入しているそうです。
40人くらいの人数なのでScrum of Scrumといった構成になっていました。
プロダクトオーナーは各チームにサブプロダクトオーナーを置いていました。
管理はJIRAを使ってプロダクトバックログ、スプリントバックログバーンダウンチャートなどを出しているそうです。

思ったことは、こういったソーシャルゲームといった業界ではかなりアジャイル開発をしているのかと思っていましたが意外とまだそこまで浸透していないということと、最初はスクラムのチームをエンジニア、デザイナーなどそれぞれで分けていたなどと、まぁどこでも組織というか職種の壁は存在するのだな・・と思いました。

パネルディスカッション

チームにはスペシャリスト（CIなど）を置かないほうが、各自が勉強するのでよい
ユーザーストーリーについて

だれが作ってもいいけど優先度はPOがつけて責任をとる
割り込みタスク用に１０％〜２０％ほど余分にアロケートしておく手もある
非機能はどうしてる？

スプリントの完了の定義に入れる
非機能対応用のタイムボックスを作ってそこでやる

プロダクトバックログの大事なところ

優先度、背景はなにか、数が多くなりすぎないようにメンテすること
技術的なリスクを考慮する
納期に対してどれだけリソースをさけるか
準備できているか

スクラムマスターとして意思決定に関わるときのコツ

振り返りの時に話題を投げかける
最初にガイドなどをつかって手本を示す
一人一人話しを聞いて人によってアプローチを変える
BootCampをする。アジャイルはこういうものというのを紹介する
メンバーのもつ不安を解消する。反論するチャンスを与える
どのテクノロジー(TDD,CI)をやるかではなく、将来的にどの方向に向かいたいのかを決めておくのが必要。

スクラムマスターに必要なスキル

空気を読まない事、忍耐力
最終的にチームから必要なくなる人になること

雑感
タイトルが"Agile do IT!"ですが、"Be Agile!"のほうがいいというか正しい気がしています。
というのもアジャイルは”する”ものではないというところがアジャイル開発において難しいところなのではないかと思っています。
確かに導入としてはTDDやCI、朝会、振り返りなどを”する”というのは大いにありですが、それによって万事解決するわけではなく、それをベースとして”自分たちにあった形に改善し続けていく”というところがアジャイルの本質的な部分ではないかと個人的には思っています。
そこをどう全体に広めていくかといったところにみなさん苦労なさっているという印象を受けました。むろん私もですが・・・

結構以外だったのが、DeNAなどのWeb系やソーシャル系のところではかなりTDD,CI,自動化などが進んでいて当たり前のようにやられているのかと思っていましたが、実際にはそういうところもあるが、テストの全くないレガシーコードも大量にあるのが実情ということで、まだそれほど差はないなということがわかった点でした。