MicrosoftのAgile Dayに行ってきた
皆様お疲れ様でした。
イベントレポートって何をかけばいいんだろ？
個人的な感想とふりかえりになります。また、勝手な解釈をしている部分が混じっている事を先にお詫びします。
見た感じ、スーツ率高い、参加している人はプロジェクトリーダ/マネージャが多いみたい。
また、実際に現場でアジャイル開発に取り組まれている方が多いような感じがしたけど、実際のところどうだったんだろう。
私の立場
セッションごとに印象に残ったこと
セッション１：アジリティを向上させるためにマイクロソフトが行ったこと〜Visual Studio 開発部門の場合〜
マイクロソフトでのアジャイルな取り組みについて。
大規模な製品開発（VisualStudioの開発）にアジャイルを取り入れた事例の紹介。
ちょっとまとめきれないので、印象に残ったところだけ書き出したけど、ヒントがいっぱい詰まっていそう。
- VisualStudio2008の開発では新規開発を中断し、既存バグの根絶に集中した。
- 標語は"Get Clean, Stay Clean"
- ジョエルテスト#5「新しいコードを書くまえにバグを修正するか？」に通じる話。
- リスク報告の正直さHonestlyが大事
- 大雪のためスケジュールが遅延するなんて事まで書いてある。
TeamFoundationServerってどんなツールなんだろう。
セッション２：「開発現場でのムダ取り・改善活動」
アジャイルの成功事例をベースに、どういった改善活動をおこなったのかを紹介。
- 時間が有言実行の障害になる。
- 前に言った事でも、時間がたつと誤解されやすくなる。
- ウォーターフォールは正解主義、アジャイルは適応主義。
- 現時点で分かっている情報を元に仮説を立てる。
- アジャイルでのマネージメントの役割は管理ではない、自律の手助け。
- 数値はとってもいいけど、管理に使うな。
- アーキテクチャ分析は最初にチーム全員でやる。
- ゴールの共有、仕様の理解のため？
- 「初めてのアジャイル開発」でも以下のように述べられている。
最新のIID手法では、開発構想書および「概要レベル要求のトップ10」一覧の作成や、負荷やユーザビリティや多言語化といったアーキテクチャに大きな影響を及ぼすような要因の分析を、早い段階でベースライン化するよう推奨している。
- 問題が起こったとき、「お前なにやってんだよ！」ではなくて、「ちょっと教えてくれる？」で情報を引き出す。
セッション１で出ていたリスク報告の正直さを保つために必要な態度だろう。
たとえば、指先に熱いものが触れていて、それが脳に報告されなかったら、大やけどする。
神経が正直に情報を伝えるから反射的に手を引っ込めることが出来る。
リスクを見逃さないために正直さがプロジェクト必要なのかも。
怒れるマネージャはもらいが少ない。
セッションの内容ではないけど、懇親会の時に聞いた、受託開発でのアジャイル成功事例はおもしろかった。ドキュメンタリーとして読みたい。
