アジャイル開発の本質とスケールアップ読了

感想おまちしてます!

もし、ソフトウェア業界におけるソリューション開発の現在の能力よりも、市場がより早い変化を必要としている、という前提を認めるなら、「そのために何ができるだろうか?」という問いを持つことになるだろう。私にしてみればその答えは、アジャイルだ

アジャイルは使える – そして、スケールアップ可能であるという結論までを語る本。原書はScaling Software Agility: Best Practices for Large Enterprises (Agile Software Development Series)

社内の先輩が「面白い本を見つけたので読書会をしようと思う」という話をしてくれた。
その方はマネージャになるのだけれど、データ分析とかが得意なアーキテクトでもあり、
「この人が開催する勉強会は面白い」と思って、「絶対面白いからやりましょう」と伝えた。

それから、数か月がたち、今月で勉強会も終わりを迎えようとしている。
最初は20名ぐらいの参加者だったけど、今は、数人になってしまった。
でも、毎回、とても面白いディスカッションができていて、勉強会の価値はあったんじゃないかな。

自分は、「スクラムの本質」で、自分のチームのスクラム部分を話したり、
「継続的インテグレーション」で、CIサーバ環境を作り、その結果成功したチームと失敗したチームの事例紹介をした。
中でも、CIサーバは、その環境にのせて流れに乗るまでがつらいようで、
わずか数件のチャレンジでありながら、%でいうと25%しか成功しなかった。

そこで学んだのは、「導入して流れをつかむまではサポートがいる」ということ。

まず、驚いたのが、「テストを作りメンテナンスしていく」ことができない人が75%もいることだ。
さらに、「テストを書いたこともない」という人もいるのにはびっくりした。
よって、サポートとして、テストの作り方や、テストのメンテナンスなど、テクニカルな面が必要になることがわかった。

また、一部チームからは「CIに登録しただけで、その後サポートがない」というFBももらった。
誰もが、CIの魅力には飛びつくが、いざ自分がやるとなると、そこまでコストを割いてくれないという
悲しい現実を知った。
最終的には「現場が続ける」必要が出てくる。そういったチームは、「誰かがテストをしてくれる」という感覚で
サポートを求めるので、丁重に断っていった。

アジャイル開発のスケールアップは本当に難しい。

以下、気になったワード。

  • テストと品質保証の組織もまた大きく変わる
  • アジャイル開発では、継続的、並行的、早期にテスト
  • アジャイル開発でのアーキテクトの役割(自分がアーキテクト関係の仕事なので気になった)
    • アジャイルマニフェストの原則には「最善のアーキテクチャは自己組織化されたチームから浮かび上がるとあるが、アーキテクチャはアジャイルチームにとって非常に重要
    • ↑のような自然発生するアーキテクチャを「ローカルなアーキテクチャ」と著者は読んでおり、システムレベルのアーキテクチャとわけて書かれている
    • 「ローカルレベル=協調的に自然発生」「システムレベル=システム全体として、システムアーキテクト、ビジネスアナリストが決定」
    • アジャイルコンポーネントチームは、開発者、テスター、プロダクトオーナー、アジャイルマスター or スクラムマスターという構成になり、そのチームの外にアーキテクトやQA担当(全体を統括)が存在する(これは案かも)
  • 自己組織化されたチームにもリーダーは必要
    • 正しい方向に方向付けられる必要があり、リーダーシップ不在ではなく、リーダーシップのそのスタイルに特徴がある。管理されているのではなく、リードされている形
  • ふりかえりは、反復のために主要な指標を確立する方法(定量的評価)、そして、何がうまくいったか、そして、何がどれほどうまく行かなかったかを決定する方法(定性的評価)がある
    • 定量的評価例
    • 居てレーションに入れたストーリーの数と達成したストーリーの数
    • ストーリー受け入れ率
    • 却下されたストーリーの数
    • 延期されたストーリーの数
    • 次のイテレーションにずれこんだストーリーの数
    • 追加されたストーリーの数
    • テスト数、カバレッジ、バグ数
    • 自動化されたテストの率
  • 定性的評価
    • うまくいったこと
    • うまくいかなかったこと
  • 良いユーザストーリー(INVEST)
    • 独立している(Independent)
    • 交渉可能(Negotiable)
    • 価値がある(Valuable)
    • 見積もり可能(Estimatable)
    • 小さい(Small)
    • テスト可能(Testable)
  • 大規模組織におけるスクラムおよびアジャイルの展開
    • 概観、評価、そしてパイロットの準備(やはり成功例から広めるのがはじめやすい模様)
    • パイロットでは、スクラムマスタートレーニング、プロダクトオーナートレーニング、指標を確立・・・とすすめる
    • 組織への展開で、トレーニング、アジャイル関係の読み物の提供、体験記などのFBを行う
  • アジャイル開発の評価
    • アジャイルプロセスアセスメント指標を作る
    • バックログの管理ができているか?
    • リリース計画はできたか?
    • ビルドは成功し続けているか?などなど、アジャイル開発の流れを再確認してレーダーチャートにする
    • レーダーチャート:プロダクトオーナー、リリース計画作りと追跡、反復計画作りと追跡、テストプラクティス、プラクティスやインフラの開発などの視点で作る

    テスト駆動開発入門
    テスト駆動開発入門 ケント ベック Kent Beck

    ピアソンエデュケーション 2003-09
    売り上げランキング : 135995

    おすすめ平均 star
    star翻訳が残念
    starリファクタリングって何
    star何のプログラムを作っているのかがキー

    Amazonで詳しく見る by G-Tools

    あとで読もうと思うTDDの指南書