eyecatch
Tue, Feb 9, 2016

継続的インテグレーションは死んだ

このエントリでは、Yegor Bugayenkoによる記事、Continuous Integration is Deadを紹介する。 (Yegorから和訳と転載の許可は得た。) 以下はその全文の和訳だが、意訳超訳が混じっているので、もとのニュアンスを知りたければ元記事を読んでもいいし、読まなくてもいい。 (adsbygoogle = window.adsbygoogle || []).push({}); 数日前、「なぜ継続的インテグレーションは機能しないのか」という私の記事がDevOps.comに公開された。 それとほぼ同じ日に、Twitterで非常に否定的な批評が送られてきた。 継続的インテグレーションが機能しないとはどういうことだ。この人気なすばらしいアイデアが。 その求めてもない質問への返事をここに書く。 私はこの分野に関して多少の経験があるが、それに基いた論拠は挙げない。 代わりにロジックだけを頼りにする。 ところで、私には50以上のオープンソースや営利プロジェクトで5年間Apache Continuum、Hudson、CruiseControl、Jenkinsを利用した経験がある。 さらに、数年前fazend.com(2013年にrultor.comに改名)というホスト型継続的インテグレーションサービスを開発した。 現在TravisとAppVeyorのアクティブユーザでもある。 継続的インテグレーションはどう機能すべきか 考え方はシンプルで明確だ。 masterブランチ(Subversionなら/trunk)に新しくコミットをする度に、継続的インテグレーションサーバ(またはサービス)はプロダクト全体のビルドを試みる。 「ビルド」というのはコンパイル、ユニットテスト、統合テスト、品質解析などを意味する。 その結果は「成功」か「失敗」だ。 もし成功だったら「ビルドがクリーン」であると言う。 もし失敗だったら、「ビルドが壊れている」と言う。 通常、ビルドが壊れるのは、以前通っていたユニットテストを通らなくするような新しいコードをだれかがコミットしたからだ。 これは問題の技術的な面だ。 この部分はいつも上手くいく。 まあ、依存が直書きされてるとか、ビルド環境が十分分離されていないとか、ビルドの並列性が完全じゃないとか、そういう問題はあるかもしれないが、この記事はそれらについてではない。 アプリケーションが上手く書かれていてユニットテストが安定しているなら、継続的インテグレーションは簡単だ。 技術的には。 組織的な面を見てみよう。 継続的インテグレーションというのは、ビルドを実行するサーバだけを指すのではなく、上手く機能すべき管理的/組織的プロセスだ。 プロセスが上手く機能するとは、Jez Humbleが「継続的デリバリー: ビルド、テスト、デプロイの自動化による確実なソフトウェアリリース」の55ページで言っていることそのものを意味する。 もしビルドが失敗したら、開発チームは何をやっていたとしてもそれを中断して、そのビルドの問題を速やかに直す。これが重要だ。 これが上手くいかず、上手くできないことだ。 誰がこれを必要としているのか 既に述べた通り、継続的インテグレーションとは、開発チーム全体を止めて壊れたビルドを修正させることだ。 繰り返すが、ビルドが壊れたら直ちに、それを修正し、ビルドを安定した状態に戻すコミットを入れることに全員が集中すべきだ。 ここでひとつ疑問が生じる。誰が、活動中のチーム内の誰がこれを必要としているのだろうか? 一刻も早く新しい機能をリリースしたいプロダクトオーナ? または、締め切りに責任を持つプロジェクトマネージャかもしれない。 もしくは、他の誰かが作りこんだバグをプレッシャーを受けながら修正すること嫌うプログラマかもしれない。 誰がこの継続的インテグレーションを好み、誰が必要としているのか? 誰でもない。 実際に何が起こるのか 教えよう。 私は何度も見たことがある。 シナリオはいつも同じだ。 継続的インテグレーションのビルドステータスは単に無視されるようになる。 ビルドがクリーンか壊れているかにかかわらず。 そして以前のやり方が継続される。 Jez Humbleが推奨するように開発を止めて問題に対応したりしない。 代わりに、継続的インテグレーションサーバから来る情報を無視する。 しばらくして、次の日かもしれないし月曜日かもしれないが、空いた時間を探してビルドの修正に取り組む。 これは単に、ダッシュボードの赤いボタンが嫌で緑に変えたいからだ。 規律についてはどうか そう、これには別の見方もある。 チームに規律を徹底させることもできる。 ビルドは常にクリーンで、壊した人は何らかの罰を受けるという厳格なルールを設けることができる。 これを試すとなると、恐怖駆動型開発を実施することになる。 プログラマは、ビルドを失敗させたら少なくとも謝罪しなければならなくなるため、リポジトリへのコミットを恐れるようになる。 この場合の厳格な規律(私は大好きだが)は、単に状況を悪化させる。 開発プロセス全体が遅くなり、プログラマはビルドを壊さないように自身のコードをできるだけ長い間手元に保持する。 いざコミットするとなった時、変更は巨大になっていて、マージは非常に難しいか、時に不可能になる。 結果、プログラマが書いた多くのコードがコミットされること無く捨てられる。 あの恐怖因子のせいだ。 OK。解決策は?
eyecatch
Mon, Jan 11, 2016

ソフトウェアアーキテクトは何をするのか?

このエントリでは、Yegor Bugayenkoによる記事、What Does a Software Architect Do?を紹介する。 (Yegorから和訳と転載の許可は得た。) 以下はその全文の和訳だが、意訳超訳が混じっているので、もとのニュアンスを知りたければ元記事を読んでもいいし、読まなくてもいい。 (adsbygoogle = window.adsbygoogle || []).push({}); 君のプロジェクトにはソフトウェアアーキテクトが居るだろうか? 必要だと思う? まあ、ほとんどのアジャイルチームはそのような役割を明確には定義せず、民主的な感じで働く。 全ての重要な技術的な意思決定はチーム全体で議論され、最多数の投票を得た解決策が採用される。 しばらくして、このようなチームが「ソフトウェアアーキテクト」バッジを誰かのTシャツに付ける事に決めたときは、もっとも評判のいいプログラマがそのバッジを手にする。 このバッジが彼の責務を変えることはまれだけども。 結局、チームは同じように働き続け、全員を巻き込んだ技術的議論を楽しむ。 つまり、ソフトウェアアーキテクトは責務が明確に定義された役割というよりもステータスになる。 それは最年長で最も権限のある人へのチームメンバからの尊敬の印になる。そうだろ? 全く間違っている! アーキテクトは品質の責任を負う 普通はアーキテクトは最も知識、スキル、経験、権限がある人がなるということは明らかだ。 もちろん普通はアーキテクトは他の人よりもものを知っていて、必要に応じて外交的指導的手腕を発揮してその知識を伝達する。 アーキテクトは普通はチームの中で最も賢いやつだ。 しかしこのことは、彼をアーキテクトたらしめているものではない。 そして、チームに必要なものでもない。 私のソフトウェアアーキテクトの定義こうだ。 アーキテクトは品質の責任を負う人だ。 「責任 (blame)」を職責 (accountability) とか 責務 (responsibility) と言い換えてもいいが、私は「責任 (blame)」という言葉を使うのがいいと思う。 なぜなら、開発中の製品の全ての品質問題がアーキテクトの個人的な失敗であることをより強調するからだ。 もちろん、その責任の対価として、品質がよかった場合には満足した顧客からの称賛は全てアーキテクトのものだ。 これがチームに必要なものだ。 開発するソフトウェアの品質に対して誰かが個人的に責任を負うのだ。 プロジェクトマネージャの仕事は、アーキテクトによる全ての技術的決定に対して誰にも不信を抱かせないようにすること アーキテクトが他のメンバにどのように責任を委譲するかはアーキテクト自身の仕事だ。 知識やスキル、品質管理ツール、ユニットテストフレームワーク、権限、コーチング、体罰、何を使おうとも、それが彼の仕事だ。 プロジェクトマネージャは品質管理をソフトウェアアーキテクトに委譲した。 それをさらにどう委譲するかはソフトウェアアーキテクト次第だ。 ソフトウェアアーキテクトの役割は全てのプロジェクトにおいて重大だ。 たとえたった二人のプログラマが同じデスクで働いている場合でもだ。 二人のうち一人はアーキテクトでなければならない。 理想的なアーキテクトは上記の長所の全てを持つ。 彼は全員の意見を聞いて考慮に入れる。 彼はよいコーチであり先生だ。忍耐もある。 彼は効果的な伝達者であり交渉人だ。 外交官だ。 技術的な領域のエキスパートだ。 しかし、たとえこうした長所全てを持たなくても、彼の決定は常に最終決定だ。 そして、プロジェクトマネージャの仕事は、アーキテクトによる全ての技術的決定に対して誰にも不信を抱かせないようにすることだ。 これが委譲というものだ。 責任には常に権力が伴う。 プロジェクトマネージャは定期的にアーキテクトの成果を評価すべきだ。 チームで開発中の製品の品質はアーキテクトの個人的な(!)責任だということを思い出してほしい。 どんな問題であっても彼の問題だ。 彼を責めたり罰したりすることを恐れてはいけない。 ただし、罰を有効なものにするためには、アーキテクトの行動に対して全力で応えるべきだということをを忘れてはいけない。 繰り返すが、彼の決定は最終決定だ。 もしプロジェクトマネージャが製品の品質に満足せず、またアーキテクトがその状況を改善しないなら、アーキテクトを交代させる。 彼をプログラマに降格させ、他のプログラマをアーキテクトに昇格させる。
eyecatch
Tue, Aug 11, 2015

スタンドアップミーティングはダメマネージャーが好む手法

このエントリでは、Yegor Bugayenkoによる記事、Daily Stand-Up Meetings Are a Good Tool for a Bad Managerを紹介する。 (Yegorから和訳と転載の許可は得た。) 以下はその全文の和訳だが、意訳超訳が混じっているので、もとのニュアンスを知りたければ元記事を読んでもいいし、読まなくてもいい。 (adsbygoogle = window.adsbygoogle || []).push({}); スタンドアップミーティング (または単純にスタンドアップ)は、「チームマネージャに状況報告をするためのデイリーチームミーティング」であるとWikipediaに書かれている。 こうしたミーティングは、ソフトウェア開発チームの間でとても人気な手法ではあるが、単なる悪であり、よいマネージャは決してやらない。 以下、その理由を説明する。 私は、スタンドアップのやり方が適切だったり不適切だったりする、と言いたいわけではない。それについて述べた記事は大量にある。 また、スタンドアップを上手く機能するように実施する方法についてアドバイスしようとしているわけでもない。 よいマネージャはデイリースタンドアップを決して実施すべきでないと言っているのだ。 スタンドアップは、単に「機能しない」だけでなく、非常に悪い、時に破壊的なものをマネジメントプロセスにもたらす。それがアジャイルかどうかにかかわらず。 一方、ダメなマネージャは常に、デイリースタンドアップを重要なマネジメント手法として使う。 私の意図を説明するため、マネジメントをいくつかの異なった視点から見ながら、よいマネージャとダメなマネージャが仕事をどのように進めるかを比べてみよう。 情報 ダメなマネージャは進捗を尋ねる。 オフィスを歩き回り進捗を訪ねて回るのは、ひどいマネージャの崇高な習慣だ。 彼は、プロセスと情報伝達フローを適切に構築できるほど賢明ではなく、チームが何をしているかを知らない。 しかし、彼は進捗を知る必要がある。彼もまた上司からちょくちょく尋ねられるからだ。 必要な情報を収集する唯一の方法は、チームに「今何の作業をしているの?」と尋ねることだ。 朝のスタンドアップは、メンバの作業内容を知らないことに気付かれずに、このうっとうしい質問を正式に尋ねる最高の場だ。 よいマネージャは必要なときに報告を受ける。 プロジェクトマネージメントにはコミュニケーション管理が必要だ。 情報伝達フローが適切に構成されていれば、チームメンバはいつどのようにマネージャに報告すればいいかが分かる。 何か問題が起きたとき、そういう状況をどのように報告しなければいけないかを全員が知っている。即時、直接報告するのだ。 作業が完了したとき、必要に応じてプロジェクトマネージャにどのように知らせるかを全員が理解している。 完璧なプロジェクトマネージャは決してチームに質問しない。代わりに、チームが必要なときにマネージャに報告する。 そして、報告を怠るメンバが出たときには、その壊れたコミュニケーションチャネルを修復するのがよいプロジェクトマネージャだ。 ただし、情報収集のためにデイリーミーティングは決して実施しない。 よいマネージャとして、何がゴールで何がプロジェクトマネージャ(またはスクラムマスタ)として重要かをチームに伝えるべきだ。 チームメンバは、マネージャがチームの進捗、リスク、障害、失敗について知るために何が重要であるかを知っているべきだし、チームメンバがマネージャの期待に沿えなければどんなトラブルに陥るかを理解しているべきだ。 プロジェクトやチームが取り組んでいる最も重要な課題についてをチームに伝えることは、よいマネージャとしてすべき仕事だ。 また、よいチームメンバとしては、重要な情報をつかんだら、すぐにマネージャに知らせることが重要だ。 これが完璧なマネージメントというものだ。 もしそのようなチームワークを築いたなら、開発者が今日何をしてどんな問題にあったかを、明日の朝まで待ってから尋ねる必要はなくなる。 マネージャはこういった情報をもっと早く、まさに必要なタイミングで知るようになる。 オフィスの外にいるときでさえ、プロジェクトで起こっていることを知ることができるようになる。 実際には、オフィスは全く不要にさえなるが、これはまた別の機会に議論したい。 デイリースタンドアップはプログラマ間で情報交換する最高の機会で、スクラムマスタに報告してフィードバックを受けるだけの場ではないと言う人がいるかもしれない。 もう一度、同じことを言うが、なぜ、その日の必要になった時点で情報交換をしないのか? なぜ、10人のメンバを毎朝集めて、その内たった5人だけに関係することを議論する必要がある? 答えよう。ダメなマネージャは、チームメンバ間で情報交換する場を用意する他の方法を知らず、朝のスタンドアップを適切なコミュニケーションモデルの代わりとして使う。 こういったミーティングは、マネージャが熱心に働いていて、大げさな給料を受け取るに値するかのような印象を与える。 対照的に、よいマネージャは定期的な状況報告ミーティングをいっさい実施しない。 なぜなら、効果的なコミュニケーションツールの使い方を知っているからだ。 例えば、問題追跡ツール、メール、コードレビュー、意思決定ミーティング、ペアプログラミングなど。 責任 ダメなマネージャはマイクロマネージメントをする。 ダメなマネージャはプロジェクトマネージメントのことをほとんど知らないので、大きな不安を抱えている。 彼はチームのコントロールを失うことを恐れていて、チームを信頼せず、いつも十分な情報を得ていないと感じ、上司から状況を尋ねられたときに動揺する。 このため、彼はチームメンバを抗うつ薬として使う。チームメンバが彼の言う通りのことをしているとき、彼はより安心と安定を感じる。 デイリースタンドアップミーティングは、彼がメンバに何をしているかを尋ね、代わりに何をすべきかを指示するためのすばらしい機会だ。 このマネージャは、メンバに個人の目標と計画を報告するよう強制し、必要だと感じればそれらを修正する。 次のようなやりとりをを何回聞いたことがある?「私はテストXをやるつもりです。…いや、それは来週だ。今日はYをやってくれ。」 これはマイクロマネージメントだ。デイリースタンドアップはマイクロマネージャのための完璧なツールだ。 よいマネージャは責任を委譲する。 理想的なマネージメントには4つのステップが必要だ。 複雑なタスクを小さいサブタスクに分解する。 それらを部下に委譲する。 報酬と、ペナルティと、ルールをはっきりと伝える。 報酬はちゃんと支払われること、ペナルティは免れられないこと、ルールは厳格に守られることを確実にする。 完璧なマネージャは日々何をするかをメンバに指示しないし、業務時間の使い方にも口を出さない。 彼は信頼し、コントロールする。 彼は、メンバに作業方法を指示して自尊心を削ぐようなことは決してしない。 すばらしいマネージャは次のようなことを言う。「今日はテストXをやるつもりだって?