第15章 より効果的なアジャイル:デリバリー
人々が得意とするのは、思考を必要とする、より制約の少ない上流の作業であり、コンピューターが得意とするのは、繰り返し行う必要がある、より決定的な下流の作業である。
テストに関しては人の方が得意なものも多くある気がして少し違和感があったんだけど、決定的な作業はコンピュータにやらせようというのは分かる
デプロイのリードタイム計測はわかる。LeanとDevOpsの科学は最近会社で流行っていて、結構どのPJも計測している
たとえばAmazonはこの数年間、数秒おきにデプロイを行っており、その数は1時間あたり1,000デプロイに上る
いかに大規模かつ冗長性の高いシステムなのかがよくわかる指標だなー。
自動化したデプロイパイプラインのメンテナンスよりも新しい作業を優先させれば、長期的に痛みを味わい、ベロシティを低下させることになる。
これほんとうにそうなんだよな。。。どれくらい必要なのかは対象の技術スタックにはよりけりですが。イメージ的にはどんなに少なくとも全体の作業コストのうち15%以上はかかるなって感覚がある。
DoDの例がそれなって感じだったけど、大規模システムになるとここに「Chaos Monkeyのテストが通っていること」とかも含まれそう。(いわゆるシステム障害系に巻き込まれた時、自分が発生させた時にも重大な障害を拡大せずにいられるようになっているとか)
推奨リーダーシップアクション
検査
■デリバリー/デプロイパイプラインでの自動化の範囲を把握する。
継続的に開発していないやつだと手動になりがちだなっておもった。手元からのデプロイとかは1ステップになっていたりするけど。
継続的に開発しているものであれば、継続的デリバリーにはなってはいるが、テストが不足していることがおおいかなぁ。
■チームにヒアリングを行い、繰り返しが多く、自動化が可能なデリバリー/デプロイ作業に労力がどれくらい投入されているのかを判断する。
インテグレーションテストとスモークテストはまぢで多いなって思う。3回くらいリリースすればすぐに元がとれそうなものがよくある。
■デリバリー/デプロイプロセスにおいてまだ手動で行われている活動をリストアップする。チームの自動的なデリバリーの妨げとなっているのはどの活動だろうか。
上にあげたとおりだけど、他にもあるかなぁ。オートヒーリング的なものがあればもっと楽できそうなものもあるけどリストの後ろの方でいいかも。
■調査を行い、チームの作業が頻繁なインテグレーションを後押しするレベルまで計画されているかどうかを判断する。
少しずつはされているかなー。とくにデプロイ周りの自動化とか、Opsの効率化みたいなことはやっていることがおおいかもしれない。
■コードの変更からソフトウェアのデプロイまでのリードタイムを計測することを検討する。
最近関わっているやつだと、だいたい1週間以内から1日くらいが多い気はする。
適応
■メンバーに対し、作業を頻繁に(少なくとも1日に1回)統合することを働きかける。
この数年ずっとそうしている気がする。自分ができていないこともあるけど。
■自動化したデリバリーとデプロイを支援する完了の定義(DoD)を作成する。
支援するような漸進的なDoDのステップというか、パタンを描き切ったことがない気がする。いつも雰囲気でやりがち。今度ちゃんとやってみたいなって改めて思った。
■チームのビルド環境とデプロイ環境をできるだけ自動化する計画を立てる。
この辺はコンテナ化されていれば本当に簡単になったなっていう印象がある。2015年までとは一線を画すな。コンテナじゃなくてもslsみたいなものでもいいんだけど。
同意。ただ自分のPJはコンテナ導入まで改善がいけなかった。。。
■新しい機能を作成することよりもデリバリー/デプロイパイプラインを正常に動作する状態に保つ作業を優先することをメンバーに伝える。
壊れていたら真っ先に直すっていうのは徹底しているかなー。もし緊急のバグフィックスの必要が1時間後にきてもなにもできないよって言っている。
Jenkinsおじさんにめちゃくちゃ怒らせて笑、直ぐ直さないと1分起きに怒られ続けてストレスがかかるように以前のチームではしていた
■コードの変更からデプロイまでのリードタイムを短縮する数値目標を設定する。
リードタイム自体は半日くらいを目指そうっていうのはよくいうかなー。そこに辿り着くまでにどれくらいかかるのかは2ヶ月くらいから3年くらいと開きがある。エンジニアリングに興味があって、必要な権限が小さい(もしくは手に入れている)と、2ヶ月くらい。2つともNOだと1年とかかかる経験。
2ヶ月~3年で半日なんですね!4月からチーム立ち上げて、半日目指して奮闘中なので一つの目安になります