上司が要件と全体的な設計に関する主要な決定を常に延期する場合はどうすればよいですか？
新しいプロジェクトを開始するとき、私の上司は常に決まった決定をすることを避けます。彼は通常言っています：わかりました、何かを書き始めて、できるだけ一般的になります。終了したら、継続方法を確認します。彼の主張は基本的にあなたが決して知らない「アジャイル開発」であるということです。
質問をできるだけ一般的にするために：上司が決定を下したくない場合はどうしますか？
それに固執して、数週間後に大量のリファクタリングと部分的な書き換えが行われる可能性のあるコードを記述しますか？または、上司が少なくともいくつかの決定を行うまで話し合いを続けますか？これは多かれ少なかれ私の現在の戦略です。それは物理法則のようなものなので、ある時点で何かを提供する必要があります。上司の上司が結果を見たいと思っているからか、何かがとんでもないことになっているからです。
また、上司がほぼすべてを批判していることもわかりました。彼自身に基づいた提案でさえ...
プロトタイプの作成
最初は何もしない画面の描画を開始するだけです（おそらく、それを行うのに十分ですか？）
部分的にゆっくりと機能させることができ、何をしようとしているのかが明確になったときに、最終的には不良コードの一部をリファクタリングできるはずです。
彼らが何かを見て、それが彼らが望んでいるものではないことに気付くまで、彼らが彼らが何を望んでいるのかわからないことは一般的な問題です。誰かがあなたに「フレームワーク」または彼があなたに言っているような「一般的な」何かを構築し始めてほしいと思っているとき、あなたがしようとするとあなたはただ問題を起こすだろうと私は見つけました。フレームワークはすでに作成されているので、それを行う必要はありません。
私があなたのメッセージから集めたいくつかの問題があります：0-プロジェクトを管理するのはあなたの仕事ではなく、エンドユーザーの要件を集めるのもあなたの仕事ではありません。 1-上司は正確な要件を知りません2-上司は要件についてエンドユーザーに話しません3-上司はアジャイルを本当に理解していない用語を投げています4-あなたは再取得するいくつかの解決策を考えています-何度か書いて、あなたはそれについて満足していません
1、2、3に関しては、あなたが年配の人でなければ、これについてはほとんど何もできません。ただし、次のことは可能です。
A-彼にプロジェクト計画をあなたと共有するように頼んでください。彼はそれを持っているかもしれませんし、タスクと締め切りを示すものを作るでしょう。これらの1つは、分析と要件の収集に関するものでなければなりません。それを示唆していない場合。
B-ソフトウェアプロジェクトの成功に対する要件の重要性に関するいくつかの参照を準備します
C-アジャイルとは何かの1ページを彼に準備します。
D-設計段階への典型的な入力のリストを彼に準備し、それぞれの価値を彼に納得させます。
E-ビジネスアナリストやデータモデラーをチームに追加することを提案します。そのような役割はエンドユーザーと一緒に座る必要があり、必要な情報または少なくともその大部分を取得します。
F-他の開発者がこの男とどのように協力したかをご覧ください。
＃4については、プロトタイピングアプローチまたはコードジェネレーターを使用して、彼、あなた、およびユーザーがアプリケーションの機能的な側面について理解を深めることを提案できます。ほとんどのツールは完全なGUIを生成しませんが、少なくとも必要な機能をキャプチャすることはできます。
すべての場合において、各反復を明確に文書化し、受け取った入力、実行した内容（詳細）、および結果が何であるかについて電子メールで送信するようにしてください。 （要件の欠如など）などの適切な原因に結果を関連付けるようにしてください。
残念ながら、アドバイスを受け入れない人もいます。だからあなたが彼とどのようにコミュニケーションするかに注意してください。
これはうまくいっていません！
幸運を。
以前はそのような上司がいました-実際、彼のモットーは「優柔不断が柔軟性の鍵である」であったと冗談を言っていました。
どのような開発作業を行っても、上司よりもクライアントの問題を解決するのほうがよいでしょう。クライアントが解決しようとしている問題が何であるかがわからない場合（これは仕様と同じではありません）、誰かが要件の収集を適切に行っていません。
いくつかのページレイアウトをスケッチするか、非/半機能のプロトタイプを作成します。しかし、何かをしなさい。フルクライアントソフトウェアを構築しているのかWebアプリを構築しているのかは投稿からは明らかではありませんが、後者の利点は、リリース（早期、リリース）が頻繁にできることです。必要最低限の作業から始め、そこから作業を進めます。不正スタートは、何らかの対話が流れ、いくつかの決定が下されても害はありません。
$ WORK（内部Webアプリ）に関しては、「私はあなたに何かをあげますので、あなたが何を望んでいるかを教えてくれます」と言っています。最初のドラフトを破棄する準備をしてください。ただし、実際にそうする必要がほとんどないことに驚かれるかもしれません。
アジャイルの本は、できる限り決定を延期することを提案していることを彼に指摘しますしかしそれ以上ではありません。すべての決定にはそれを下さなければならないポイントがあり、おそらくあなたは今そこにいるでしょう。
一方で、自分自身にも疑問を投げかけましょう。このアプリに使用する永続レイヤーを本当に決定する必要がありますか？または、CSVへの書き込みを開始して、後でその決定を行うのに十分なだけ抽象化しておくことはできますか？
独自の仕様書を作成し、レビューを行って説明し、彼が承認します。その後、あなたは上司になり、あなたの上司は技術的な問題よりも対人関係の管理の問題に移ります。
上司やクライアントとの「上向きの管理」の話し合いに参加し、いくつかの解決策を見つけ、チームが実装するのに最適なものを選び、他の問題の欠陥を見つけ、マネージャーを「管理」して「正しい」決定を下します。
そしてもちろん、それがすべて彼/彼女の考えであったと彼が考えていることを確認してください。 （特にそれがすべてうまくいかないとき！）
何かを設計して実装する必要があります。上司は決定を下さないので、自分で決定します。決定と仮定を実装する前に、それらを文書化するために少し余分な時間を取ってください。上司を含め、関係者に送ってください。うまくいけば、そのリストには上司よりも多くの情報が含まれています。上司があなたに進む準備ができていることを他の人が知っていることを知っているので、いくつかの決定をするように彼に少し圧力をかけるでしょう。書面で決定を下すと、特に他の人が同意しない決定を下す場合に、フィードバックがどれだけ早く返されるかに驚かれます。その間、別段の指示があるまで、あなたが下した決定を進めます。
上司が望まないことを実行するために時間を無駄にするのをやめた場合、上司はあなたがたどる道を知っていたので、あなたではなく上司にあります。
また、始めるのに苦労する人もいますが、何か具体的なものを見ると、頭がおかしくなります。上司はそのような人で、書面で何をしようとしているのかを伝えると、頭が良くなるかもしれません。
自分で決定を下し、コーディングを開始します。もちろん、柔軟な方法で開発することは役立ちます（まだ行っていない場合は、Robert C Martinのアジャイルパターン、原則、およびプラクティスを読んでください）。 あなたが思う必要なものを開発し、必要に応じて変更する必要があるかもしれません。多くの場合、クライアント/ボスは、彼らがそれを見るまで、または彼らが彼らが望まない何かを見るまで、彼らが何を望んでいるかを知りません。これはおそらくあなたが開発者の範囲外になるでしょうが、それは人生です。私と私の同僚が効果的にビジネス上の決定を下していることに気付くことがよくあります。時々これらは疑問視されず、私が下した決定は、純粋に他の誰も決定を下さないという理由で、ビジネスを推進し始めます。必ずすべての仮定と決定（例外なし）をリストし、それらを上司に提示してください。