顧客に価値を届けるということは、
本番環境にソフトウェアをリリースし、
サービスが稼動しているということ。
つまり手前の状態では価値は無い。
価値を測る基準はリリースまでの期間となる。
もちろんミスやバグは許されない。
品質の高いものをリリースする必要がある。
品質を作りこみ、リリースまでの期間を短くするために、
ビルド・テスト・デプロイメントを自動化する。
当然最初の自動化するために痛みを伴うことになる。
自分たちはどこまでできているのだろうか？
皆さんの構成管理およびリリース管理の成熟度モデル（P.487）は、
レベルいくつですか？
（以下抜粋。○：完全抜粋、●：簡略抜粋）
○ケントが率いる統率されたチームには興味深い特徴がいくつもあったが、
そのひとつがソフトウェアを毎晩本番にデプロイしているという事実だった。（P.22）
●アンチパターン：ソフトウェアを手作業でデプロイする（P.41）
・広範囲にわたる詳細な手順書を作成し、リリースに必要なステップを記述する。
また考えられる間違いについても記述する。
・アプリケーションが正しく動作していることを確認するために、
手動テストに頼る。
・リリース当日にデプロイメントがうまくいかず、
その理由を開発チームに対して頻繁に問い合わせる。
○大きな組織では、デリバリープロセスは別々のグループに分類されている。
たとえば、データベース管理者、運用担当者、テスターなどだ。
こうしたサイロをまたいで協力しあうコストは膨大で、
申請書地獄のせいでリリースが遅くなってしまう。
このような場合、開発者やテスターそれに運用担当者はデプロイメントを行うときに、
常に申請書を提出しあうことになる（あるいはメールを送りあうことになる）。（P.45）
○ストレスを軽減するための鍵はこれまで説明してきた
ある種の自動デプロイメントプロセスを準備することだ。
そしてそのプロセスをこまめに実行し、
万が一最悪の事態が起きても変更前の状態に戻せる筋書きをと唱えておくのだ。
初めて自動化するときには、痛みを伴うことになる。
しかし、そのうち間単になっていき、
プロジェクトやあなた自身が受け取れる恩恵は計り知れないくらい大きくなるのだ。（P.58-59）
○テストが苦痛を伴うプロセスで、
リリースの直前に行われているのであれば、
最後になってやるのをやめよう。（P.64）
○非常に奇妙でありながら多くのソフトウェアプロジェクトに共通して見られる性質がひとつある。
それは、開発プロセスの長い間アプリケーションが動く状態にな、というものだ。（P.95）
○高品質を実現するために、大人数での調査に頼るのをやめよ。
まずはプロセスを改善し、本番の品質を作りこめ。（P.127）
●デプロイメントパイプラインを実装する（P.180
・コードがコンパイルできる
・コードは開発者の期待通りに動く。
なぜなら、ユニットテストを通っているから。
・システムはユーザの期待通りに動く。
なぜなら、受け入れテストを通っているから。
・コードには適切なコンポーネントがそろっている。
なぜなら、デプロイできるから。
↓ 実装する。
１．バリューストリームをモデル化して、動くスケルトンを作成する。
２．ビルドとデプロイプロセスを自動化する。
３．ユニットテストとコード解析を自動化する。
４．受け入れてストを自動化する。
５．リリースを自動化する。
○ソフトウェアデリバリープロセルにとって、
最も重要なグローバルメトリクスは、
リサイクルタイムである。（P.186）
○受け入れてストの自動化をあきらめたチームでは、
はるかに重い負荷がテスターにかかることになる。（P.244）
○自動テストを新しくはじめた人は、
コードをテストしやすくするためには設計アプローチを変える必要があることが気づく（P.262）
○細かい効率化については忘れることだ。
97%ぐらいの状況がそうだろう。
早まった最適化は諸悪の根源である。
しかし、重要な残り3%について見逃してはいけない。
良いプログラムはそんな論法では納得せず、
問題のコードを注意深く吟味するだろう。
しかし、それができるのは問題のコードが特定できてからである。（P.285）
○更新するかしないかを決めるために必要な情報が何も与えられないまま、
判断を迫られているようなものだ。（P.327）
○悲観的ロックシステムのゆーざはこんな心配をしているらしいという話を聞いた。
「楽観的ロックシステムのユーザは、
いつもマージ時の衝突の解消に時間を取られているのではないか」
あるいは「自動マージのせいで実行できないコード
やコンパイルの通らないコードができあるのではないか」
といった心配である。
実際のところ、そんな心配は杞憂ににすぎない。
マージ時の衝突は確かに発生する。
大規模なチームならかなりの頻度で発生するだろう。
しかし、通常はそのほとんどすべてが数秒からせいぜい数分で解決できるものだ。
もしそれ以上時間がかかることがあるとすれば、
それは先ほどの説明した指針に従わずに
コミットの頻度を十分上げなかったときぐらいだろう。（P.453）
本番環境にソフトウェアをリリースし、
サービスが稼動しているということ。
つまり手前の状態では価値は無い。
価値を測る基準はリリースまでの期間となる。
もちろんミスやバグは許されない。
品質の高いものをリリースする必要がある。
品質を作りこみ、リリースまでの期間を短くするために、
ビルド・テスト・デプロイメントを自動化する。
当然最初の自動化するために痛みを伴うことになる。
自分たちはどこまでできているのだろうか？
皆さんの構成管理およびリリース管理の成熟度モデル（P.487）は、
レベルいくつですか？
（以下抜粋。○：完全抜粋、●：簡略抜粋）
○ケントが率いる統率されたチームには興味深い特徴がいくつもあったが、
そのひとつがソフトウェアを毎晩本番にデプロイしているという事実だった。（P.22）
●アンチパターン：ソフトウェアを手作業でデプロイする（P.41）
・広範囲にわたる詳細な手順書を作成し、リリースに必要なステップを記述する。
また考えられる間違いについても記述する。
・アプリケーションが正しく動作していることを確認するために、
手動テストに頼る。
・リリース当日にデプロイメントがうまくいかず、
その理由を開発チームに対して頻繁に問い合わせる。
○大きな組織では、デリバリープロセスは別々のグループに分類されている。
たとえば、データベース管理者、運用担当者、テスターなどだ。
こうしたサイロをまたいで協力しあうコストは膨大で、
申請書地獄のせいでリリースが遅くなってしまう。
このような場合、開発者やテスターそれに運用担当者はデプロイメントを行うときに、
常に申請書を提出しあうことになる（あるいはメールを送りあうことになる）。（P.45）
○ストレスを軽減するための鍵はこれまで説明してきた
ある種の自動デプロイメントプロセスを準備することだ。
そしてそのプロセスをこまめに実行し、
万が一最悪の事態が起きても変更前の状態に戻せる筋書きをと唱えておくのだ。
初めて自動化するときには、痛みを伴うことになる。
しかし、そのうち間単になっていき、
プロジェクトやあなた自身が受け取れる恩恵は計り知れないくらい大きくなるのだ。（P.58-59）
○テストが苦痛を伴うプロセスで、
リリースの直前に行われているのであれば、
最後になってやるのをやめよう。（P.64）
○非常に奇妙でありながら多くのソフトウェアプロジェクトに共通して見られる性質がひとつある。
それは、開発プロセスの長い間アプリケーションが動く状態にな、というものだ。（P.95）
○高品質を実現するために、大人数での調査に頼るのをやめよ。
まずはプロセスを改善し、本番の品質を作りこめ。（P.127）
●デプロイメントパイプラインを実装する（P.180
・コードがコンパイルできる
・コードは開発者の期待通りに動く。
なぜなら、ユニットテストを通っているから。
・システムはユーザの期待通りに動く。
なぜなら、受け入れテストを通っているから。
・コードには適切なコンポーネントがそろっている。
なぜなら、デプロイできるから。
↓ 実装する。
１．バリューストリームをモデル化して、動くスケルトンを作成する。
２．ビルドとデプロイプロセスを自動化する。
３．ユニットテストとコード解析を自動化する。
４．受け入れてストを自動化する。
５．リリースを自動化する。
○ソフトウェアデリバリープロセルにとって、
最も重要なグローバルメトリクスは、
リサイクルタイムである。（P.186）
○受け入れてストの自動化をあきらめたチームでは、
はるかに重い負荷がテスターにかかることになる。（P.244）
○自動テストを新しくはじめた人は、
コードをテストしやすくするためには設計アプローチを変える必要があることが気づく（P.262）
○細かい効率化については忘れることだ。
97%ぐらいの状況がそうだろう。
早まった最適化は諸悪の根源である。
しかし、重要な残り3%について見逃してはいけない。
良いプログラムはそんな論法では納得せず、
問題のコードを注意深く吟味するだろう。
しかし、それができるのは問題のコードが特定できてからである。（P.285）
○更新するかしないかを決めるために必要な情報が何も与えられないまま、
判断を迫られているようなものだ。（P.327）
○悲観的ロックシステムのゆーざはこんな心配をしているらしいという話を聞いた。
「楽観的ロックシステムのユーザは、
いつもマージ時の衝突の解消に時間を取られているのではないか」
あるいは「自動マージのせいで実行できないコード
やコンパイルの通らないコードができあるのではないか」
といった心配である。
実際のところ、そんな心配は杞憂ににすぎない。
マージ時の衝突は確かに発生する。
大規模なチームならかなりの頻度で発生するだろう。
しかし、通常はそのほとんどすべてが数秒からせいぜい数分で解決できるものだ。
もしそれ以上時間がかかることがあるとすれば、
それは先ほどの説明した指針に従わずに
コミットの頻度を十分上げなかったときぐらいだろう。（P.453）
コメント
コメントを投稿