90年代のエクストリームプログラミングでの好経験の後、スクラム、クリスタル、DSDMなどの似たようなアプローチに興味を持つようになりました。それらを詳しく調べて、これらの新しい方法論の共通の特徴を抽出ししました。それは、予測計画よりも適応計画を優先し、プロセスよりも人材を成功の鍵として重視することです。時が経つにつれ、これらのアプローチはアジャイルソフトウェア開発という旗印の下に集まりました（そして、私は記事を改訂しました）が、この論文の視点は、アジャイルの本質を理解する上で依然として有効な方法であると考えています。

アジャイル手法は主流にしっかりと定着していますが、その人気は問題がないわけではありません。組織のリーダーは、期待した効果が得られないと不満を述べています。この記事では、アジャイルのアイデアを最大限に活用するのに役立つ熟達度モデルを紹介します。熟達度は4つの異なるゾーンを経て進化し、それぞれに独自のメリット、必要な能力、主要な指標があります。

XPやその他のAgile手法の人気が高まるにつれて、10～12人を超えるチームへのXPのスケーリング方法に関する疑問が表面化し始めています。2003年2月中旬、このテーマに特化したワークショップがカナダのアルバータ州バンフで開催されました。この記事では、ケン・シュワバーとマーティン・ファウラーによる基調講演、および他の主要な実践者の報告について述べています。

子供の頃、ニンジンは大嫌いでした。その匂いと食感は嫌でした。しかし、家を出て自分で料理をするようになってから、ニンジンが好きになりました。ニンジンも私の味覚も劇的に変わっていませんでしたが、違いは調理方法にありました。私の母は、彼女世代の多くの英国人と同じように、優れた料理人ではありませんでした。特に野菜料理に関しては。彼女のやり方は、ニンジンを20分以上煮ることでした。その後、適切に調理すれば、ニンジンは全く異なる体験になることを学びました。

これは料理に関するサイトではなく、ソフトウェア開発に関するサイトです。しかし、私は、技術やツールがしばしばかわいそうなニンジンに似ていることに気づきます。技術が正しく行われていないことが本当の理由なのに、ひどいものであると非難されるのです。

人々が「ソフトウェアアーキテクト」という用語を使うとき、彼らは建築建設からのメタファーを使用して、アーキテクトの役割を理解するのを助けています。皮肉なことに、これを行うことで、彼らは実際の建築家の役割を誤解しています。

これまで様々なコード所有権スキームに出会ってきました。それらを3つの大きなカテゴリに分類しました。

ダニエル・テルホルスト・ノースによる最近のソフトウェア職人技に関するブログ記事は、多くのブログでの議論を引き起こしました（興味があれば、以下に要約します）。そこには多くの内容がありますが、彼のテーマの1つが特に私に共感を呼び、この投稿を書きました。

ソフトウェアをきちんと設計する価値はありますか？

2つのソフトウェア開発アプローチの1つ。指示型アプローチは、ほとんどの開発者はそれほど優秀ではない（平均以下の開発者が約50％いるという噂がある）ため、彼らの作業方法を指示する必要があると考えています。この指示は、彼らが作業しているシステムに害を及ぼすことを防ぐためです。通常、このアプローチは、開発者が特定の作業を行うことを防ぎ、複雑な領域から遠ざけることで、彼らが何ができるかを制限する設計やツールに現れます。

2つのソフトウェア開発アプローチの1つ。支援型アプローチは、開発者は責任ある専門家であり、したがって必要なことを自由に実行できるようになるべきであるという見解をとっています。このアプローチに従った設計は、使いやすさを向上させるべきですが、開発者は自分のやっていることを理解していると仮定し、したがって何かを悪用することを阻止しようと努力するべきではありません。そのため、これらのツールは誤用される可能性がありますが、ユーザーはもっとよく知っているべきであり、そうでない場合は自業自得だと考えるべきです。

アジャイル手法の一般的で、おそらく支配的なプラクティスは、構築中のソフトウェアの機能（多くの場合、ストーリーと呼ばれる）のリストを作成することです。これらの機能は、インデックスカード、作業キュー、バーンダウンチャート、バックログ、または選択したツールを使用して追跡されます。

私のお気に入りの名言の1つは、「痛ければ、もっと頻繁に行う」です。表面上は意味不明のように見えますが、深く掘り下げると貴重な意味が得られるという、嬉しい特性を持っています。

成熟度モデルは、個人やグループの現在の有効性を評価し、パフォーマンスを向上させるために次に習得する必要がある能力を把握するのに役立つツールです。多くの分野で成熟度モデルは悪い評判を得ていますが、誤用されやすいものの、適切な方法で使用すれば役立つ可能性があります。

私の著作の常連読者であればご存知かもしれませんが、私はソフトウェア開発について他の職業の比喩を使用することに非常に懐疑的です。特に、エンジニアリングの比喩は、私たちの職業に損害を与えてきたと考えています。それは、設計と構築を分離するという概念を助長してきたからです。

ロンドンのオフィスにいたとき、この問題はリーン製造という文脈で提起されました。リーン製造は、アジャイルの分野、特にポッペンディック夫妻によって頻繁に使用されている比喩です。土木工学からの比喩的な推論を好まないのであれば、リーン製造からの比喩的な推論をもっと好むのでしょうか？

多くの人がアジャイル手法について理解するのが難しいことの1つは、アジャイルの人材重視です。アジャイルプロセスに関心のある人々は皆、プロセスはプロジェクトの成功に対する二次的な影響であることに同意しています。アジャイル宣言の最初の価値は、プロセスとツールよりも個人と相互作用がより価値があるということです。

人々がコードレビューについて考えるとき、通常は開発チームのワークフローにおける明示的なステップとして考えます。今日では、プルリクエストで行われる統合前レビューが、コードレビューの最も一般的なメカニズムであり、プルリクエストを使用しないことはコードレビューの機会をすべて排除すると無意識に考える人が多くいるほどです。このような狭い視点のコードレビューは、多くの明示的なレビューメカニズムを無視するだけでなく、おそらく最も強力なコードレビューテクニックであるチーム全体による継続的な洗練を無視します。

会議に参加し、チームが過去2年間取り組んできたコードを検討しています。今、できる最善のことは、そのコードをすべて破棄して、全く新しいアーキテクチャで再構築することだと判断しました。その運命を決定されたコード、それに費やした時間、ずっと前に下した決定について、どのような気持ちになりますか？

n回目の、そして恐らく最後ではないでしょうが、開発プラクティスの定義、その中のいくつかを「ベストプラクティス」とラベル付けすること、そしておそらく「Cワード」（認定）についての議論に滑り込もうとしています。これは馴染み深い議論であり、まだ始まったばかりですが、議論の行く末の大部分を予測できます。これは、より優れたソフトウェア開発者を見極め、既存の開発者が能力を向上させる方法を特定したいという、至極当然の願望に突き動かされています。

SEMAT（Software Engineering Method and Theory）は、Ivar Jacobson、Bertrand Meyer、Richard Soleyによって開始された取り組みです。その目的は、「確固たる理論、実証済みの原則、およびベストプラクティスに基づいてソフトウェア工学を再構築すること」とされています。ソフトウェア業界の多くの著名な人々と同様に、私も参加を依頼されました。これまでのところ、私はそれを辞退しており、その理由を説明する必要があると感じています。

修・破・離とは、技術を習得する方法に関する考え方です。この名称は日本の武道（特に合気道）に由来し、アリスター・コックバーンによって、ソフトウェア開発の技術や方法論を学ぶ上での考え方として紹介されました。

私のキャリアを通して、人々はソフトウェア開発を「従来の」エンジニアリングと比較してきました。通常、ソフトウェア開発者が適切な仕事をしていないことを非難するために用いられます。電子工学の学位を取得した私にとって、これはキャリア初期の頃から共感できるものでした。しかし、この考え方は間違っています。なぜなら、ほとんどの人が実際にはエンジニアリングがどのように機能するのかについて誤った印象を持っているからです。

ソフトウェア開発における多くの議論は、発言者が指示型思考なのか支援型思考なのかによって左右されます。これらの異なる姿勢は、言語、設計、ツール、プロセスなど、多くの選択肢に影響を与えます。

時々、特定の専門分野を漸進的な方法で使用できるかどうかが疑問視されます。「（セキュリティ｜ユーザーインターフェース設計｜データベース｜国際化｜*）は、アジャイルプロジェクトでは行うことができません。なぜなら、この側面は事前に完了する必要があるからです。」

今月はIEEEのソフトウェアエンジニアリング知識体系の見直し月です。これは、免許制の職業の基盤を築くことができるように、私たちの職業の知識体系を定義しようとする試みです。

時間制約のあるイテレーションは、プロジェクトの作業を分割してスケジュールする方法であり、特にアジャイルソフトウェアプロジェクトに関連付けられています。チームは、ソフトウェアの可視的な機能をユーザーストーリーに分割し、時間を固定期間（例：1週間）に分割します。これをイテレーションと呼びます。次に、ストーリーをイテレーションに割り当てることで、ストーリーをスケジュールします。ストーリーはおおよその見積もりを行い、チームが1イテレーションにいくつストーリーが収まるかを把握できるようにします。

私のキャリアを通して一貫して見られるテーマの1つは、ソフトウェア開発の性質と重要性です。数年前、見込み客が営業担当者に「ソフトウェアは下水管のようなものだ。信頼性が高く動作することを望んでおり、詳細は知りたくない」と言いました。これは、Nicholas CarrがIT Doesn't Matterで論じたアプローチの種類です。対照的に、私たちは、ITがビジネスにとって明確な戦略的推進力となり、新しい市場への参入や市場シェアの大幅な増加を可能にした多くの企業のために仕事をしてきました。では、ITは下水管のようなユーティリティなのか、それとも戦略的資産なのか？

ソフトウェア業界では、「ウォーターフォール」は一般的にソフトウェアプロセスのスタイル、つまり反復型またはアジャイルスタイルとは対照的なスタイルを説明するために使用されます。ソフトウェアにおける多くのよく知られた用語と同様に、その意味は曖昧で、起源も不明瞭です。しかし、その本質的なテーマは、大きな努力を活動に基づいた段階に分割することだと私は考えています。

CHAOSレポートによると、プロジェクトの成功率はわずか34％です。

Standish GroupのCHAOSレポートは、長年にわたってITプロジェクトで数十億ドルもの無駄な費用が発生していると指摘しています。34％という成功率は、2001年の28％という数値よりも実際には改善されています。しかし、「失敗」とは本当にどういう意味なのでしょうか？

YAGNIは元々、「You Aren't Gonna Need It」の頭字語です。エクストリームプログラミングのマントラであり、アジャイルソフトウェアチームで一般的に使用されます。これは、将来ソフトウェアが必要と推定される機能の中には、今構築すべきではない機能があるという主張です。「必要ないだろうから」です。