正しいこと -スクラムは、正しいことを行っているかどうかさえ気にしません。 バックログの形成は、所有者の製品に任されています。 開発チームは、正しいことをするかどうかはあまり気にしません。 スケープゴートがあります-ウーナー製品です。 彼とすべての需要と。 OUNERの製品は、ユーザーに関するすべてを知って、市場に関するすべてを知って、トレンドについてすべてを知って、一般的にすべての製品を独力で決定するために、すべてを知っているべきです。
また、注意、 引用
プロダクトオーナーはチームの一員ではありません
概して、製品全体の成功はOUNERの製品に基づいています。 彼がファイルを持っている場合、チームにどんなクールなビーバーがいたか、プロジェクトにどんなクールなカバレッジテストがあったかは関係ありません。
物事は正しい -スクラムは通常、どのように行われるかを気にしません。 これはチームに任されています。 主なことは、チームが集まって、何が正しいか、そして一般的に正しいことをどのように行うかを議論することです。 チームがこれを行う方法-スクラムはまったく同じです。 スクラムは、チームがプロセスを改善するのに十分クールであることを示唆しています。 残念ながら、これは常にそうではありません。 たとえば、経験豊富な開発者のいないチームでは、何が良いのか、何が悪いのかを迅速に把握することはできません。
高速 -スクラムは一般に、物事が迅速に行われるかどうかを気にしません。 チームができるように-それはします。 たぶん速い-素晴らしい。 それはできません-集まって状況を修正する方法について話しましょう。 このために、振り返りがあります。
少なくとも何か良いこと -実際、スクラムはまだ何かを提供し、フィードバックを高速化し、機能横断的なコマンドを作成することを強くお勧めします。 プロジェクトの結果を1年間待っていたマネージャーにとって、3か月後に機能が制限された作業バージョンを見るのは奇跡のように思えます。 彼がボタンを突くと、ここでシステムが予期せず動作するということが可能になりました。 彼がさらなる開発に影響を与え、機能を優先的に選択することが可能になりました。 フィードバックループを減らすことは、概してスクラムが確実に提供する唯一の有用なことです。 それ以外のすべては、スクラムトレーナーから直接提供されます。個人的な経験とソフトウェア開発プロセスのビジョンからです。
プロセスの外部の単純さのために、スクラムは多くのマネージャーにとって非常に魅力的であるように思われました。 しかし、外部コンサルタントのいない経験の浅いチームの場合、スクラムベースのプロセスを改善することは非常に困難です。 これは面倒で時間がかかるプロセスであり、数年かかることがあります。
スクラムだけでは強力な革新ではありません。 彼は幸運だった。 極端なプログラミングにはほぼ同じ内容が含まれていますが、そのような人気はありません。 スクラムは商業化され、マーケティングを通じてアジャイルの世界でナンバーワンの方法論になりました。 それにもかかわらず、それは独自のプロセスの開発と構築のための良い基盤として機能します。 ファイルを少し改良して（ただし、チューニングを行う）、スクラムを適切な開発プロセスに変えることができます。