Subscribed unsubscribe Subscribe Subscribe

「アジャイルソフトウェアエンジニアリング」 TFSの背景にある考え方

マイクロソフトの長沢さんより献本いただきました。ありがとうございます。


今年2月に、この本の原著を書店で手に取って、そのコンパクトさと扱っているトピックの適切さに驚き、すぐ長沢さんにこの本の日本語訳は出ていないんですか、とTwitterで質問したのを覚えています。

非常に多くの書籍を参照しながら、最新のアジャイルの全体像をTFSにマッピングしながら、コンパクトにまとめた本なので、この本をきっかけに、その原典を読んだり、読書会やトレーニングなど、知識と実践を深めていくといいと思います。

  • 初めてアジャイルに触れられる方は(きっとたくさんいると思います)...
    • 1〜4章の概念を丹念に読んで、その先に進んでいただくといいと思います。
    • 最低限本書を読んでから、TFSのスクラムテンプレートを使うことをお勧めします。
  • Visual Studio に以前から触れている方、アジャイル好きな方は第9章はとても楽しめると思います。
  • テストについても、第6章(TDD)、第7章(CI)、第8章(受入テスト)と、順に重要な概念をきちんと分けて紹介しており、素晴らしいと思います。


以下、駆け足ですが、内容のメモを書きますので、ご参考になれば幸いです。

第1章 アジャイルコンセンサス

アジャイルスクラム、リーンのコンセプトをぎゅぎゅーっとまとめている。"複雑 Complex"な問題であるところのソフトウェア開発に、エンピリカルなやり方(実証的プロセスモデル)で対応する、というスクラムの根本的な部分を説明している。

  • 実証的プロセスモデル (Empirical Process Model)
  • スクラム
  • 潜在的に出荷可能 (Potential Shippable) : いつでも出荷できる状態のインクリメントを作る
  • プロダクトバックログ
  • ムリ、ムラ、ムダ
  • 透明性
  • 技術的負債
  • バグピンポンをなくす
  • 自己組織化したチーム

トヨタは長いこと次のように考えてきた。「現場の従業員」は、心のない、ただの製造機械の歯車ではない。彼らは「問題解決者」「革新者」「変革推進者」になり得る、と。米国の企業はプロセスの改善策の案出を専門的スタッフに頼っていたが、トヨタはすべての従業員に、発生した問題を解決し、新しい問題を未然に防ぐための技術とツールと許可を与えていた。

第2章 スクラムアジャイルプロセスと Visual Studio

スクラムのタイムボックスと道具の説明

  • リリース
  • スプリント
  • デイリースクラム
  • 検査と適応
  • タスクボード
  • かんばん (最近人気のデヴィッドアンダーソンの KANBAN)

第3章 プロダクトオーナーシップ

プロダクトオーナー必見。要件定義の手法。

  • ビジネス価値、顧客価値
    • 顧客蔵の明確化
    • 顧客の pain (痛点)の理解
  • 狩野モデル
  • デザイン思考、ストーリーボード
  • ユーザーテスト
  • 品質

第4章 スプリントの実行

  • プランニングポーカー
  • 規定中心(prescriptive) vs 事実中心(descriptive)
  • ダッシュボード

この他にも、規定中心のメトリクスの誤用によって、あまり目立たないけれども同じくらい深刻な問題が引き起こされます。つまり、最高点をもらえない人がやる気をなくしたり、数字をもてあそぶかチームを去るかの選択を迫られたりします。

第6章 開発

チケットの扱い方と、TDD、バージョン管理。

  • テスト駆動開発(TDD)
  • コードカバレッジ
  • コードレビュー
  • 予想外の動作の原因究明
  • パフォーマンス
  • バージョン管理、ブランチとマージ

第7章 ビルドとテスト環境

継続的インテグレーション(CI)

  • 完了の定義
  • 継続的インテグレーション
  • ビルドの自動化 + ビルド検証テスト
  • デプロイの自動化
  • 実稼働環境に合わせた開発環境の構築の需要性(仮想マシンで)
  • テストの自動化、デイリービルド

第8章 テスト

受入レベルのテスト

  • 探索的テスト
  • プロダクトバックログ項目のテスト
  • 「再現できない」との決別
  • 見つかったバグの処理 - すぐ修正か、PBIか
  • どのテストを自動化すべきか
  • テストシナリオの自動化
  • ロードテスト (実環境に近い開発環境)
  • リスクベーステスト

第9章 Microsoft Developer Division で得た教訓

VS2005からVS2010 にいたる、マイクロソフトでのアジャイル適用の歴史。必読。

Microsoftでは、製品リリースにこぎ着けると通常は人事異動が行われます。社員にとって、この人事異動は、キャリアを開発し、新しい挑戦を行って個人の満足度を高める好機です。(中略) これは企業にとっても社員全体にとっても健全なやり方ですが、短期的には一種の記憶喪失状態を生み出すことになります。

第10章 継続的フィードバック

次期バージョンのTFSで取り込まれる、もっとアジャイルな方向性