どのようにしてマネージャにアジャイルを理解させますか？
反復的な開発を理解していない（はるかにアジャイルではない）シニアディレクターに問題があります。彼は、コード行が記述される前に、ソフトウェア設計仕様（SDS）が完成していることを強く主張しています。彼にとって、完全とは、すべての機能の詳細がそこにあることを意味します。また、元Cobolプログラマーである彼は、「モジュール」とフローチャートを見たいと思っています。これはJava大声で叫ぶためのWebアプリです！
とにかく、コーディングを開始する前にSDSが100％完全である必要はないことを示すために、彼を優しく指す簡単な場所を見つけようとしています（完全ではありません）。助言がありますか？
ありがとう！
コンサルタントとして、私はコンサルティングの1つの簡単なルールを理解しています。
- 助けられたくない人を助けることはできません。
あなたが持っていない権威の力を除いて、だれにもやりたくないことをさせることはできません。
コーチとして、私は3つのルールでアジャイルを紹介します。
プロジェクトの開始時にすべての要件を収集することは不可能です。
do収集する要件が何であれ、変更されることが保証されています。
時間とお金が許す以上のことをすることが常にあります。
そして一つの目標：
- 価値のあるものを毎週お届けします。
始めるのに必要なのはそれだけです。
上司を説得することは別のことです。
マネージャーにアジャイルを「理解させる」ことは、開発者に理解させることとは異なる方法で行うことはできません。あなたは彼に議論を提示し（ケントベックの本は良いスタートです）、彼に彼自身の決心をさせる必要があります。
または、実験を実行するように依頼することもできます。小さなプロジェクトを取り、反復型開発で実行し、時間、予算、品質の問題、およびチームの満足度を注意深く監視します。以前のプロジェクト（またはリリース）と比較して、それが良かったか、悪かったか、中立かを確認してください。
あなたはしません
まず第一に、なぜシニアディレクターがソフトウェア開発方法論の選択にさえ関与しているのですか？その決定は彼の給与等級をはるかに下回っており、ミクロな管理のスマックであり、不信のボリュームを語っています。
第二に、なぜ彼はそれをまったく理解する必要があるのですか？ソフトウェアの仕様が固定されている場合、正確に1回の反復が行われます。そうでない場合、複数の反復が行われます。 これは彼の決定ではありません。
彼が自分の決定だと思う場合、彼はITマネージャー、プロジェクトマネージャー、ITアーキテクト、チームリーダー、および開発チームの権限を弱体化させています。したがって、彼は@＃$％ingソフトウェアを自分で作成するか、STFUを作成して、専門家に恐竜の頭脳に邪魔されることなく仕事をさせる必要があります。
私は冗談で言っているのではない。彼があなたを信頼してあなたの仕事をすることができないなら、彼はそれを自分でしなければならず、あなたは悲鳴を上げるをすべきです。
「ソフトウェアの作成は映画の作成に似ています。事前に計画を立てる必要がありますが、良い結果を得るには、撮影中に再撮影を行い、古いシーンを再訪し、最終製品を編集する必要があります。」
それからまた、彼はマネージャーなので、彼の言葉では：
「相乗効果のある柔軟性を活用して、ジャストインタイムのフルサービスソリューションを生成する必要があります」
単純な場所は アジャイルソフトウェア開発のマニフェスト かもしれません。
この場所で見つけた情報は、著名な専門家のグループによって定義されたアジャイルソフトウェア開発のコアプリンシパルについてです。
あれは
- プロセスとツールを介した個人と相互作用
- 包括的なドキュメントに対応した実用的なソフトウェア
- 契約交渉をめぐる顧客コラボレーション
- 計画に従った変更への対応
しかし、完全な意図を得るために詳細にページを見てください。
古いことわざが当てはまります：馬を水に連れて行くことはできますが、飲むことはできません。
他の人が指摘しているように、このシニアディレクターにとって本当に重要なのはビジネス価値です。彼のフローチャートとモジュール図を作成し、「完全な」SDSを作成するために費やす時間の簡単な見積もりを提供することを試みることができます（ばかげた概念ですが、彼が望むものを与えてください）。私がこれらのことについて何か知っているなら（そして私がソフトウェアを書き始めたとき、それはそれが行われた方法でした）、あなたの見積もりは簡単に数週間になるでしょう。その数字をお金で表現してください。
次に、同時に提供できる機能の量を彼に示します。ビジネスで数人と話し合って、基本的なWebアプリで同じ時間に提供できるものを実行することで、どれだけの時間を節約できるかについて話し合ってください。次に、この節約額に、たとえば3年以内にこの機能を使用する頻度を掛けます。それをお金で表現しなさい。
おそらくお金で表現できる他のビジネス上の利点があります。私のお気に入りは常に「グーフボール」防止です。ソフトウェアが災害を最小限に抑えるか、完全に回避するのに役立つ場合は、最近の災害を見つけて、それを金銭的に表現します。次に、上司に言います。これが今あれば、このお金を節約できたでしょう。
そして、お金のトリックがうまくいかない場合は、おそらく彼に近づいて、彼のチームのマイクロ管理をやめるように言うべきでしょう。私の経験では、何よりも解雇される可能性が高いですが。
「ラピッドプロトタイピング」（別名、最初の数回の反復のコーディングを開始）を実行することで、SDSをより迅速かつ正確に肉付けし（後でやり直しを減らすことを意味します）、より早くビジネス価値を提供し始めることができることを彼に示すことをお勧めします。本当に、おそらくビジネス価値はこのディレクターにとって重要なすべてであり、彼はそれを達成するための最良の方法はこの一連のプロセスを通してであると決定しました。あなたは彼の言葉であなたのアプローチがより良い理由を示す必要があります。