私の講演ビデオ

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

残念ながら、動画は途中で切り捨てられており、講演の途中で終わっています。フル動画を投稿する方法を見つけることができていません。

#

私はアジャイル宣言を書いた10年後にこの講演を行いました。宣言を書いた歴史的な背景を説明し、それ以来経験してきたセマンティック拡散がその成功の必然的な結果である理由を説明し、アジャイルを気にしないと言う人々は通常間違っており、アジャイル思考において興味深い新しい活動が見られる2つの分野を強調します。

参考資料

• アジャイルソフトウェア開発宣言
• アジャイルガイド

#

2014年、デイブ「プラグマティック」トーマスは、アジャイルソフトウェアの世界の状態にいらいらしてアジャイルは死んだと言いました。オーフスのgoto会議の主催者は、長年アジャイルスタイルの探求に積極的に取り組んでおり、それが宣言の2人の著者である彼と私、そして現場でアジャイルアプローチを使用および拡張している、それを受けてきた人々を集める良い機会だと感じました。

参考資料

• デイブの元の投稿
• 新しい方法論:アジャイル思考の本質を探る私のオリジナルの記事。

#

私は、アーキテクチャがなぜ重要なのかを説明するためにOSCONで14分の基調講演を行うように依頼されました。私が最も良いと思ったのは、ラルフ・ジョンソンの私のお気に入りのメーリングリストの投稿に導かれ、その厄介な用語の意味を探求することから始めることでした。それが終わると、デザインスタミナ仮説の経済的な議論に焦点を当てることで、それがなぜ重要なのかに移りました。

参考資料

• 私は以前、アーキテクチャの意味に関するラルフのメールを、IEEE Softwareの2003年のコラムで徹底的に調査しました。
• デザインスタミナ仮説
• 「どのように」を少し掘り下げて調べるには、モリー・ディッシュマンと私によるアジャイルとアーキテクチャに関する少し長い講演をご覧ください。
• ソフトウェアデザインの経済学に関する少し深い講演
• アーキテクチャという言葉は建築に由来しますが、不適切な比喩です。

#

ますます多くの組織が、ビジネス機能に焦点を当てた自律チームの世界に移行していることがわかります。これは、ソフトウェア開発が対応力を高め、ビジネス成果に焦点を当てるのに役立ちます。しかし、これにより、チーム内およびより広い組織全体で、アーキテクチャにどのような役割が残されるのでしょうか？

私たちは、アーキテクチャは依然として重要であるが、指揮命令ではなくガイダンスに基づいている必要があると主張します。この考え方をチーム内およびチーム間で育むには、いくつかの分野で作業が必要です

• ビジネスコンテキストの理解
• クロスファンクショナルな要件の優先順位付け
• 一連のアーキテクチャ原則の開発
• テクノロジーレーダーなどのアライメントを促進するプラクティスの使用
• 製品の一部として意思決定の記録を保持する

#

多くの場合、人々は、より優れた職人技と品質の必要性を指摘することによって、ソフトウェア設計への努力を正当化します。私の見解では、そのような道徳的な議論は間違っており、代わりに経済学に焦点を当てるべきだと考えています。ほとんどのソフトウェアの取り組みは、悪い設計決定の重みによってチームのスピードが遅くなるため、時間の経過とともに遅くなります。設計に注意を払うことで、これを軽減したり、さらには逆転させたりすることができます。

技術的負債の比喩は、悪い設計の結果について考えるのに良い方法であることがわかりました。利息を支払うか、元本を返済するかということです。技術的負債はぞんざいな設計の結果ではないと主張する人もいますが、技術的負債はさまざまな原因から生じ、最高のチームでさえいくつか発生すると指摘します。

参考資料

• 高品質のソフトウェアにはコストに見合う価値があるのか？
• デザインスタミナ仮説
• 技術的負債
• 技術的負債の象限

#

QConサンフランシスコ2008で、レベッカ・パーソンズと私は、アジャイルアプローチがエンタープライズアーキテクチャグループとどのように連携するかについて講演しました。現在、アジャイルプロジェクトチームとアーキテクチャグループの間には多くの不信と対立があります。私たちは、なぜこれがそうなのかを掘り下げ、これらのグループが協力できる方法を探ります。

#

Thoughtworksの最上級開発者の1人であるバドリ・ジャナキラマンと私の間の、Railsアプリケーションのアーキテクチャに関する議論です。まず、六角形アーキテクチャの概念と、エンタープライズアプリケーション、特にRuby on Railsアプリケーションにおけるデータベースの役割について説明します。これらの原則は、データベースとのコラボレーションを整理するために、Active RecordパターンまたはData Mapperパターンを使用することの決定に影響を与えます。次に、Railsのようなフルスタックアプリケーションフレームワークを使用する方法について、プラットフォームとして扱うか、コンポーネントのスイートとして扱うかの選択について説明します。

参考資料

• P of EAA Book
• P of EAA Catalog

#

ソフトウェアアーキテクチャは、建築業界からの不適切な用語の借用である、定義が曖昧な概念です。私たちは、アーキテクチャを、システムの中で最も重要な属性の選択であり、変更が困難なものに焦点を当てていると見なしています。アーキテクチャは、システムが成長するにつれて進化する可能性がありますが、それが見守られていることを保証するために努力と注意を払うことによってのみ可能です。初期のビジョンニングと継続的な努力の組み合わせによって、それを行うことができます。

（ダラスの動画にはQ&Aが含まれており、合計65分になります。）

#

継続的デリバリーは、効果的なソフトウェアデリバリー組織にとって中心的なプラクティスになりつつあります。この講演では、その仕組みの要点、デプロイメントパイプラインの役割、継続的デリバリーと継続的デプロイメントの違い、およびいくつかの重要な要素について説明します。また、継続的デリバリーの3つの主な利点である、デプロイメントリスクの削減、信頼できる進捗、ユーザーフィードバックについても取り上げます。

参考資料

• ガイド
• 書籍
• 定義
• デプロイメントパイプライン

#

ソフトウェアアーキテクトという肩書きには多くの意味合いがあり、多くの場合、それは良いものではありません。開発者は、象牙の塔に住み、コードの書き方を忘れてしまった手振り身振りの人たちを思い浮かべます。プロジェクトマネージャーは、曖昧な技術的目的を果たすためのイニシアチブで完璧さを追求する技術者を思い浮かべます。しかし、あらゆるソフトウェアプロジェクトの成功には、特にマイクロサービスアーキテクチャへの関心が高まっている現在、アーキテクチャは非常に重要です。

私たちは、従来のアーキテクチャの役割なしに、優れたアーキテクチャをサポートできると主張し、優れた設計と持続可能なアプリケーションを得るためのテクニックを紹介します。

#

マイクロサービスに関する20分間の入門的な講演です。マイクロサービスの定義を取り上げ、よりモノリシックなアプローチと比較し、マイクロサービスアプリケーションをデプロイする前に正しく行う必要のある重要な事項の概要を説明します。

参考資料

• ガイド マイクロサービスに関する記事、書籍、動画への概要とリンク
• マイクロサービスの定義
• マイクロサービスのトレードオフ
• マイクロサービスの前提条件

#

私の同僚であるジム・ウェバーは、エンタープライズにおける統合に対する軽量でビジネス指向のアプローチを取ることで高い評価を得ています。彼はまた、非常に強固で面白い講演者であるという評判もあります。そのため、QCon 2008での基調講演で彼とステージを共有することに興奮すると同時に緊張していました。彼は、いくつかの重要な情報が織り込まれた素晴らしい面白いプレゼンテーションをまとめました。そして私たちは飛び込んで、それを実行しました。おそらく、講演前のパイントが役に立ったでしょう。私たちは、エンタープライズ統合の歴史、強力だと思っているが実際には肥満しているシステムの成長、アジャイル思考の役割、Webの影響（Webが発明された理由についてのジムのユニークな理論を含む）、そしてこれがゲリラSOAにどのようにつながるかについて話します。

#

私は鉄器時代に育ちました。そこでは、新しいサーバーは物理的なマシンとして注文する必要がありましたが、今ではクラウド時代に生きており、新しいサーバーは数分でオンデマンドで起動できます。クラウド時代のスピードと柔軟性を活用するためには、インフラストラクチャの管理方法を再考する必要があります。

コードとしてのインフラストラクチャは、インフラストラクチャの定義を実行可能な形式で保持し、他のコードアーティファクトのように管理し、バージョン管理に保持できるようにします。これにより、より正確なドキュメントが提供され、アプリケーションコードと同じビルドおよびテストの規則に従うことができるインフラストラクチャが提供されます。これにより、より高い一貫性を維持しながら、より大規模なインフラストラクチャ構成に拡張し、変更のリスクを減らし、新しい需要を迅速にサポートできます。

参考資料

• Bliki

#

QConロンドン2012での私たちの基調講演では、データが私たちの生活の中で果たしている役割（そして、それが単に大きくなっているだけではないこと）を見ています。まず、データの世界がどのように変化しているかを見ていきます。それは成長し、より分散化され、接続されています。次に、業界の対応に移ります。NoSQLの台頭、サービス統合へのシフト、イベントソーシングの登場、クラウドの影響、可視化の役割を高めた新しい分析です。開発途上国におけるデータに特に重点を置いて、現在データがどのように使用されているかを簡単に見ていきます。最後に、ソフトウェアプロフェッショナルとしての私たちの個人的な責任がすべてこれに何を意味するのかを検討します。

参考資料

• Infodeck

#

イベントソーシングは、更新を記述するイベントを保存し、そのイベントを処理して現在のアプリケーションの状態を変更することによって更新を処理するアプローチです。次に、イベントログは情報の信頼できるストアになり、すべてのアプリケーションの状態を削除して、イベントストアから再構築できます。基本的に、これはバージョン管理システムによって採用されているアプローチです。イベントソーシングを使用すると、監査、過去の状態を照会する機能、デバッグ、および分散においていくつかの利点が開かれます。

参考資料

• 記事 私の2005年の記事で、このテクニックをより詳しく説明しています

#

最近ではスキーマレスデータベースに関する議論が盛んですが、ほとんどの場合、スキーマが存在します。暗黙的なスキーマは柔軟に見えますが、通常はデータの使用方法を把握するのが難しくなるため、悪化します。人々がスキーマレスを望むとき、彼らが通常必要とするのは可変状態です。これは、カスタムフィールドや均一でないデータ構造に役立ちます。

参考資料

• Infodeck

#

「NoSQL」という用語の起源は、Twitterのミートアップのハッシュタグでしたが、リレーショナルデータベースの20年間の覇権に対する最も深刻な挑戦へと発展しました。名前が偶然につけられた性質上、多くの定義がない広範囲をカバーしていますが、それらの多くをアグリゲート指向データベースという名前でグループ化すると便利です。

NoSQLデータベースは一貫性に関する問題を引き起こしますが、ACIDトランザクションを使用しても、アプリケーションで同時更新を管理する必要がある場合が多いことを覚えておく価値があります。多くのNoSQLデータベースが分散データをサポートする機能は、一貫性をさらに複雑にし、CAP定理の一貫性と可用性（および応答時間）の間のトレードオフにつながります。このトレードオフは、本質的に技術的な決定ではなく、ビジネス上の決定です。

NoSQLデータベースは、現代のデータのニーズにとって深刻な選択肢ですが、唯一の選択肢ではありません。私たちは現在、ポリグロット永続性の時代にあり、特定のデータアクセスニーズに基づいてデータストレージテクノロジーを選択する必要があります。

これは私の最も人気のある講演です（オリジナルのgoto Aarhusビデオで750,000回以上の視聴回数があります）。

参考資料

• ガイド
• 書籍
• 定義

#

ほとんどのNoSQLデータベースは、リレーショナルな世界で見られる一貫性とは異なる方法で人々が考えるように強制します。アグリゲート指向データベースは、リレーショナルシステムにおけるトランザクションの必要性を自然に取り除きます。データベーストランザクションは、同時更新の問題に対処する必要があることを防ぐものではありません。データに分散を追加すると、対処する必要のある一貫性の問題の種類が増加します。CAP定理は、主に分散システムにおける一貫性と可用性（実際にはレイテンシ）の間のトレードオフに関するものです。これは、主にビジネス上の決定です。

（この講演は、私のNoSQL入門講演の一貫性の部分であり、その講演の資料を重複しています。）

参考資料

• 書籍

#

ソフトウェアのプロフェッショナルは、資金提供者の要求するものを何でも行う単なる注文請負業者であると考えることはできません。私たちは、ソフトウェアがユーザーや社会全体にどのように影響を与えるかについて責任があります。隠すものが何もないと思っていても、私たちのプライバシーは、腐敗を防ぎ、社会の進歩を可能にする迷惑な人々を保護するために必要なのです。電子メールのオンラインサービスへの移行は、電子メールプロバイダーの憂慮すべき集中化につながり、重要なコミュニケーション形態である私たちの電子メールの大規模な監視を容易にしています。一見無害な傍受でさえ、私たちに関するこの情報は、政府にとって無害であっても企業にとっては価値があるため、深刻な問題につながる可能性があります。

メールの暗号化の利用を広げることで、これらの問題を軽減する必要があります。そうすることで、大量監視のコストが法外なものになります。この課題は主にユーザーエクスペリエンスとソフトウェアパッケージングの課題であり、暗号化について深い理解を必要とするものではありません。

（この講演の最初の12分は、私の「単なるコードモンキーではない」の講演を圧縮したものです。）

参考資料

• プライバシーは私たち全員にとって重要です。なぜなら、プライバシーは、私たちの社会を自由な状態に保つ迷惑な人々を保護するからです。
• 同じ会議でのティム・ブレイの講演

#

私は鉄器時代に育ちました。そこでは、新しいサーバーは物理的なマシンとして注文する必要がありましたが、今ではクラウド時代に生きており、新しいサーバーは数分でオンデマンドで起動できます。クラウド時代のスピードと柔軟性を活用するためには、インフラストラクチャの管理方法を再考する必要があります。

コードとしてのインフラストラクチャは、インフラストラクチャの定義を実行可能な形式で保持し、他のコードアーティファクトのように管理し、バージョン管理に保持できるようにします。これにより、より正確なドキュメントが提供され、アプリケーションコードと同じビルドおよびテストの規則に従うことができるインフラストラクチャが提供されます。これにより、より高い一貫性を維持しながら、より大規模なインフラストラクチャ構成に拡張し、変更のリスクを減らし、新しい需要を迅速にサポートできます。

参考資料

• Bliki

#

イベントソーシングは、更新を記述するイベントを保存し、そのイベントを処理して現在のアプリケーションの状態を変更することによって更新を処理するアプローチです。次に、イベントログは情報の信頼できるストアになり、すべてのアプリケーションの状態を削除して、イベントストアから再構築できます。基本的に、これはバージョン管理システムによって採用されているアプローチです。イベントソーシングを使用すると、監査、過去の状態を照会する機能、デバッグ、および分散においていくつかの利点が開かれます。

参考資料

• 記事 私の2005年の記事で、このテクニックをより詳しく説明しています

#

非決定論的なテストとは、基礎となるコードに変更がなくても、合格したり失敗したりするテストです。放置すると、テストスイート全体が役に立たなくなります。最初に隔離し、次に修正する必要があります。一般的な原因には、テストの分離不足、非同期性、リモートサービスとの通信などがあります。

参考資料

• 記事

#

多くの場合、人々は、より優れた職人技と品質の必要性を指摘することによって、ソフトウェア設計への努力を正当化します。私の見解では、そのような道徳的な議論は間違っており、代わりに経済学に焦点を当てるべきだと考えています。ほとんどのソフトウェアの取り組みは、悪い設計決定の重みによってチームのスピードが遅くなるため、時間の経過とともに遅くなります。設計に注意を払うことで、これを軽減したり、さらには逆転させたりすることができます。

技術的負債の比喩は、悪い設計の結果について考えるのに良い方法であることがわかりました。利息を支払うか、元本を返済するかということです。技術的負債はぞんざいな設計の結果ではないと主張する人もいますが、技術的負債はさまざまな原因から生じ、最高のチームでさえいくつか発生すると指摘します。

参考資料

• 高品質のソフトウェアにはコストに見合う価値があるのか？
• デザインスタミナ仮説
• 技術的負債
• 技術的負債の象限

#

最近ではスキーマレスデータベースに関する議論が盛んですが、ほとんどの場合、スキーマが存在します。暗黙的なスキーマは柔軟に見えますが、通常はデータの使用方法を把握するのが難しくなるため、悪化します。人々がスキーマレスを望むとき、彼らが通常必要とするのは可変状態です。これは、カスタムフィールドや均一でないデータ構造に役立ちます。

参考資料

• Infodeck

#

リファクタリングは、コードベースの健全性を維持するために不可欠な手法です。多くの場合、テスト駆動開発の文脈で説明されますが、開発者のワークフローには、リファクタリングを使用できる多くの場所があります。問題が明らかになったらすぐに修正できるように、機会主義的に使用することが特に重要です。定期的なリファクタリングの価値は、職人技を求めることにあるのではなく、貴重なソフトウェアの将来の流れを確実にするためのビジネス上の理由にあります。

参考資料

• Infodeck

#

ほとんどのNoSQLデータベースは、リレーショナルな世界で見られる一貫性とは異なる方法で人々が考えるように強制します。アグリゲート指向データベースは、リレーショナルシステムにおけるトランザクションの必要性を自然に取り除きます。データベーストランザクションは、同時更新の問題に対処する必要があることを防ぐものではありません。データに分散を追加すると、対処する必要のある一貫性の問題の種類が増加します。CAP定理は、主に分散システムにおける一貫性と可用性（実際にはレイテンシ）の間のトレードオフに関するものです。これは、主にビジネス上の決定です。

（この講演は、私のNoSQL入門講演の一貫性の部分であり、その講演の資料を重複しています。）

参考資料

• 書籍

#

マイクロサービスに関する20分間の入門的な講演です。マイクロサービスの定義を取り上げ、よりモノリシックなアプローチと比較し、マイクロサービスアプリケーションをデプロイする前に正しく行う必要のある重要な事項の概要を説明します。

参考資料

• ガイド マイクロサービスに関する記事、書籍、動画への概要とリンク
• マイクロサービスの定義
• マイクロサービスのトレードオフ
• マイクロサービスの前提条件

#

私たちがアジャイルソフトウェア開発宣言を書いたのは10年以上前のことですが、アジャイルというミームは、私たちが期待していたよりもはるかに成功を収めています。しかし、あらゆる成功と同様に、セマンティック拡散という危険性が常に存在します。私はアジャイルソフトウェア開発の本質、つまり、予測的な計画よりも適応的な計画を好み、プロセスよりも人を重視することを説明することで、この病気に対抗しようとしています。

次に、アジャイルチームがどのように熟練していくか、そしてアジャイル技術のより熟練したユーザーになるにつれて、通常どのようなステップを踏むのかを考える上で効果的な方法であると私が考えるアジャイル習熟度モデルについて説明します。

参考資料

• 新しい方法論:アジャイル手法の本質に関する私のオリジナルの紹介
• アジャイル習熟度モデル

#

継続的デリバリーは、効果的なソフトウェアデリバリー組織にとって中心的なプラクティスになりつつあります。この講演では、その仕組みの要点、デプロイメントパイプラインの役割、継続的デリバリーと継続的デプロイメントの違い、およびいくつかの重要な要素について説明します。また、継続的デリバリーの3つの主な利点である、デプロイメントリスクの削減、信頼できる進捗、ユーザーフィードバックについても取り上げます。

参考資料

• ガイド
• 書籍
• 定義
• デプロイメントパイプライン

#

この講演を説明するのは難しいです。通常、私はタイトルと概要で講演内容を説明するのが好きですが、この講演は旅のようなものであり、どこへ向かうかを教えるのではなく、私と一緒に足元を探索してほしいのです。アジャイルソフトウェア開発の導入における私の最大の問題点、つまりユーザー、アナリスト、プログラマー間のやり取りの本質から始めます。次に、これらの役割を探り、プログラマーとユーザーの関係、プログラマーが負うべき責任、そして最後にプログラマーが直面する必要があると思う二つの大きな課題について疑問を提起します。

#

人々がアジャイル手法について語るとき、多くの場合、製品とプロジェクト管理の側面に焦点を当てています。小さなリリースを提供し、それぞれのリリースから学習することで、チームはユーザーが必要とするものを学ぶにつれて、迅速に方向を変えることができます。これにより、不確実な環境で価値を迅速に提供するソフトウェアを構築できます。

この働き方には多くの価値がありますが、それを機能させるためには、その詳細だけでなく、全体的なアーキテクチャに対しても、迅速な変更をサポートするコードベースが必要です。このようなコードベースを構築するには、アジャイル流暢度モデルの配信ゾーンを支えるいくつかの技術的プラクティスが必要です。

• 自己テストコードにより、変更を加えたときに自信を持って障害を検出できます。
• リファクタリングにより、バグを発生させることなくコードを迅速に変更できます。
• 継続的インテグレーションにより、チームのすべてのメンバーが互いに干渉することなく変更を加えることができます。
• YAGNIは、ソフトウェアを可能な限りシンプルに保ち、拡張を容易にします。

#

参考資料

• ガイドページ
• 書籍

#

Thoughtworksは、オフィスがある都市でコミュニティ向けのオープンな講演会である「四半期テクノロジーブリーフィング」をよく開催しています。このトロントでのQTBで、スコット・ショーと私は、ITとビジネスの間に新しい関係を構築する方法について話します。IT部門を解散すべきだと考える理由を説明します。

#

QConロンドン2009での講演で、2006年から2008年の間にThoughtworksが行った41のプロジェクトにおけるRubyの使用状況を調査しました。私の講演では、Rubyの生産性、速度、および保守性に関する私たちの見解について説明します。結論として、Rubyは開発環境として真剣に検討する必要があると考えています。

参考資料

• 記事

#

私の同僚であるザック・エクリーと私は、2008年のオバマ大統領選挙で使用されたソフトウェアについて話します。私が特に興味深いと感じたのは、ソフトウェアが選挙運動に対する組織的なアプローチをどのように可能にし、どのように相互作用したかという点でした。

参考資料

• 記事

#

モバイルはまだ従来のウェブよりもトラフィックの割合が小さいですが、そのシェアは増加しているため、効果的なモバイルアプリケーションを開発するための戦略について考える必要があります。製品ビジョンを考え、ユーザーエンゲージメントのスタイルを「リーンフォワード」、「リーンバック」、「ルックダウン」スタイルに分離し、それらをトランスメディアアプリケーションに統合することについて議論します。トラフィックよりも価値に焦点を当てることの重要性、レーザー戦略とカバーユアベース戦略、そしてAndroid、iOS、Webが3つの実行可能なプラットフォーム選択肢であると意見を述べます。ジャイルズは、主要な航空会社との私たちの活動の事例を紹介して締めくくります。

参考資料

• 複数のモバイルプラットフォームのサポート
• モバイル実装戦略の選択
• martinfowler.comのモバイルに関するその他の記事

#

継続的デリバリーの1時間の概要を説明します。トピックには、継続的デリバリーの正当性、デプロイパイプライン、継続的インテグレーション、DevOps、およびデプロイ戦略が含まれます。ハイライトは、ジェズがリリース候補をギリシャ神話の英雄として擬人化することです。

参考資料

• ガイド
• 書籍

#

ビジネスをデジタル組織に変革することについて人々が言うことはすべて非常に良いことですが、その仕事をうまくこなすことができる技術組織がなければ、それは実現しません。

ニコール・フォースグレンは、ITパフォーマンスと組織パフォーマンスを相関させる研究を行っており、DevOpsに関する彼女の研究で、ITパフォーマンスの3つの重要な指標を特定しました。デプロイ頻度、デプロイリードタイム、および平均復旧時間です。宝くじの簡単な例は、迅速なサイクルタイムの金銭的価値を示しています。

高性能な技術チームについて観察された特徴には、継続的デリバリーの使用、ビジネス指向の組織化、テクノロジー主導、および信頼の風土での運営が含まれます。遠くへ行くためには、正しい方向に進む必要がありますが、自分の乗り物も大事にしてください。

#