皆さんに質問させてください。

私はこの質問を、ローリー地域で最近開催された製品とアジャイルのミーティングで、何人かのかわいそうな無防備な人たちに投げかけました。

最近、この質問をさまざまなソーシャル メディア チャンネルに投稿したところ、ソフトウェア デリバリー ビジネスでは、一貫性の名の下に自らを奴隷化してしまうことがあると確信しました。

では、この問題を少し掘り下げて、そのような転換点がどのようなものであるかについて同意できないかどうか、まずそれがどのようなものでないかを検討してみましょう ….。

賢明な一貫性

プロダクト マネージャーにとって有益な一貫性の 1 つの例は、ユーザー ストーリーの作成方法です。

優れた一貫性のもう 1 つの例は、UX の世界、特に Don Norman の名著「The Design of Everyday Things」の第 6 章から来ています。

スティーブ・クラッグは、彼の楽しい本「Don’t Make Me Think」の「Billboards Design 101」の章でこの例を紹介しています。

しかしながら、Krug 氏は、私たちが最終的に求めているのは明快さであり、そのための効果的な手段として一貫性を賢く利用することであると主張しています。

そして最後に、一貫性について一言。

一貫性は絶対的な善であるとよく言われます。 それはできません。

サイトやアプリの中で一貫性を保つことは、常に努力すべき良いことです。 例えば、ナビゲーションがいつも同じ場所にあれば、考える必要もなければ、探すのに時間をかける必要もありません。 しかし、少しだけ不統一にしたほうがわかりやすくなる場合もあるでしょう。

Tyrannical Consistency

。

私の冒頭の引用は、エマーソンの『自己-』からです。Reliance,”

私が冒頭で引用したのは、エマーソンの「自己信頼」というエッセイからですが、このエッセイは、崖っぷちやレミングにまつわる運命を受け入れるのではなく、自分の頭で考えるようにと説得力のある主張をしています。

先ほど述べたように、私は冒頭の質問をさまざまなソーシャルチャネルやMeetupで行いました。

• 開発者が README.md アーティファクトのタイプミスを修正するために JIRA ストーリーを作成しないと、スクラム マスターが怒る。
• ソフトウェア デリバリーへのより現代的なアプローチには不確実性が多すぎるため、キャパシティ プランニングが、顧客が支払ったものを確実に得るための唯一の真の方法であると主張するプロジェクト マネージャー。
• 現場の誰かが「ストーリーのサイズを決める方法について、すべての開発チームを一致させる方法はないのか」と質問する。
• アーキテクトが、機能セットをサポートするために何を構築すべきかを知ることができる唯一の方法であると主張して、あらゆるシナリオに対してすべてのものを前もって設計することを主張する。
• 新しい Lucene ベースの全文検索インフラストラクチャで提供される結果が、既存の NoSQL データベース実装から返される結果と 100% 同じであることを要求する顧客。
• TPS の定型文とそれに付随するカバー シートを使用して完璧にフォーマットされ、包括的に完成されていない限り、他の人からのユーザー ストーリーを受け入れることを拒否する製品マネージャー。

このようなシナリオの結果、開発チームは、一貫性に固執するあまり、フラストレーションに苛まれることになります……善意ではありますが、誤った優先順位付けにより、価値のある適切な機能を迅速かつ継続的に発見して提供する能力が大きく妨げられます。

追加の知恵

私よりも賢い人たちも、一貫性への愚かな従属について警告しています。