1990年代の終わりに、私はプレゼンテーションでスライドを使用することに個人的な反発をしました。それは、出来の悪い箇条書きのプレゼンテーションにうんざりしていたからです。約10年間、私はスライドを一切使わずに基調講演を行ってきました。ここ1年ほどで、再びスライドを使い始めました。それは主に、同僚のニール・フォード氏の講演を見たことがきっかけです。彼は、恐れられていたスライドデッキを、講演を真に強化するものに変えています（そして、彼のテクニックを伝えるための書籍プロジェクトで協力しています）。再びスライドを使い始めたことで、スライドのセットを効果的な講演の一部にするものは何かについても考えるようになりました。私が従おうとしてきた主な原則は、スライドを、私の話す言葉である音声チャネルを補完する視覚チャネルとして考えることです。このように別々のチャネルとして考えることで、プレゼンテーションでよくある問題、その多くは、ありふれた箇条書きのスライドに根ざしている問題を回避するのに役立つと感じています。

継続的インテグレーションの支持者が持つ一般的な前提の1つは、ビルドは再現可能であるべきだということです。これは、どの時点でも、作業中のシステムの古いバージョンを取得し、当時とまったく同じ方法でソースからビルドできる必要があるという意味です。

講演でビジュアルチャネルとしてスライドを再び使うようになったため、私は自分のポイントを伝えるのに役立つアニメーションをダイアグラムで利用しています。主要なプレゼンテーションプログラム（KeynoteとPowerpoint）は長い間アニメーションをサポートしてきましたが、私はより強力で使いやすいモーショングラフィックツールを探す傾向がありました。

私は自分のラップトップをSnow Leopardにアップグレードすることを長い間考えていました。特に、より良く動作すると言われているAperture 3を入手してからはそうでした。しかし、結局のところ、オペレーティングシステムのアップグレードは通常非常に面倒なので、なかなか実行に移せませんでした。（ただし、Ubuntuのアップグレードはほとんどよりもはるかに苦痛が少ないです。）

2010年のQConサンフランシスコでのJez Humbleと私のインタビュー

フィーチャーブランチを支持する最も一般的な議論の1つは、単一のリリースサイクルよりも時間がかかる保留中の機能に対するメカニズムを提供することです。2週間ごとに本番環境にリリースしているが、完了するまでに3か月かかる機能を構築する必要があると想像してください。リリースで半分実装された機能を表示せずに、メインラインで全員が作業を続けるために、継続的インテグレーションをどのように使用しますか？私たちはこの問題に非常に頻繁に遭遇し、フィーチャーフラグはそれに対処するための便利なツールです。

アジャイルオーストラリア会議のために最近オーストラリアに行った際の散在した印象です。

先週、オーランドで開催されたAgile 2010会議に参加しました。Agile 20xxは、XP Universeとアジャイル開発会議にルーツを持つ、米国最大のアジャイル指向の会議です。私は主要なアジャイル会議の常連参加者ではありませんでしたが、昨年も参加しました。統合された説明を試みるのではなく、ここにいくつかの散在した印象を示します。

私がキャリアを通じて見てきた一貫したテーマの1つは、ソフトウェア開発の性質と重要性です。数年前、見込み客が私たちの営業担当者の1人に「ソフトウェアは下水管のようなもので、確実に動作するようにしたいし、詳細を知りたくない」と言いました。これは、ニコラス・カーがITは重要ではないで述べた種類のアプローチです。対照的に、ITがビジネスのより明確な戦略的イネーブラーとなり、新しい市場への参入や市場シェアの大幅な拡大を可能にした多くの企業のために仕事をしてきました。では、ITは下水管のようなユーティリティなのか、それとも戦略的資産なのか？

アジャイルプロジェクトで見られる一般的なことの1つは、開発チームが単一のオープンチームルームに座っていることです。これはエクストリームプログラミングの初期に提唱され、第2版の主要なプラクティスの1つとして呼ばれました。アジャイル主義者は、チーム内の人々の間の多くの非公式で深いコミュニケーションを促進するため、オープンなチームルームを支持します。

チームルームのワークステーションのデフォルトレイアウトは、中央の机で、全員がその周りに座っています。しかし、私の同僚の多くは現在、テーブルのU字型の中央に開発者がいるUポッドを好んでいます。

私は自分をiFanboyだとは認識していませんでした。iPhoneが発売されてからしばらく経っても入手しませんでしたし、3Gデータプランにアップグレードする唯一の方法だったので入手しました。私はMacを使用していますが、Ubuntuデスクトップも持っています。しかし、iPadを入手しました。そして、これは重要な製品だと思います。

アジャイルブラジルでのPaulo Caroliと私のインタビュー

ニール・フォードと私はパリのUSI（2010）で、アジャイルが機能する理由（方法ではなく）のいくつかの側面について講演しました。これは、手法を見るのではなく、アジャイルを効果的にするいくつかのコアな力について探求します。特に、コミュニケーションとフィードバックの役割、そしてそれらがアジャイル環境でどのように相互作用するかを見ていきます。

多くの強迫的なスナッパーと同様に、私は最近Canon S90カメラを入手しました。これはポケットに入るほど小さいですが、真剣さを気取る人が好むようなもの、つまりフルマニュアルコントロール、RAWファイルサポート、優れたセンサー、そしてf2レンズなどを備えています。

私は最近、早朝のフライトを利用するためにヒースロー空港のホテルに滞在する必要がありました。これを行う際の大きな煩わしさは、ホテルから空港への移動が難しいことです。ターミナル1〜3の中心部からわずか800メートルのホテルがたくさんありますが、そこに行くにはヒースローホッパーバスサービスを利用する必要があります。これは悪いサービスではありませんが、恐ろしく高価です。800メートルの距離で片道4英ポンドです。800メートルは簡単に歩ける距離なので、そのような法外な料金を請求するバスを使うのは本当にためらわれます。幸いなことに、代替手段がありますが、ヒースローはそれを見つけるのを困難にしています。

過去15年間ほど、私は多くの基調講演を行ってきました。私はこれらの種類の講演を常に少しぎこちないと感じてきました。会議のセッション中に講演をする場合は、1つのテーマを選んで講演します。複数のトラックがあることを知っているので、あなたの講演に来る人は、あなたのトピックにある程度の関心があることを意味します。しかし、基調講演では会議全体に話しているので、講演を焦点を絞りすぎないようにする必要があると感じます。私は一時的なイベントをモデリングする複雑さについて話すのが好きかもしれませんが、それは幅広い聴衆にとっては狭すぎるトピックだと感じます。

SEMAT（ソフトウェアエンジニアリング方法論と理論）は、Ivar Jacobson、Bertrand Meyer、Richard Soleyが開始した取り組みです。その目標は、「確固たる理論、証明された原則、ベストプラクティスに基づいて、ソフトウェアエンジニアリングを再構築する」ことであると述べられています。ソフトウェア業界の多くの悪名高い人々と同様に、私も参加を招待されました。これまでのところ、私は辞退しており、その理由を説明する必要があると感じています。

私たちは最近、イタリアのアマルフィ海岸への1週間の休暇から戻ったばかりです。同様の旅行を検討している人のために、ここにいくつかの散在した印象を示します。

RESTアプローチの主要な要素を3つのステップに分解するモデル（Leonard Richardsonが開発）。これらは、リソース、http動詞、ハイパーメディアコントロールを導入します。

私がバージョン管理ツールについて議論したとき、それは意見の非科学的な集まりであると言いました。そうしているうちに、調査を行うことで分析に偽りがあるが魅惑的な数字を追加できることに気づきました。Googleのスプレッドシートを使用すると、調査の実施のメカニズムが非常に簡単になるため、私は抵抗できませんでした。

ソフトウェアでリーン技術の採用を支持するために使用される議論の1つは、トヨタの成功です。では、トヨタの最近の品質の失敗は、リーンソフトウェア開発の根拠を損なうのでしょうか？

私の同僚と私がクライアントに強く推奨する目標の一つに、完全に自動化されたデプロイメントプロセスがあります。デプロイメントを自動化することで、ソフトウェアが「完成」してから、その価値を実現するまでの間に発生する摩擦や遅延を減らすことができます。Dave FarleyとJez Humbleはこのテーマに関する本『継続的デリバリー』を執筆中です。これは、継続的インテグレーションに関連付けられる多くのアイデアを基盤とし、ソフトウェアを迅速に本番環境に投入し、動作させる能力をさらに高めることを目指しています。彼らのブルーグリーンデプロイメントに関するセクションは、あまり活用されていない手法の一つとして私の目に留まったので、ここで簡単に概要を説明したいと思います。

ソフトウェア開発者とツールについて話していると、最も頻繁に話題になるのがバージョン管理ツールです。バージョン管理ツールを使用するようになると（有能な開発者であれば必ずそうなりますが）、それはあなたの生活の大きな一部となります。バージョン管理ツールは、プロジェクトの履歴を維持するためだけでなく、チームが共同作業を行うための基盤でもあります。ですから、バージョン管理ツールに関する不満をよく聞くのは当然のことです。最近のThoughtworksテクノロジーレーダーでは、企業が使用を評価すべきバージョン管理ツールとして、Subversionと分散型バージョン管理システム（DVCS）の2つを挙げました。ここでは、バージョン管理ツールに関して社内で交わした多くの議論を要約しながら、この点について詳しく説明したいと思います。

アジャイル手法に関してよくある誤解がここにあります。それは、ユーザーストーリーがどのように作成され、開発活動を通して流れていくかに焦点を当てたものです。誤解は、プロダクトオーナー（またはビジネスアナリスト）がユーザーストーリーを作成し、それを開発者に実装させる、というものです。これはプロダクトオーナーから開発への流れであり、プロダクトオーナーが「何」をすべきかを決定し、開発者がそれを「どのように」行うかを決定するという考え方です。

プロダクトオーナーまたはアナリストによってストーリーが作成され、開発者が構築するために渡されるアプローチ。これはアジャイル思考の深刻な誤解であると私は見ており、そのため会話型ストーリーを大いに推奨します。