コミュニケーション中、誰もがすべてを独自の方法で理解し、言われたこととは異なる解釈をします。 顧客は頭の中に言葉や写真に変換しようとしている特定の画像を保持し、開発者はこれらの言葉を聞いて頭の中のある種の画像に変換します。 そして、このチェーンには多くのリンクがあります。
この問題を解決しようとして、人々は詳細なToRを書きます。 しかし、これは問題を解決しますか？ 私が見るように、同じ質問は、2001年2月にアジャイルマニフェストを書いたときに、同僚と一緒にボブ・マーティンとマーティン・ファウラーによって尋ねられました。 この問題とアジャイルマニフェスト自体について一緒に理解してみましょう。
物語
2000年の冬、いわゆるエクストリームプログラミングのリーダーたちの会議があり、開発方法論について議論し、その結果、いくつかのライト方法論が提供され始めました。 興味のある人はほとんどいませんでした（私は誰かを怒らせたくありません）。 しかし、その会議の何人かの部外者は1年後に彼ら自身を組織しました。 それはすべて、Bob Martin（コードの品質に関する有名な本を書いた）が、前回の会議のリーダーにニュースレターを作成したという事実から始まりました。一緒に話してみましょう。 実際には具体的ではありません。 しばらくの間、彼らは場所と時間について口論した。 その結果、2001年2月11日にユタ州のスキーリゾートに集まりました。 Bob Martin、Martin Fowlerなど、開発業界の17人。 彼らは飲み、ファウラーはスキーに行き、議論の後、 アジャイルマニフェストが誕生しました。
原則として、最も重要なものはすべて、 ここで読むことができるテキストのページによって文字通り伝えることができます 。
しかし、短くて細心の注意を払って考え出されたすべてのものと同様に、単にそれを読むだけでこれを理解することは私にとって個人的には容易ではありませんでした。 したがって、アジャイルマニフェストに署名した人々が念頭に置いていたものを詳細に検討しましょう。
アジャイルの原則
つまり、正しいことの重要性を否定することなく、これは非常に重要な側面であり、マニフェストを読むとき、そして実際に毎日仕事をするときは常に留意する必要があります。 主なマニフェストステートメントについて説明しましょう。
まだ左側のものを重視しています。
人と相互作用はプロセスとツールよりも重要です
一見すると、これはすべてのJiraプロジェクト、バグトラッカー、タイムロガー、その他のツール、および構成されたすべてのプロセスを破棄するように思えます。 もっと簡単にできるのは、誰かが何をしているかを口頭で同僚と話し合うことです。 みんなが幸せだったら。 しかし、それは少しユートピアに見えますよね？
この原則は、何かの開発プロセスを構築するとき、それがなぜ、誰のために、どのような目的で行われるのかを覚えておくことが重要であることを示唆しています。 プロセス自体のためにプロセスを作成することはほとんど意味がありません。 仕事は最終的に人々、あなたと私によって行われるからです。 すべての火花、目への関心がすべて、ユトレックのタスクまたはjirのバグに置き換えられるとどうなりますか？ 顧客の前で完全な安全性を提供する適切に構造化されたプロセスには価値がありませんが、実際の開発タスクは解決しません。 官僚的な（正式な）詳細は、プロジェクトの人々の損失に容易につながります。 同じことが計画にも当てはまると思います。 最後に計画を立てたのはいつでしたか。最終的に少なくとも60〜70％が正確であることが判明しました。
私の意見では、マニフェストのこの原則は次のように聞こえます。
プロセスのための人ではなく、人のためのプロセスマニフェストは、この原則の実装に近づくことをどのように示唆していますか？
- やる気のある専門家はプロジェクトに取り組むべきです。
- 直接通信が最も実用的で効果的です。
- 最良の要件とアーキテクチャソリューションは、自己組織化チームからもたらされます。
- チームは常に作業を分析し、プロセスを最適化する必要があります。
チームは一般的に何を開発していますか？ 顧客向けの製品。
包括的なドキュメントよりも機能する製品の方が重要です
そのまま解釈すると、額に、多くの人が同意すると思います。 しかし、ここには他に何が見えますか？ 個人的には、完全に記述されたコードよりも機能し、 時間通りに機能する製品の方が重要であることがわかります。 これらは多くの点で残酷で恐ろしい言葉なので、私はそれを言ってはいけません。 しかし、私のキャリアを通して、さまざまな人々から学ぶことで、考えをますます確信しました。コードとアーキテクチャの点で理想的なプロジェクトと、内部はあまり美しくないが、世界に利益をもたらすプロジェクトとの間で選択する場合、私は2番目のものを選択します。 そして、はい、私は自分の能力と能力を最大限に向上させます。
そして、ここでちょっと考えてみてください。 しかし、これらの問題をより一般的にしないために何ができるでしょうか？ モジュールをリファクタリングするか、新しい機能を開発するかを選択する必要はありませんか？
- 動作中の製品はできるだけ頻繁にリリースする必要があります。
- 稼働中の製品は、進捗状況の重要な指標です。
- 技術的な卓越性と品質への継続的な注意がプロジェクトの柔軟性を高めます。
- シンプルさと最小化が必要です。
技術的な卓越性に関する点に注意してください。 コードを適切な（必要な）十分な品質で維持することで、要件の変更、したがってコードの変更を容認しやすくなります。
すべての原則は否定的ではありません。 一方は他方を除外しません。 これは優先順位付けに関するものです。 製品、コードの品質、ドキュメントなど、すべてが重要です。 しかし、何を選ぶべきか、いつ選ぶべきか？ 品質と製品の特定のバランスで作業することで、品質を否定することなく、製品を優先することが容易になります。
私の人生の例として、ロシアの顧客のための銀行プロジェクトの仕事を思い出します。 この作業は、アナリストの参加を得て、厳密に容積測定TKで実施されました。 半年に一度、マネージャーは顧客の本社に行き、作業の結果を示しました。 原則として、結果は顧客の期待とは大幅に異なっていたと推測するのは簡単です。 最初に新しいシステムを見て、一般的にそれが作成されていることを知った顧客の会計士は、恐怖の状態にありました-新しいシステムには彼の通常の作業プロセスのようなものはありませんでした。 次のトピックに進みます。
契約条件を交渉するよりも顧客とのコラボレーションが重要
このステートメントには非常に注意する必要があります。 そして再び、声明の右側が否定されていないことを忘れないでください。 それどころか、契約は重要だと言います。 契約と協力、適切な長期パートナーシップの条件を検討するとき、関係がより重要になります。 二番目を否定することなく。 私たちは現実の世界に住んでおり、時には非常に異なる顧客と仕事をしなければならないので、私はこれに注意を向けます。 顧客が自分の利己的な目的のために素朴さを利用し、契約を犠牲にして、開発者に受け入れられない条件を打ち破る場合があります。
それにもかかわらず、特定の抽象的な良い顧客について
プロジェクト全体で、期待を理解してコンプライアンスを達成する方法は？
- プロジェクト全体を通して、カスタムビジネスの開発者と代表者は毎日一緒に作業する必要があります。
- 直接通信が最も実用的で効果的です。
同時に、自分自身の安全のために合意を確認することを忘れてはなりません。 ちなみに（残念ながらめったにありませんが）、一般的に契約後に支払いを拒否する顧客がいます。
顧客が何であれ、開発者からのアクティビティは常に役立ちます。
また、これは両方の方法で機能するはずだと自分で付け加えます。
これにより、作業と計画の変更という論理的な継続が可能になります。 あなたがそれについて考えるならば、それは人間の性質にあります。 どのシステムも、平衡と不変性の特定のポイントを目指して努力しています。 しかし、常に動きと変化に関連するのは開発です。
変更への準備は 、元の計画に従うよりも重要です。
そのような計画の存在は否定されません。 それどころか、計画は重要です。 しかし、ある時点でこの計画が現在の環境では機能しなくなったことに気付いた場合、変更する準備をすることはさらに重要です。
私の同僚の実践の例は、CIS諸国の1つの税務調査プロジェクトです。 州のプロジェクト、本質的に、TK、法律では、アジャイルに関する話はありませんでした。 しかし、プロジェクトが計画された形式でまったく意味をなさないように、顧客の国の州が税法を変更した時点で、チームは柔軟でなければなりませんでした。 顧客が使用できるように、技術仕様を変更し、ほぼ完成したプロジェクトをやり直す必要がありました。 そうでなければ、おそらくそのような収益を除いて、仕事には意味がありません。
おそらく、これは最も明らかな例ではありません。変更は外部要因によって引き起こされたためです。 一方、顧客は、外部要因により、要件を変更する必要に迫られる可能性があります。 そうでなければ、彼は競争上の優位性を得られません。
これはすべて、私にとって少し苦痛なトピックに触れています。 しかし、私たちが1年間プロジェクトを行っていて、1年後に顧客が言ったらどうでしょう-さて、あなたは素晴らしいです、そして今、私たちはこれをすべてアーカイブに入れます、それを使用せず、新しいプロジェクトを開始します。 私はこれにかなり苦しんでおり、同様の経験をしました。 しかし、本当に-何が起こったのですか？ 行われた作業は、選択されたパスが正しくないことを顧客が理解するのに役立ちました。 または効果がありません。 競争上の優位性を得るには、別の仕事をし、別のプロジェクトを行う必要があります。 そして彼は私たちの助けを借りてこの知識を受け取りました。
私たちの仕事のどの側面がこれらのコーナーを滑らかにし、柔軟性を恐ろしくないものにしますか？
- 定期的および早期のソフトウェア配信。
- 後の段階でも変更を歓迎します。
- 変更は、顧客に競争力を提供するのに役立ちます。
同時に、私たちは現実の世界に住んでいます。現実の人々は、これを含めて絶対的な判断を下すべきではありません。 はい、変更が最終製品に付加価値をもたらす場合は歓迎します。 しかし、バランスを保つことが重要です。 無限に変更を加えた場合、製品を本番環境でリリースすることはありません。 したがって、ある時点で言う必要があります-停止し、製品をリリースし、実際にすべてを確認し、これらの変更を含むバージョン2の作成を開始します。 顧客と明確になるたびに-これまたはその変化で彼が見る価値。
私は最近Facebookでこのフレーズを読みました。
あなたの製品を恥じていないなら、あなたは遅すぎて市場に参入した上記の本質をかなり正確に反映しています。 製品が変更に関して次のリリースに十分対応できるようになり、まだマイナーな変更にあまり多くの労力を費やしていないバランスの特定のポイントを探す必要があります。
まとめる代わりに
アジャイルマニフェストの作成者はルールを規定していません。逆もまた同様です。 しかし、彼らは私たちの仕事に重要な問題を引き起こします-人、開発者、顧客の相互作用、変化への準備。 これらの原則は本質的に重要です。 文書化、契約、プロセスおよび計画、人間の相互作用、価値ある変更への準備、そして世界に役立つものをもたらすことは否定できないほど重要です。