Subscribed unsubscribe Subscribe Subscribe

マイクロソフト Tech Fielders イベント 〜 「カボチャが馬車になる」

sukusuku-scrum, suc3rum, scrum

マイクロソフトの長沢さんが企画したイベントに参加してきました。

参加者は、知っている顔が4分の1くらいで、あとはたぶん、本来のターゲットである、これからアジャイルを勉強してみようという人たちだと思います。MSさんのチャネルというのは、あまりこれまで関わってこなかったので、すごく面白かったです。

セッションも実践的で、とても参考になりました。みなさん、自分できるところ(半径5m)からチャレンジしている感じが伝わってきて、そういうところから、きっと社会は変わっていくんだろうな(Fearless Change)、と思いました。


プレゼントで、VisualStudioロゴ入りプランニングポーカー(私がAgile2009でもらってきてXP祭りでプレゼントしたものと同じだと思う)を出していただいたので、懇親会で、プランニングポーカーの使い方セッションをさせていただきました。皆さんすごく楽しそうに参加していただきました。うれしかった。

「プランニングポーカーをもらえなかったんですけど、どこかで売っていますか?」「売っているのは知りませんが、自作もできるし、じゃんけん(指)でもいけますよ」ということで、プランニングじゃんけんも伝わった!


今回おもしろいなと思ったのは、マイクロソフトさんが、ツールの紹介より、アジャイル開発のの事例の紹介など、開発者サイドの話題を優先させていたこと。Youtubeや検索広告など、力のあるユーザ生成コンテンツを中心として人を集めておいて、満足度とリターン率やコミット率を高め、その脇にCMを配置しておく手法に似ているな、と思いました。マイクロソフトは、インフラに徹して効率的に集客できる訳です(たぶん)。

- - -

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