マイクロソフトの長沢さんが企画したイベントに参加してきました。
参加者は、知っている顔が４分の１くらいで、あとはたぶん、本来のターゲットである、これからアジャイルを勉強してみようという人たちだと思います。MSさんのチャネルというのは、あまりこれまで関わってこなかったので、すごく面白かったです。
セッションも実践的で、とても参考になりました。みなさん、自分できるところ(半径５m)からチャレンジしている感じが伝わってきて、そういうところから、きっと社会は変わっていくんだろうな(Fearless Change)、と思いました。
プレゼントで、VisualStudioロゴ入りプランニングポーカー(私がAgile2009でもらってきてXP祭りでプレゼントしたものと同じだと思う)を出していただいたので、懇親会で、プランニングポーカーの使い方セッションをさせていただきました。皆さんすごく楽しそうに参加していただきました。うれしかった。
「プランニングポーカーをもらえなかったんですけど、どこかで売っていますか？」「売っているのは知りませんが、自作もできるし、じゃんけん（指）でもいけますよ」ということで、プランニングじゃんけんも伝わった！
今回おもしろいなと思ったのは、マイクロソフトさんが、ツールの紹介より、アジャイル開発のの事例の紹介など、開発者サイドの話題を優先させていたこと。Youtubeや検索広告など、力のあるユーザ生成コンテンツを中心として人を集めておいて、満足度とリターン率やコミット率を高め、その脇にCMを配置しておく手法に似ているな、と思いました。マイクロソフトは、インフラに徹して効率的に集客できる訳です(たぶん)。
- - -
- 三井さん
- TPSの７つのムダの話。1.作りすぎのムダ: ソフトウェアの場合、使っている機能は45%というレポートがある
- 仕様凍結。３年後のシステムなんてわかんないのに、すごい要求入っているのに凍結する、ということがよくある。世の中は変わり、開発者は真面目に作ったのに受け入れてもらえない。お客さんとのコミュニケーション、有言実行を時間軸(忘れる)が邪魔をする
- イテレーティブでインクリメンタル => アジャイル。 ニーズとの擦り合わせ (インテグラル）。「誤解を生まない」というのが一番作りすぎない為に重要。短いサイクルで見せられることが重要。
- 頭脳労働におけるムダ - 一人にアサインすると悩んだりぐるぐる回っちゃう。じゃあコーヒーのみに行こうかと。開発者じゃない人たちにも、２人一組の作業が有効
- ２人一組だと残業したくなくなる。生産性は倍くらいになったりする。でも、中間管理職とか経営者層の意識改革が必要。現場が自発的にやらないと意味がない。強要されるならやらないほうがいい。管理者が理解して、ファシリテーションなどをする。
- 見える化。時間は動作の影(結果)。見積もった時間よりどれだけかかったか。割り込みがある場合は、割り込み時間をあらかじめある程度バッファをとる
- Inspect(検査) and Adapt(適応) と Scrum Primer には書いてありましたね。実測駆動。 RT @kanu_ 完全主義より適応主義へ
- スプリントの前の、最初の取りかかりの部分 ( = Sprint0 ですね ) をすごく時間をとって、意識を共有することがとても重要だとわかった。
- たぶん各タスクは時間で測定している感じですね。記録して、徐々に予測可能性をあげていくということだと思います。 RT @norihei_siba 時間を基準に見える化しろで合ってるのかな…
- タスクボード＆タスクカード(PostIt)、スタンドアップミーティング(毎朝)、毎週のふりかえり。よくアジャイルをしているっていう人で、素単打アップミーティングしてなかったりする。本をみてそのままやるのはダメ。本では伝わらない (部分がある)。
- リスクを見える化することが重要。熱いから部屋の温度を調節してくれ、とか。自分たち(チーム)が思うことを全部出すのが重要
- タスクボードはいわゆるスクラム盤ですね。作業前、作業中、作業完了
- パフォーマンスモニター。毎週の消化タスク量をグラフに。 (タスクの理想時間単位のベロシティっぽい)
- ふりかえりが、意欲を引き出す。 ( Keep / Problem / Try ) 管理職はチームのプロデューサーですよ。と言ってます。チームに対して「お前なにやってんだよ」じゃなくて「ちょっとどうなってんの？おしえて？」と聞く。
- 私たちの年代の人が頭切り替えないといけないのかな〜っと最近思っています。
- アジャイル開発を阻害する要因。経営者の理解支援の欠如、中間管理職の揺り戻し、「でも我々は違う」と言い訳、コミュニケーションの不足と理解。ちいさなチームから開始
- 開発体制の例。最初は公認会計士を入れた (!).
- ペアプログラミング。やってみないとわかんない領域がある。私は絶対おすすめする。できない理由を聞いたら一晩中しゃべってくれる。やった人じゃないとわからない。品質はペアでやる方が２〜３倍になるんじゃないか。全員が同じロジックで作れる。
- 概要設計したら、みんなで見積もりをする。後はペアプロすればいい。ソースコードがきれいであれば、詳細設計はいらない。ソースコードがドキュメントは昔からある。それができないからモデラーの人が出てきたが、モデルがスパゲッティになったり。
- アジャイルがドキュメント作らないというのは誤解。 必要なドキュメント。意識共有のためのものは作る。
- システムテストの状況例。バグ総数 175例 2日以内に完了した件数は122。
- リファクタリング。ソースコードの領域以外もリファクタリングと言っている。DBのスキーマとかも
- ちゃんとしてるひとは、ちゃんとみてるよ。
- ebackyさん
- 類像現象。目と口にみえる。 => 先入観を持ってみるとコミュニケーションが違ってくるという話（がいいたいらしい）
- 銀の弾丸はない。アジャイルは銀の弾丸ではないし、この話も銀の弾丸ではない
- ５分だと退屈なんで、２分で切ります。
- アジャイルマニフェストの背景にある１２の原則 http://agilemanifesto.org/principles.html
- Martin Fowler's Bliki in Japanese - アジャイルの押しつけ http://capsctrl.que.jp/kdmsnr/wiki/bliki/?AgileImposition
- 「説得でなく説明しよう」 by Martin Fowler
- Fowler は 押しつけが全てダメともいっていなくて、守・破・離 の 守のフェーズでは、「「教義主義」や「非柔軟性」も（一時的には）良い学習ツールとなっているのである。」
- 自己紹介。これからグループ作る。
- マイブームを書く
- 各グループの発表 (１チーム目のは記録とり漏らしました。)
- 「やらされ感よりやってやった感
- 「速いのはニコン」「もっているのはキャノン」
- 「仕様変更が多すぎる」「時間が不定」
- 「変化に適応するマインドが足りなかった」
- 「聞くことをテンプレート化しましょう」 「この雰囲気がいい」
- 「ebacky の時間変更に ちょっと待ってくださいと言えなかったのがよくなかった」「模造紙は邪魔なだけだと思っていた」「いろんな話を聞けた。楽しかった。」
- 「先に聞くべきだった」「チームとしてのコミュニケーションはできた」
- 「アジャイルは何か」「チームワークをとって、納得して楽しくやること」「チームが満足できるような、納得できるようにすすめることに注力した」「全てできなかったけど、やり方を変えたりとか調整することで、今はできなかったけど、お互いの信頼関係を築けた」
- 現場の人から目を離すのだけはやめてください。
- 戦略的な try & error を繰り返す。「ぼくのほうが正しいのに」と思うこともある。でもモチベーションを維持していくことが大事。人から目を離したら価値を生み出すことはできないのではないか。
- 最後の質問「あなたはアジャイルの価値をどのように伝えますか？」
- Ryuzeeさん
- biacさん
- 「本日は唯一のテクニカルセッションです」=> TDDの話
- TDD３原則 by Uncle Bob Martin
- FizzBuzz問題をTDDでつくる。1.考える、2.コード準備(テストコードのソースファイル作る) 「ハイこっから猛スピードで行きますよー」TDD開始。レッド、テストを一個ずつグリーンに。テストを通すのに関係ないから我慢、難しいときは三角測量
