金メッキソフトウェア
ソフトウェアの説明として金メッキが使用されたのを初めて目にしたのは、Barry Boehmによる次の根本的な原因のある論文でした。
金メッキ。設計に先立つ固定要件仕様は、ソフトウェアの金メッキを促進する傾向がありました。「この機能が必要かどうかはわかりませんが、万が一に備えて指定することをお勧めします。」
彼の説明では、彼の研究で説明されている方法を使用することをお勧めします。これには、プロジェクトがサイクルごとに一連のプロトタイプを生成するようにスコープされたスパイラルソフトウェアライフサイクルモデルが含まれ、スパイラルが大きくなるにつれて、フル機能の製品が提供されます。スパイラルはソフトウェア研究者の間で広範囲に影響を及ぼしており、ウォーターフォールとアジャイルの間の重要な架け橋でした。スパイラルの重大な制限は、スパイラルを回るたびにサイクルが長くなり、コストが高くなることです。
アジャイルと同様に、スパイラルは、より狭い範囲をスコーピングし、チームが要件を完了するのに十分な長さでプロジェクトの成果物をスケジュールすると同時に、初日から納品日までの目標に焦点を当てることができるほど短くすることで、金メッキを回避しようとします。スクラムのようなアジャイルメソッドが優れている1つの方法は、反復で長くならない時間枠でスクラムをスプリントすることです。この論文から、プロジェクト管理は、個々の開発者よりも金メッキに大きな影響を与えているようです。
タイムボクシングの才能
タイムボックスを設定できることは非常に重要ですが、バイナリスキルではありません。あなたはそれを持っていないか、それを欠いています。あなたはそれで良くも悪くもなります。それがあなたの上司から来たのかあなたから来たのかにかかわらず、金メッキを止めることができないと誰も言わなかったら私は好むでしょう。それは個人的で、広範かつ永続的に聞こえます。
根本原因分析は、いくつかの問題の特定に役立つ場合があります。彼らがすべてあなたを指しているわけではないこと、そしてあなたがサイコパスと協力しない限り、あなたのチームの他の人々が彼らのアジャイルスキルセットを改善するための同様のニーズを見ると確信しています。問題なく誰かを知っている場合、あなたはそれらをあまりよく知りません。改善する必要がないと思う人を知っている場合、その人はあまりよく知りません。
あなたが特定した改善が、あなた自身の認識とチームからの助けで解決できるものになることを願っています。しかし、それがここで終わるわけではないと思います。あなたのレビューを書いているスーパーバイザーまたはマネージャーからの私の期待は、彼らが成功するために彼らの部下もコーチできることです。これは、組織が計画からアジャイル（またはアドホックからアジャイル）への切り替えなどの革命的な変化を経験している場合に特に重要です。
迅速で汚れた、またはリスク管理されたプロトタイプ？
私は、特定の方法でタスクを実行するように要求していたマネージャーがいました。
早くて汚いが、美しさのもの。
彼はこれの愚かさを知っていました、そしてそれは彼のひどいユーモアのセンスの一部でした。多くの人々はこのようなことを言い、彼らは真剣に死んでいます。どこかに、改善された技術またはアプローチで問題を緩和する妥協または機会があります。
タイムボックスに合わせて何を犠牲にすることができますか？
Extreme Programming Explainedの第2版の第1章では、Kent Beckが高速移動に必要なことについて説明しています。彼の答えは、「顧客に価値をもたらすために必要なことだけを行う」というものです。
リスク
同じ本の第1版では、ベックは、リスクの管理に関するBoehmの見解を、彼の方法論にとって重要であると少しだけ詳しく述べています。
「リスクはソフトウェア開発の基本的な問題です」
どちらのエディションでも、ベックは8つの一般的なリスクをリストして説明し、その後にXP（または拡張機能によってはアジャイル）がそれぞれ特定の方法で対処するという主張が続きます。私にとって、彼の説明の大部分は小さな増分の使用に要約されており、より高速な反復により、リスクが大きくなりすぎて処理できない前に物事をコースに戻すことができます。
充足の精神
ベックは、山の人々と森の人々についての物語の文脈でリソースについて議論し、「十分な精神」と呼ばれる概念を紹介します。あなたの状況に照らして、彼は「十分な時間があるならどうしますか？」と尋ねます。本のプレビューとして利用できるこの最初の章だけでも、XP（および他のアジャイル手法）が時間のような制約をどのように考えるかについて考えるための多くの食物を提供するかもしれません。
強迫は症状であり、病気ではない
何年も前、私は先延ばしについての本を見て、多くの先延ばしは恐怖に起因すると述べました。あなたが始めなければ、あなたは間違いを犯さず、たぶんあなたは批判されないでしょう。強制と完全主義は、私たちの道徳的な感覚が先延ばしよりも優れていると言うものを与えますが、おそらく同じ結果になります。おそらく、あなたは別の形で先延ばしに問題を抱えていると思いますか？
批判と競争
スクラムのようなアジャイル手法では、先延ばしにされて批判または処罰される機会はこれまでになく高くなっています。それは悪循環です。私は先延ばしにされているので、私は批判されているので先延ばししています。毎日のスクラム会議では、達成したことをチームに報告するのが常に1日以内なので、常に注意を払っています。
理想的なチームでは、スクラムは先延ばしを修正する毎日の機会を提供します。間違いは、助けが届く前に大きくなる時間がないはずです。チームは常に信頼できる場所であるとは限らないため、チーム内のリーダーは、物事を前進させるために、批判または批判に対する恐怖に積極的に取り組む必要があります。
私たちの仕事の世界では、チームの各人は他の人とも競争しなければなりません。チームが仕事と栄光を達成のために共有することを信じるのは少し統合失調症ですが、その後、メンバーの20％に報いる、メンバーの10％以上を罰する、または追放する年次パフォーマンス管理プロセスを使用し、 70％の過半数がインセンティブなしで最善を尽くすように見せかけます。これはチームワークを促進するWRTの大きな象であり、Kent Beckの物語を参照すると、山岳民族であることと深い文化的つながりを示していると思います。
今後の方法
アジャイルチームの一員として、何が効果的かを研究し、他の人と対話することは良いことです。チームがツールを使用してユニットテストを自動化するためにTDDを使用している場合は、最善を尽くす人に指導してください。上司やマネージャーがドキュメンテーションのアプローチに問題がある場合、彼が好きなことや誰が好きなようにやっているのかを見つけ、彼らのアプローチに従ってください。それが生のコーディング速度に煮詰めるなら、より速くコーディングするために何が必要か調査してください。
リーダーは、他の人ではなく自分の問題について率直に語り、チームをアジャイルマリンスタイルに移行する方法について対話する（つまり、人がいない）ことで、自分の問題を率直に話すなどの望ましい行動をロールモデリングすることにより、正しい方向に一歩を踏み出すことができます残された）。チームの全員が同じ能力を持っているわけではありません。チームメンバーのペアリングを検討したり、関係する人々の補完的な強みを強調できるタスクや役割を割り当てたりすることが適切な場合があります。スキルの成長または改善の計画は、監督者と部下の両方にとって仕事のやりがいのある部分である必要がありますが、効果的であるためには早めに、そして頻繁に行わなければなりません。