Tech Fielders セミナー 東京 [Agile Day] に行ってきました。
1/22(金) Agile Day | これから知りたい、きっかけを作りたい、取り組みたい方に参加いただきたい！ - 長沢智治のライフサイクルブログ - Site Home - MSDN Blogs
＃サイトが期限切れで表示できないので長沢さんのblogにリンク。
まずは長沢さん、三井さん、江端さんそしてLT登壇者の皆さん、素晴らしいイベントをありがとうございます。
本当に楽しかったです：）
『アジリティを向上させるためにマイクロソフトが行ったこと 〜 Visual Studio 開発部門の場合 〜』 ＠長沢さん
米マイクロソフトの Visual Studio 開発を例にする。
マイクロソフトの取り組みとして、Engineering Excellence がある。これはエンジニアの取り組みの中で良いものを共有することで、専門の部隊が用意されている。この部隊がいることによってマイクロソフト社内では常に改善活動がなされている。
バリューアップ
またマイクロソフトではアジリティを向上させるために、トップダウンやボトムアップといった開発者視点ではなく｢バリューアップ｣として｢顧客に対する価値の向上｣を目指している。
バリューアップとは（アジャイルプロジェクトマネージメント宣言）
- タスク達成率ではなく、価値を測定
- 価値を基準にした組織運営、意思決定
- 価値＝投資収益率、信頼関係、透明性、個人力、責任の共有、状況に応じた戦略
情報リソースとして｢Visual Studio Team Systemで実践するソフトウェアエンジニアリング ― 成功する開発プロジェクト運営のために｣がある。
VISUAL STUDIO TEAM SYSTEMで実践するソフトウェアエンジニアリンク
- 作者: Sam Guckenheimer,Juan J.Perez,マイクロソフト株式会社,トップスタジオ
- 出版社/メーカー: 日経BP社
- 発売日: 2007/02/08
- メディア: 単行本
- 購入: 1人 クリック: 7回
- この商品を含むブログ (4件) を見る
マイクロソフトの階層構造
マイクロソフトではライフサイクルを計画と実行で段階的に分けている
- 計画
- Value Pro：ビジョンや主要なテーマ
- Feature Group：投資効果や顧客価値の大きい領域
- Feature：シナリオの実現方法
- 実装
- Deliverable：コード単位の実装方法
- Task & Bugs：実行するための個別の作業単位
これを基準に、WindowsやOffice、SQLServer ごと、製品に合った階層構造を作り上げている。
このプロセスは閉じたものではなく、MPT(Microsoft Process Template)としてTFSのプロセステンプレートとして公開されている。
TFSのプロセステンプレートには先のMTPのほかにもScrumを実装する Agile Software Development もある。
TFS(Team Foundation Server) の意義
タスク管理、バージョン管理、バク管理など、個別のツールを使用するとそれぞれの学習コストと、連携のコストがかかる。これをオールインワンパッケージとすることで、学習コストの低減を狙う。
実際にマイクロソフト社内での TFS 使用実績は年々右肩上がりである、多くのプロジェクトで利用されている。
また、自社の製品を自社で使用するドックフードと呼ばれる方法をとっており、TFS の最大のユーザー企業はマイクロソフト自身。
Visual Studio 2005 と 2008 の開発期間、バグの比較
Visual Studio 2005 ではたび重なる延期と（計画２４カ月、実績３９カ月）、多くのバグが負債となった。
Visual Studio 2008 では、"Get Clean, Stay Clean（キレイにする、キレイを保つ）"を目標に、新規開発を４カ月中断しバグの根絶を図った。
同時にアジャイル開発や、透明性の維持など新しいスタイルへのチャンレンジも行い、その結果 Visual Studio 2005 から２年以内のリリースを達成することができた。
＃Visual Studio 2008 での計画レベルの Feature 数は 1,200 にのぼる
まとめ
- リスクは正直に
- 成功へ実現可能なものを少しずつ
- レポート可能な状況を作る
『開発現場でのムダ取り・改善活動』 ＠三井さん
作成されたソフトウェアの機能のうち65% は使用されていない。
TPS（トヨタ生産方式）を参考に。TPS とアジャイルとの比較を載せたので後で見ておいて。
ムダの排除には、誤解を生まないこと。
一人での作業は思考のムダを生むので、二人一組での作業を行う。
タイムボックスと呼ばれる日々の時間記録を行うのもよい。
改善とは
改善とは不断の努力。決して止めることはしない。
改善の例として
- 大きな企業で模造紙を出しっぱなしにできないような場合、日中は模造紙を壁にはっておき帰るときにカギのついたところにしまう。そのうちに上司が理解を示してくれれば社内のルールを変えることもできる。
- 毎週の振り返り。KPTを行うことで改善する
- 管理者は芸能人のようなマネージャー（引っ張るのではなく、後押しする）を目指す
提案型のソフトウェア開発
開発者がリズムをつかみ日々改善していくことで、顧客に対して受け身ではなく、提案型の開発に変えることができる。
継続して成功するために
成功例をそのままもっていてはだめ。チームを考え、チームにあったやり方で開発する。
『あなたにとって、アジャイルとは何ですか？』 ＠ id:ebacky さん
ebacky way
アジャイルは銀の弾丸ではない、今日の話も銀の弾丸ではない
アジャイルとはなんですか？×５
id:cnaos さんがこの問いに対する答えを書いていたのでマネっこ：）
- 最初の質問「アジャイルとは何か？」
- アジャイルなソフトウェア開発のためのマニフェストを読んだ後での「アジャイルとは何か？」
- アジャイルソフトウェアの12の原則を読んだあとでの「アジャイルとは何か？」
- IT用語辞典「アジャイル」を読んだあとでの「アジャイルとは何か？」
- アジャイルの押しつけを読んだあとでの「アジャイルとは何か？」
アジャイルの押しつけ（Martin Fowler's Bliki in Japanese - アジャイルの押し付け）
普段アジャイルの押し付けは良くないが、時と場合によってはそれが良い場合がある。
それは学習段階、すなわち｢守破離｣の｢守｣の状態のとき。このときは押しつけが良いがほかの場合では良くない。
われわれにできることはアジャイルとは何かを説明できること。
説得ではなく説明できること。
LT2・TDD ってどんな感じ? ＠ biac さん
[お知らせ] Tech Fielders セミナーの資料を掲載しました: TDD.NET
FuzzBizz を TDD でやってみる。
まとめ
どのセッションも素晴らしく有意義な時間を過ごすことができました。
特に ebacky さんおワークショップでは、意地悪な顧客役に悩まされ頭がうにうにの状態になりました。
ゴールも見えず、意図もやることも分からず、もやもやしながらワークショップを行っていた方もいるでしょう。
それでもきっと終わったころには皆さんそれぞれに気づきがあったのではないでしょうか？
それがたとえ主催者が意図したものではなかったとしても、気付きがあったことが一つの成功なんだと思います。
僕が得た気づきは上記のことです。
そうそう
懇親会で ebacky さんから聞いたこと（意訳）
｢今日はプロセスの話をしたけど、技術が大事ではないとは一言も言ってない。技術とプロセスは車輪の両輪で、両方そろわないと幸せにはなれない｣
あと
なんとなくアジャイルを叫ぶ人が哲学っぽくなるのがわかった気がする。
人もいいけど、作成すべきはソフトウェア。これを忘れないようにしないと。。。
人とソフトも車輪の両輪ですね。
