今日、ソフトウェア開発に携わる多くの人々は、ペアプログラミングという実践について聞いたことがあるでしょう。しかし、業界での普及はまだら模様です。その受け入れ度合いが異なる理由の一つは、そのメリットがすぐには明白ではなく、中長期的に効果が現れるためです。また、「2人で1台のコンピュータで作業する」ほど単純ではなく、不快に感じるとすぐに却下してしまう人も多いでしょう。しかし、私たちの経験では、ペアプログラミングは共同作業を行うチームワークと高品質なソフトウェアにとって不可欠です。

リモートワークと共同勤務という単純な二分法ではなく、チームの分散にはいくつかのパターンがあり、それぞれに異なるトレードオフと効果的な手法が適しています。確証的な証拠を特定することは不可能ですが、私の感覚では、ほとんどのグループは共同勤務の方が生産性が高いです。しかし、分散型の勤務モデルを使用することで、より広い人材プールにアクセスできるため、より生産性の高いチームを構築できます。

最新のソース管理システムは、ソースコードにブランチを簡単に作成できる強力なツールを提供しています。しかし、最終的にはこれらのブランチをマージする必要があり、多くのチームは複雑に絡み合ったブランチに対処するために膨大な時間を費やしています。チームがブランチを効果的に使用できるようにするためのいくつかのパターンがあり、それらは複数の開発者の作業を統合し、本番リリースへのパスを編成することに集中しています。全体的なテーマは、ブランチを頻繁に統合し、最小限の労力で本番環境にデプロイできる健全なメインラインに焦点を当てるべきだということです。

シップ/ショー/アスクは、プルリクエストの機能と変更を継続的に出荷する機能を組み合わせたブランチ戦略です。変更は、シップ（レビューなしでメインラインにマージ）、ショー（レビュー用のプルリクエストを開くが、すぐにメインラインにマージ）、またはアスク（マージする前に議論のためにプルリクエストを開く）のいずれかに分類されます。

プラットフォームチームは、プラットフォームの採用を確実にするために、他のチームへの独自の依存関係を持っています。つまり、他のチームのコードベースにコード変更を適用することが、彼らの成功にとって非常に重要です。そのチーム間コラボレーションにはさまざまなパターンがあり、適切なパターンを選択するには、プラットフォームの採用フェーズと、外部の影響を受け入れるチームとコードベースの両方の能力によって異なります。

ふりかえり、または人々が議論し、その議論から学ぶことを目的とするあらゆる種類の会議を使用する場合、時々非効率的なセッションを経験するでしょう。それは不思議なことではなく、ほとんどの人に起こります。この記事では、これらの不幸な状況の3つ、つまり、洞察の生成をスキップすること、変更できないことで迷うこと、そして大声で話す人に支配されることについて説明し、解決策を提供します。

優れた技術設計の決定は、コンテキストに非常に依存しています。共通の目標を持って定期的に協力するチームは、定期的にコミュニケーションを取り、変更を迅速に交渉することができます。これらのチームは、アライメントの強い力を示しており、その強い力を利用したテクノロジーと設計の決定を行うことができます。大規模な組織では、独立して作業し、コラボレーションの頻度が低いチームと部門の間には、ますます弱い力が存在します。これらの強い力と弱い力の違いを認識することで、各レベルでより良い意思決定を行い、より良いガイダンスを提供できるため、より権限を与えられたチームがより迅速に動くことができます。

テクノロジーは常にスマートになり、より強力になっています。これらのテクノロジーが導入されると、組織の生産性は向上するどころか低下していることがよくあります。これは、テクノロジーが開発者の複雑さと認知的なオーバーヘッドを増やし、効果を低下させているためです。この記事では、シリーズの最初の記事として、開発者の効果を最大化するためのフレームワークを紹介します。調査を通じて、開発者が1日に200回行うマイクロフィードバックループを含む、主要な開発者のフィードバックループを特定しました。これらは、開発者にとって迅速、シンプル、インパクトのあるものになるように最適化する必要があります。いくつかの組織がこれらのフィードバックループを使用して、全体的な効果と生産性をどのように向上させたかについて検討します。

インセプションとは、プロジェクトの開始時に、関係者を一同に集め、進行中の作業の共通の方向性と作業スタイルを設定するために行われる活動です。リーンインセプションは、1週間で完了できる、焦点を絞った形式のインセプションです。この期間中に、製品の主要な機能と顧客を理解し、最小限の実行可能な製品の特徴を策定するためのキャンバスを構築します。

加速するとは、より速く動き、速度を上げることを意味します。データを効果的に活用することは、現代世界で繁栄したいと願うあらゆる組織にとって重要であり、データメッシュは、組織がデータから価値を大規模に実現する方法を示しています。データメッシュ加速ワークショップは、チームと組織が現状を理解し、次のステップがどのようなものになるかを模索することで、データメッシュ変革を加速するのに役立ちます。

伝統的なリベラルアーツの学位は、プロダクトマネージャーにとって非常に重要なスキルを提供します。

優れたオーディオを使用し、ギャラリービューを使用し、話していないときはミュートにし、猫を歓迎します。

私たちや同僚は、クライアントのためにアーキテクチャの評価を行うように依頼されることがよくあります。これを行うとき、これらのシステムに関与するアーキテクトは、これらのシステムのパフォーマンス、障害に対する回復力、および新しい機能を簡単にサポートするように設計されている方法について話します。しかし、めったに話題にならない問題は、さまざまなシステムがどのようにビジネス価値に貢献し、この価値がこれらの他のアーキテクチャ属性とどのように相互作用するかです。

ペアプログラミングの利点は広く受け入れられていますが、ペアのローテーションに関するアドバイスは依然として議論の余地があります。チームメイトはいつ、どのくらいの頻度でペアをローテーションする必要がありますか？そして…毎日ペアをローテーションしたらどうなるでしょうか？私たちは、毎日のペアローテーションの演習を通じて3つのチームと協力しました。私たちは、チームがペアリングの利点と課題を振り返り、それらを解決する方法を検討するための軽量な方法論を開発しました。当初の懸念は克服され、チームは頻繁にペアをローテーションすることの利点を発見しました。ペアを頻繁に交換することで、ペアリングのメリットが大幅に向上することがわかりました。ここでは、開発した方法論、観察結果、および参加したチームメンバーによって共有されたいくつかの一般的な懸念と洞察について共有します。

しばらく前、私はアカデミックキャリアに進む途中のポスドクとチャットしていました。彼は、私が実際に役立つ研究について彼に情報を提供できると感じたため、研究トピックについて私に意見を求めていました。私はあまり役に立ちませんでしたが、そのための最善の方法は、業界でしばらく時間を過ごして、ソフトウェア開発がどのように行われているのか、そしてどのような問題が研究努力に値するのかを感じることだと述べました。この考えに対する彼の答えは非常に厄介なものでした。

アライメントマップは、進行中の作業とビジネス成果のアライメントを視覚化するのに役立つ組織情報ラジエーターです。作業は、通常の機能追加、または再構築、技術的負債の返済、ビルドとデプロイパイプラインの改善などの技術的な作業である可能性があります。チームメンバーは、アライメントマップを使用して、日々の作業がどのようなビジネス成果を改善することを目的としているかを理解します。ビジネスおよびITスポンサーは、進行中の作業が彼らが関心のあるビジネス成果にどのように関連しているかを理解するために使用します。

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

データ分析と可視化への関心が高まるにつれて、組織内に存在するデータから人々が洞察を得られるような、興味深い可視化に多くの努力が注がれています。これらのダッシュボードのほとんどは個人での利用を目的としていますが、より共同的な目的で使用する傾向が強まっています。

アジャイル手法に関するよくある誤解があります。それは、ユーザーストーリーがどのように作成され、開発活動を通じて流れていくかを中心にしています。その誤解とは、プロダクトオーナー（またはビジネスアナリスト）がユーザーストーリーを作成し、それを開発者に実装してもらうというものです。この概念は、プロダクトオーナーから開発への流れであり、プロダクトオーナーは*何を*行う必要があるかを決定し、開発者は*どのように*行うかを決定するというものです。

アジャイルソフトウェア開発は、要件分析、テスト、開発間のサイロをいくつか解消してきました。デプロイメント、運用、保守は、ソフトウェア開発プロセスの他の部分から同様に分離されてきた他の活動です。DevOpsムーブメントは、これらのサイロを取り除き、開発と運用の間のコラボレーションを促進することを目的としています。

会議やワークショップの際に、順位付けやサブセットの選択のためにいくつかの項目について投票を行うと良いでしょう。これを迅速かつ簡単に行う方法がドット投票です。

オープンスペースは、自己組織化された会議をまとめるのに役立つアプローチです。私は1997年にNorm Kerthによって初めて紹介され、それ以来、何度も使用され、自分自身でも使用してきました。それは、十数人程度の小規模なグループや、100人または200人程度のより大規模なグループでうまく機能するように見えます。1日から3日の期間で実施されるのを見てきました。私がこれまで見てきたバリエーションを加えて説明します。クレステッドビュートは、約20人の小規模な年次ワークショップで、アジャイルユニバース2002は、会議で約100人程度が1つのトラックでオープンスペースを使用しました（その後も続けていますが、私は参加できませんでした）。foocampは、これを数百人で行いました。この手法はハリソン・オーウェンによって開発され、彼の著書で詳しく説明されています。

ペアプログラミングは、開発者が2人のグループで作業するソフトウェア開発プラクティスです。すべての重要なコードは、通常、1つのモニターと、多くの場合、1つのキーボードを備えた並んで座っている2人のプログラマーによって記述されます。彼らはコードを追加する際に、各ステップについて一緒に話し合います。

ペアプログラミングに関する一般的な誤解のいくつか。

コミュニケーション技術の進歩により、リモートファーストスタイルで働くチームが増加しており、この傾向はCovid-19パンデミックによる強制的な隔離によってさらに加速されました。しかし、リモートで運営されているチームでも、対面での集まりから恩恵を受けることができ、数ヶ月に一度は行うべきです。

すべてのアジャイル手法は、システムの開発者と、最終的な受益者である顧客との直接的なやり取りの重要性を強調しています。アジャイルマニフェストは「事業担当者と開発者は、プロジェクト全体を通して毎日協力しなければならない」と述べており、これはインタラクションの頻度の高さを強調するためのものです。エクストリームプログラミングは、オンサイト顧客の実践を通じてこれを強調しています。

人々がコードレビューについて考えるとき、通常は開発チームのワークフローにおける明示的なステップとして考えます。最近では、プルリクエストで実行される統合前レビューが、コードレビューの最も一般的なメカニズムであり、プルリクエストを使用しないとコードレビューの機会がすべて失われると多くの人が無分別に考えています。このようなコードレビューに関する狭い見方は、多くの明示的なレビューのメカニズムを無視するだけでなく、おそらく最も強力なコードレビュー手法である、チーム全体による継続的なリファインメントを無視しています。

プロジェクトのタイムラインは、プロジェクトの振り返り中に作成する価値のあるものです。タイムラインは、プロジェクト中に発生したさまざまなイベントと、それらがプロジェクトにどのように影響したかを示す必要があります。

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

XPスタイルの計画を使用している場合は、開発者から迅速な合意見積もりを取得する必要があります。見積もりを投げ込むことで、開発者が見積もりに関して同じような見解を持っている場合（それをメモして次に進むことができます）や、意見の相違がある場合（ユーザーストーリーについて詳しく話し合う必要がある場合）をすばやく判断できます。