私見

小さなチームのためにプロダクトを独立した小さな単位に分割しないほうがよい理由

今日、スケーリングについて二人が同じ勘違いした助言をしているのを聞きました。違うチームが作業するには、プロダクトを独立した部分に分けるのが良いというものです。この助言は決まり文句と言えるほどありふれています。アジャイルのコーチング及びトレーニングのコミュニティに広く見られる盲点がここに現れています。

LeSS Q&A

Q. デザイナーをどのようにチームに巻き込むか

実例による仕様 Cucumber/Java Specification By Example (SBE) 電子バーテンダー

プロダクトバックログリファインメントを行なっている間は、ユーザーストーリーではなく、実例による仕様(Specification By Example、以降SBE)を用いることをお勧めします。ビジネス側の人と開発者は、ホワイトボードを使用して共同作業します。 Cucumberを使用すると、非技術者であっても Fea...

LeSS全体像スクリプト

これがLeSSの簡単な全体像です。 まずは、LeSSの中心となる10個の原則をみていきましょう。

認定LeSS基礎研修(CLB)(Certified LeSS Basics)

大規模スクラム(LeSS)とは、複雑なプロダクト(典型的にはソフトウェア)を複数のチームで開発するためのアジャイルなアプローチです。LeSSはスクラムにインスパイアされたものです。ただし、スクラムガイドが適するのは12人以下の会社のみですが、LeSSは20人、200人、または数千人規模の会社の問題にも対応していま...

局所最適化バイアス:今ここで 対 後にどこかで

ソフトウェア開発について深く理解していない人は、大規模なアジリティは複数の「超生産的」なチームの作業の総計だと考えるかもしれません。一見、論理的に思えるかもしれません。馬の足が早ければ早いほど、馬車も速く進むと考えませんか?しかし、賢明な読者のみなさんは、ソフトウェア開発は馬車を引っ張る馬とはわけが違うことは理解...

大規模組織におけるソフトウェア開発の誤解その3:チームの視野は狭くて良いか、プロダクト全体を見るべきか?

ほとんどの企業では、どのようなプロダクトでも11人以上が従事しています。彼らはスクラムを適合させる(局所最適化)ためだけに「プロダクト」を再定義し、プロダクト全体より狭い意味に変えてしまうことがあります。しかしこれは、言葉が本来の意図とは真逆のことを意味してしまう鏡の迷宮への入口なのです。

大規模組織におけるソフトウェア開発に関する誤解 その1:知的作業において「依存関係」が生じるのは、逃れられない物理法則の結果なのか?

第一次世界大戦の直前、フレデリック・テイラーの同僚であった H・L・ガントは、工程同士の依存関係をはっきり表示するプロジェクト管理表を提案しました。これはガントチャートと呼ばれ、物理的実体によって依存関係が生じる製造・建設・物流等の分野において有用です。