アジャイルの神話と伝説-ファラオから現代まで

「すべてが毒であり、すべてが薬です。 どちらも線量によって決まります。」

パラケルスス






かなり奇妙な文書が生まれた2001年2月からアジャイルの歴史を数えるのが慣習です- アジャイル宣言 。 概して、文書のテキストは、哲学的証拠(たとえば、「単純さ-あまり多くの作業を行わないことの芸術」)および論争の声明(たとえば、「最高の技術要件、設計、およびアーキテクチャは、自己組織化されたチームから得られます」)で構成されています。 しかし、このドキュメントの内容はそれほど奇妙ではありません(スキーリゾートで何が思い浮かぶかはわかりません)が、ソフトウェア開発業界におけるその後の変化の壮大な性質においてです。 最短時間で、「柔軟な」開発方法論を実装する多くの技術が登場しました。これは、請負業者と顧客の財布の心を捉えて厳soleに行進します。 熟練者は、この動きを、すべてを決定する一種の魔法の薬として提示します。 誠実なプログラマーである高貴なドナー が、方法論の伝統的な方向性に従ってソフトウェア開発への関与を認めようとしないようになったのです。 スクラムをアジャイルの最も一般的な兆候として使用して、現象の原因と影響を理解してみましょう。



最初に、一般的にアジャイルラッパー、特にスクラムで得られた本当に新しいものを理解してみましょう。



古代エジプトのスクラム







一般的には柔軟な方法論、特にスクラム方法論は常に存在していたが、決して呼び出されなかったと主張する自由を取ります。 彼らはまったく呼ばれませんでしたが、単に内部プロジェクトを実施するための最も自然で効果的な方法でした(ここでのキーワードは「内部」です)。



たとえば、古代エジプトのファラオはピラミッドを建設することを計画していました...そしてそれは始まりました。 司祭(利害関係者)とアイデアを話し合い、彼の執事にプロジェクトの責任者(製品所有者)を割り当てました。 店員は有能な石工(スクラムマスター)を見つけました。 煉瓦職人はアシスタント(スクラムチーム)を雇い、奴隷市場に行き、奴隷(作業ツール:PC、サーバー、開発用ソフトウェアなど)を獲得しました。



ファラオは建設の進捗状況について彼に月次報告を命じたので、メイソン(アシスタント付き)は執事のために月次建設デモ(デモ)を実施し始めました。 ショーの間に、すでに行われた(回顧的)だけでなく、来月の計画(スプリント)も議論されました。 何も見逃さないようにするために、カップベアラーは一ヶ月をかけて司祭たちと話をし(ユーザーの話)、特別な羊皮紙(バックログ)に記録しました。そこからウィッシュリストは来月の計画に入りました。 まあなど。 ステッカー、スクラムボード、バーンダウン図がどのように見えたのかわかりません。 有能なリーダーは、プロジェクトの管理と監視に最も便利なツールを選択します。 ここでは詳細は重要ではありませんが、主なことはテクニックが機能することです。



つまり 私は、すべてのマネージャーが常に柔軟な方法論を使用して内部の(自分の危険とリスクで)製品を作成したと思います。





ただし、外部顧客の場合、このリストの項目はいずれも適用されないため、外部(カスタム)プロジェクトの場合、柔軟な手法は使用されていません(例外は規則を確認するだけです)。 結局のところ、人々は単純で不寛容であり、期限と見積りがひどく過剰だったため、頭を縮めたかもしれません。



最近のスクラム







現代のスクラムの唯一の目新しさは、外部(カスタム)プロジェクトの実装に使用されていることです。 文字列を引っ張ると市場参加者の本当の動機を引き出すことができるので、問題のこちら側を突き出さないようにしてください。 実際、アジャイルのマニフェストとスクラムのすべての議論は、すべての善とすべての悪に対する闘いの下に隠された、良識のために請負業者の利益の純粋なプロパガンダです。 これがソリューションの天才です。これにより、プロセスのために結果を犠牲にするように顧客を説得することができます。



では、製品所有者が自分の会社ではなく、別の会社の従業員である場合、何が変わりますか? 主な違いは、最終結果とそれを達成するプロセスが「バリケード」の異なる側面にあり、各当事者が商業的利益のみを追求していることです。 結果は顧客にとって重要であり、プロセスは請負業者にとって重要です。 それは他の方法ではあり得ない-結局のところ、「個人的なものは何もない、これは単なるビジネスである」。



アジャイルは、IT市場のプレーヤーに機会を提供するため、有益です。





そして、これは有益であるため、目の前に、高度な資格とシステム志向のプロのバックボーンを持つプログラミングチームが、中級者のレンタルエンコーダーの農場に変わることができます。



彼のアパートを修理するためにビルダーのチームを雇い、チームリーダーから修理の条件と費用を取得しようとする人の代わりに自分を置いてみてください。





誰もがそのような申し出に同意する可能性は低く、IT社員の顧客も同意します! それが生命を与えるプロパガンダのすることです!



顧客は予測不可能な期限と費用に同意することを確信しているだけでなく、失敗に対するすべての責任をそれに移します。 原則として、お客様の資格では、最終結果の要件を正式に定めたり、プロセスを専門的に管理することはできません。 したがって、多くの二次的な問題(長期計画の欠如が原因で最も頻繁に発生します)を解決するために、(一般的なTKがない場合)常に混乱し、気が散ることがあります。



アジャイル礼拝の結果







ソフトウェア製品の品質は、業界でのアジャイルの普及に比例して低下すると思いませんか? 問題を可能な限り簡単かつ迅速に解決することでプロセス全体が研ぎ澄まされた場合、品質はどこから来るのでしょうか? そして、方法論により先を考えることは公式に禁止されています!



同じソフトウェアの異なるセクションがまったく異なる人々によって作られているように見えることに驚いたとき、ソフトウェア製品はますます「パッチワークキルト」に変わっていると思いませんか? また、プログラムの1つの画面上で、異なるデザインスタイル、異なる人間工学的アプローチ、および同様のコントロールを機能させるための異なるアルゴリズムを混在させることができます。 しかし、この製品にはTKとスタイルガイドがありません。そのため、詳しい方はそうしてください。 また、QAスタッフは、他のすべての人と同様、スプリントの締め切りに縛られています。



これは何についてですか?



上記のすべてから、私は熱心なアジャイル嫌いだと思われるかもしれません。 しかし、これはまったくありません! そして、私は誰を怒らせようとしませんでした! 彼は、叙事詩に出された偉大なパラケルススの言葉をより明確に説明しようとしました。



柔軟な方法論は、内部の小規模および中規模のプロジェクトにも非常に適しています。 プロジェクトの規模は、「木の後ろの森を失わない」特定のリーダーの能力によってのみ制限されます。 「紙上」で体系化することなく、すべての詳細と望ましい結果の両方を念頭に置く能力。



柔軟な方法論は、外部プロジェクトに限定的に適しています。 この場合、顧客の製品所有者には、内部プロジェクトマネージャーと同じ要件が適用されます。つまり、この人は、パートタイムで一時的な負担をかける秘書ではなく、本当のITプロフェッショナルでなければなりません。 彼は雇用されたチームの資格を検証し、開発中の製品の品質を常に監視できる必要があります。 さらに、開発中の製品は、(不可抗力の場合)開発チームの交代を許可する必要があります。 この場合にのみ、「目的のない生活を送っている間、ins辱的で痛みを伴う」ことはないと予想できます。



おわかりのように、アジャイルは太陽の下でその場所を持っていますが、契約IT開発の分野では非常に限られています。 プロジェクトがアジャイルに適したカテゴリーに分類されない場合はどうしますか?



柔軟な方法論が契約ソフトウェア開発以外のどこにも根付いていないことを疑わないように思われませんか? まあ、彼らは潜水艦も、飛行機も、スクラムの車もしません。 私たちの祖先の知恵は、通常の犬小屋でさえ、設計段階(寸法付きの鉛筆スケッチ)とToR(材料とツールのリスト)の準備なしでは組み立てられないことを教えてくれます。 (スツールから宇宙船まで)周りに見えるものはすべて、古き良き「滝」に従って作成されました。 同じことをしてみませんか? そして、覚えておいてください-すべてがうまくいくでしょう!



PS



述べられていることはすべて、従来の(ウォーターフォール)アプローチとプログレッシブ(スクラム)アプローチの両方を使用した、契約Web開発における個人的な相当な(19年の)経験に基づいています。 記事を書いた動機は、ある尊敬される西洋の会社の偉大なフランケンシュタインの誓約の下で、次の「敵対技術の奇跡」を熟考することの道徳的苦痛でした。










All Articles