プロジェクト管理手法（高レベル）
私たちのソフトウェア開発チームは現在、開発ライフサイクルにかんばんを使用しています。数か月というかなり短い経験から、かなりうまくいっていると思います（確かに、方法論がなかった数か月前と比較して）。
しかし、私たちのチームは、プロジェクトマネージャー（ソフトウェアプロジェクトマネージャーではなく、一般的なビジネスのみ）によって定義された作業を行うように指示されており、PMBOK方法論を使用しています。
問題は、PMBOK、Prince2などの従来の方法論が、かんばんやスクラムなどのリーンソフトウェア開発方法論にどのように適合するかということです。すべての要件が最初から効果的に作成されているため、すべての人の時間を無駄にしているだけですか（途中で必然的に変更されますが）？
私はこの分野の大規模な専門家ではありません。しかし、ここでは2つのことを試すことができると思います。
1かんばんボードを使用して、使用されているPMBOK/Prince2プロセスを視覚化します。プロジェクトマネージャーにこの「視覚化支援」を示すだけです。私にとって、それがかんばんの目的です。ボトルネックとブロッカーがどこにあるかを示します。通常のウォーターフォールスタイルの問題が発生したとすると、ワークフローがさまざまなポイントで遅くなったりブロックされたりするため、これをかんばんボードに表示できます。次に、これを出発点として使用して、プロジェクトをよりアジャイルな方法で実行できるようにすることに同意してもらうことができます。
および/または
2要件を取得し、とにかくかんばんスタイルのプロジェクトに分割しますが、Prince2/PMBOKの方法でプロジェクトマネージャーに進捗状況を報告する方法について、事前に分析/準備を行います（これは彼らにとって快適です）。レポートが彼らのニーズを満たしている限り、PMはプロジェクトの実行方法を気にしないことに気付くかもしれません。
他の回答者は、かんばんを使用して既存のプロセスを計画し、優れたビジュアルツールにすることができると正しく理解しました。しかし、それだけではありません。
すべての要件が事前にある場合でも、WIP（仕掛品）の制限は機能します。開始時にバックログに100個の機能がある場合でも、作業を5個（チームの容量に応じて）に制限して、それらの終了に集中できます。要件は必然的に変更されますが、変更はまだ開始していない機能には影響しません。リーン原則の1つは無駄を排除することであり、無駄の種類の1つは過剰在庫です。これが、無駄を減らす方法です。
かんばんは改善のためのエンジンです。かんばんを使い始めると、それは作業項目を要件から完了まで移動するための管理ツールにすぎない場合があります。しかし、時間が経つにつれて、ワークフローをより深く理解し、プロセスの改善を提案します。
元の投稿の3番目の段落の質問に答えるには、スクラムを採用することは、人々の役割とプロセスを変更することを意味します。あなたはすぐにあなたのプロジェクトマネージャーとの対立を生み出すでしょう。
カリアンナに投票するのに十分なポイントがありませんが、私は彼に同意します。開発者->ソフトウェアPM->プロジェクトマネージャーから移動しました。プロジェクトマネージャーは、ソフトウェアプロジェクトに関するPMP/Prince2レポートを実行することが期待されています。 Prince2/PMP構造内に収まるようにアジャイル/かんばんメソッドをマッピングするのはかなり簡単です。結局、人々がこれを望んでいる/必要としている唯一の理由は、進歩を見ることです！したがって、進捗状況/ボトルネックとリスクを視覚的に示すことができれば、他のことを主張するPMは見当たりません。
要件に関しては、ビジネス要件があまり詳細にならないようにする傾向があります。これにより、開発者自身が、それをより小さな詳細なタスクに分割する最善の方法を決定できます。可能です。PMと一緒に座って、彼/彼女の（報告）要件について話し合ってから、どのように彼/彼女にそれを提供できるかを確認する必要があります。