心理療法では、患者と仕事をする次の方法があると聞いたことがあります-患者は座って、自由に「ストリーミング」することを提案されます。 これに関連して、優しく優しく愛singする言葉があります-フリーライティング。
だから、なぜ私がこれを書くことにしたのか-ソフトウェア設計自体を完全に無視し、少なくともいくつかの開発方法論の品質とコンプライアンスを無視することに直面したとき、あなたはいつも驚きます。 あなたがこれに何度も何度も出くわすとき、あなたはすでにそれについて書きたいです。
あなたが最初に考えること-エンジニアリングはすでに死んでいて、マーケティングが世界を支配しているかもしれません-それがどのように書かれ、設計されても、まったく設計されても、主なものは販売、投入、投入ですか？ しかし、エンジニアリング自体は背景に消えており、本当の「創造物」は、これらの素早さの若い人たち、営業マネージャー、ダックスフントのように卑劣で粘り強く、アナグマを穴から追い出しているのでしょうか？ この考え自体は野生の扇動ですが、何が起こっているのかを観察すると、何度も何度も思い浮かびます。
さて、実際に何が起こっているかについて詳しく説明します。 起こることは、エンジニアリングがビジネスの使用人であることが判明したということです。 企業の主要な販売製品/サービスがソフトウェア製品である場合でも、これは最も逆説的です。 ビジネスは独自のルール、ビジネスの制限、調整を指示し、品質とデザインを犠牲にして行動する意思がある技術的な「ケージ」の人々を支持します。 この場合、経営者は、雌犬に座ってゆっくりと雌犬を切り倒し、知識不足のために感じ、今日の利益を感じ、草が成長しなくても明日を感じる近くの人に似ています。
しかし、「国家管理の特徴」は、別の、大きくてかなり悲しい会話のトピックです...
一般的に、ビジネスは貪欲なモンスターに似ており、それ自体も食べる能力があります。
素晴らしいコンセプトは技術的な義務であり 、誰もがそれを知っており、誰もがそれを読んでいます。 しかし、私の主観的な意見でこの概念を考慮して実行されている実際のプロジェクトの数はごくわずかです。
理由は簡単です-ビジネスは技術的負債を好まない、それを嫌う、それについて話すことさえ嫌いです。
ビジネスはスクラムと恋に落ちました-しかし、非常に奇妙な愛で。 ほとんどの場合、スクラムは優れたジューサーです。 果物と野菜の役割は誰ですか？ もちろん、開発者。 さらに、スクラムは一種の「フィグリーフ」として使用され、多くの技術的な問題に対する受け入れがたいアプローチを覆います。 「より多くの機能をハングアップし、高速化する」という部分に関するすべては、スクラムから取られています。 まず、新しい機能の一部であり、その実装はすべての新しいスプリントにかかっています。 ただし、コードと製品全体の品質、変更に強く、テストが容易で保守可能な設計の達成と維持に関するすべての慣行は、ほとんどの場合、単に破棄されます。
ここで予約が必要です-すべての人とすべてを一般化するのではなく、今日客観的に存在する傾向について話しています。
次はQAです。 膨大な数のプロジェクトの品質保証と品質管理の概念は、アンドロメダ星雲のように、はるかに神秘的なものです。 そして、これはスクラムプラクティスの劣った使用から直接続きます。 ソフトウェアライフサイクルのプロセスの1つとしてプロジェクトに継続的なテストが実装されていない場合-手動でUIのバグを「クリック」しようとする人がいたとしても、そのようなテストは冒proとは言えません。 その結果、QAに対するそのような態度のためにリリースにひらめいたバグは、会社にそのような評判と金銭的損害を引き起こします。これと比較して、製品品質を扱う本当に効果的なプロセスを設定するコストはわずかに思えます。
しかし、再び-これらのメトリック、これらの計算、消費されたリソースのこれらの比率に関与している人...
ビジネスも文書化を嫌い、費やされるリソースは深刻で、その効果は明らかではありません。実際、傷跡の後ろに隠れることもできます。「傷跡があり、グループとの緊密なコミュニケーションが必要です。」
これは、グループの最高2〜3人がプロジェクトを完全に知っているという事実にもかかわらず、残りは広くおよび/または断片的にプロジェクトを知っているため、「秘密」の知識を持つ人々がゲームを離れると、すべてを書き直しやすくなり、これには、文書化のコストと比較できないコストが伴います。 さらに、コードリファクタリングまたはより深刻なリエンジニアリングのためにシステムを分析する機能。 さらに、たとえば、プロジェクトへの新しい人の参加。 文書化されたシステムを最初から使用し始めた場合、それがどれほど速く、効果的になるか。
また、プロジェクトにコードレビュー、SOLID原則に基づいて適切に実装されたモジュールアーキテクチャ、構造化、フォーマット、さまざまなレベルの変数の命名、クラス、メソッドがあればよいのです。これにより、ドキュメントの不足を大幅に補うことができます。状況はむしろ規則の例外です...
ソフトウェア開発業界のこれらすべてのネガティブな傾向をどのように治すのですか？
私が見るように、ここでの主な錠剤は教育です。
尊敬されている学術コミュニティが、「継母」数学の永遠の「継娘」ではなく、自給自足の工学分野としてのソフトウェア工学の実現に向けて成熟するのが早ければ早いほど、カリキュラムはより早く調整され、大学の教師として実際の開発からより多くの人々が来ることを願っています。
ソフトウェア開発分野の専門教育が提供すべき最も重要なことは、開発プロセスの3次元ビジョンです。人々がそのようなビジョンを持っている場合、おそらく正しくアクセントを付け、ビジネスの要件と活動を密接に調和させることができます。
ビジネスvsソフトウェアエンジニアリング
All Articles