Skip to content

Instantly share code, notes, and snippets.

@keisuke-umezawa

keisuke-umezawa/dev_ops_handbook_sec1.md

Last active November 13, 2016 10:36
Show Gist options
  • Star 0 You must be signed in to star a gist
  • Fork 0 You must be signed in to fork a gist
  • Save keisuke-umezawa/62622067a374f7ea858c290dfc5af7f8 to your computer and use it in GitHub Desktop.
Save keisuke-umezawa/62622067a374f7ea858c290dfc5af7f8 to your computer and use it in GitHub Desktop.
Download ZIP
Raw
dev_ops_handbook_sec1.md

Intoroduction

Three ways(3つの大切な価値観)

  • Flow
    • 顧客に対するDeveloptmentからOperationまでのデリバリーを加速させる
  • Feedback
    • より安全なシステムを可能にする
  • Continual Learning and Experimentation
    • 組織的発展のための信頼性の高い文化と科学的手法を育む

歴史

Lean

  • トヨタ生産方式を研究して編み出された方式
  • 以下の2つを融合することで、組織全体の全体最適を追求した生産管理方式(マネージメントシステム)。
    1. 暗黙知ベースの、ボトムアップ型 (旧来の日本の製造業の生産システムに多い)
    2. 形式知ベースの、トップダウン型の知識
  • 7つの原則
    1. ムダをなくす
    2. 知識を作り出す
    3. 決定を遅らせる
    4. 速く提供する
    5. 人を尊重する
    6. 品質を作り込む
    7. 全体を最適化する
  • keyward

Agile

  • ソフトウェア工学において迅速かつ適応的にソフトウェア開発を行う軽量な開発手法群の総称

発祥

  • 開発業務において、どれだけのコストをかけて(「いつまでに」「いくらで」「何人で」など)ある作業を終えられるか予測を立てる「見積もり」が重要である。
  • ウォーターフォール開発での見積もり
    • 多くの場合、見積もりが失敗に終わっていた
    • なぜなら、「全ての要求は予め全て決定できる」という前提で開発をおこなっていから。
      • 以下の理由から「全ての要求は予め全て決定できる」は偽とするべき
        • 以前よりも開発するシステムの規模は大きくなっているから。
        • 要求は開発中に変化しうるものだから。
        • 開発が進むに従って、新しい要求が見えてくることがあるから。など
  • Agile開発での見積もり
    • 「全ての要求を予め全て決定できる」を前提としない。
    • 「見積もりは後工程になるほど不確実性が減る」という特性に着目している
      • 「要件定義」->「設計」->「実装」->「テスト」->「運用」と進むに連れて見積もりの不果実性は減る
    • したがって、下記の2ではなく1の手法のほうが、ある作業に対して早い段階で精度の高い見積もりができる
      1. 「優先度の高い作業Aに着目し、要件定義から運用まで終えた後、次に優先度の高い作業Bに取り組む」
      2. 「要件定義をすべて終えてから設計に進み、設計をすべて終えてから実装にすすみ、・・・」

keyward

Raw
dev_ops_handbook_sec2.md

The First Way: the Principles of Flow

概要

目的

  1. 変更がデプロイされるまでの時間を短くすること。
  2. 提供されるサービスの信頼性と質を高めること。

方法

  1. value streamを可視化する
  2. Work In Process(WIP)のタスク数を制限する
  3. 各タスクのサイズを減らす
  4. 受け渡しの回数を減らす
  5. 継続的に障壁の特定と改善を行う
  6. value stream内の困難と無駄を排除する

value streamを可視化する

効果

  • どこでタスクが詰まっているかわかる
  • 右から左へ素早くチケットが流れていくため、タスクの引き渡しが速くなる
  • リードタイムを測ることができる

方法

  • visual work board(カンバンボード、スクラムボード等)を使う

Work In Process(WIP)のタスク数を制限する

効果

  • マルチタスクは悪であり、それを制限することができる
  • タスクが完了できない原因を発見しやすい
    • 例えば、何か先行するタスクを待つ必要がありタスクが完了できない、ということに気付くことができる

方法

  • カンバンボードでの、各カラムのチケット数を制限する

各タスクのサイズを減らす

効果

  • WIPの時間が減る
    • 先行するタスクを待つ時間が。少なくなるため
  • リードタイムの変化を少なく、かつ最小限にすることができる(つまり、見積もりが短く、かつ正確になる)
  • ある機能の提供されるまでの時間が短縮される
    • 複数機能を同時にリリースするよりも、一つ一つリリースしていくほうが、ある機能についてはより早く提供することができる
  • 間違いに早く気付ける
    • 早い段階でリリースされるため、間違いに早く気付くことができる

方法

  • タスクを分割する
    • 分割できる場合は分割するべき
    • 特に、完了までの見積もりが正確に予測できない場合は分割すべき

受け渡しの回数を減らす

効果

  • 受け渡し時コミュニケーションコストを減らすことができる
    • 要求、詳細報告、優先順位付け、スケジュール確認、コンフリクト解消、テスト、検証、ドキュメンテーションなど

方法

  • タスク処理の自動化を行う
  • 組織編成を行う

継続的にボトルネックの特定と改善を行う

効果

  • ボトルネックを発見して改善することで、リードタイムを改善する
    • 常に、唯一の障壁がボトルネックとして存在している

方法

  • ボトルネック発見の手がかりとして以下を頭に入れておこう
    • ボトルネックは下の順序で移動していく
      1. 環境構築
      2. コードのデプロイ
      3. テストのセットアップと実行
      4. システム・アーキテクチャの問題

value stream内の困難と無駄を排除する

効果

  • リードタイムを改善する

方法

  • 無駄・困難の発見の手がかりとして以下を頭に入れておこう
    • 無駄・困難の原因の分類
      1. 完了しきっていないタスク
      2. 価値を生み出さない余分なプロセス
      3. 価値を生み出さない余分な機能・特徴
      4. マルチタスク
      5. 待ち時間
      6. 余分な動作(受け渡しなどのこと)
      7. Defects(情報や材料や製品に、間違い・消失・曖昧さなどがあること)
      8. 標準化されていない仕事
      9. ヒーロー的能力が要求される仕事

keyward

  • value stream
    • 製品あるいはサービスを顧客の手に運ぶことに要求される全体的な活動
  • プロセスタイム
    • 「タスク開始」～「タスク完了」までの時間
  • リードタイム
    • 「チケット作成」～「タスク完了」までの時間
    • リードタイム = 「チケット作成～タスク開始までの時間」+ プロセスタイム
  • マルチタスク
    • 同時に複数のタスクをこなすこと
    • 悪い理由
      1. タスクのルール、目的を再確認しなければならない
      2. いちいちタスクのコンテキストを切り替えるコストを払わなければならない
      3. 研究でも悪であることは明らかになっている
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment