IT プロジェクトを正しく管理する: ローコードプロジェクトの 3 つのプロセスモデル

IT プロジェクトを開始する前に、いくつかの基本的な質問を自問する必要があります。

90 年代に開発されたスクラムプロセスモデルは依然として適切であり、今後の新世代のソフトウェア開発手法に十分な俊敏性を備えていますか?
アジリティを再考すべきでしょうか?そうであれば、どのようにすればよいでしょうか?浄化され活性化された滝のモデルを背景にしているでしょうか？
それとも、将来のプロジェクトはまったく異なる方向に進むべきでしょうか?

スクラムに従ったアジャイルソフトウェア開発が意味を持つのはいつですか?

スクラムの利点はよく知られています。技術仕様の策定から実装までの期間が数年から1～数か月に短縮されます。それだけでも、企業の各部門の IT サポートの自由度がさらに高まるという大きなメリットがあります。よく見てみると、スクラムによるアジャイルソフトウェア開発は、プロダクトオーナーによって制御される一連の小さなウォーターフォールモデルプロジェクトにすぎず、ソフトウェアの 1 つのレベルから別のレベルに移行します。実際には、厳密な意味でのアジャイル開発よりもアジャイルなプロジェクト管理です。

このモデルは、オンラインプラットフォームなど、独自のコアソフトウェアの独立した開発に最適に調整されています。最初は管理可能な最小限のソリューションでできるだけ早く生産性を高め、その後、利用可能なスタッフを使って月次ベースで徐々に拡張することが理想的です。スクラムは、一定のソフトウェアメンテナンス予算の枠組み内で完成したソフトウェアを継続的に開発するのにも非常に適しています。カスタマイズリクエストはバックログに収集され、優先度と実現可能性に基づいて優先順位が付けられ、進行中の開発に統合され、ソフトウェアの次のバージョンのいずれかに組み込まれます。

最新のDevOps組織と組み合わせることで、IT を大幅に高速化できます。また、これは、以前のバージョンの操作から得られた継続的な知識と非常によく一致しています。少なくともコストが影響しないのであれば、これは経営の観点からは正しい方法である可能性があり、工数を販売する IT サービスプロバイダーの観点からは確かに正しい方法です。労力に応じて報酬が支払われるスクラムプロジェクトは、リスクがなく計画が立てやすいため、請負業者にとって特に有利です。

改善されたウォーターフォールモデルはありますか?

ただし、複雑なソフトウェアソリューションの新規開発 (おそらくクライアントと請負業者の関係における固定価格プロジェクト) となると、状況は異なります。機能的ではあるものの、毎月まだ使用できない初歩的すぎるプログラムバージョンを必要とする人はいません。月次サイクルは、より大規模な作業パッケージを処理する際にも邪魔になります。

プロダクト所有者が専門部門、IT 部門、クライアント、請負業者のいずれの代表者であるべきかを明確に割り当てることはできず、どちらも現実の世界に完全に当てはまらないため、外部にアウトソーシングされたアジャイル開発プロジェクトの経験は非常に複雑です。必要なものを正確に知っていて、最適かつタイムリーな実装を望んでいる場合、ウォーターフォールモデルは実際には理想的です。過度の形式主義と不十分な話題性というよく知られた問題、そして何よりもサイレントポスト現象がなければ、ユーザーの要件に影響を与えるため、長い紙のルート上でグロテスクに歪められることがあり、開発が実際にニーズを無視することがあります。

読書のヒント: ソフトウェア開発の方法論 – アジャイルとウォーターフォール

問題は、「まず考えてから行動する」という賢明な基本アプローチを、ローコードソフトウェア開発のアジャイルの世界に移すことができるかどうか、そしてどのように移すかということです。行政の V-Modell-XT で規定されている反復プロトタイピングだけでは、これには明らかに十分ではありません。ウォーターフォールモデルを改善するには、ユーザーの要件をより直接的かつ迅速に、理想的には直接対話して開発者に伝えることが重要です。ただし、これは、プログラマーが登場するずっと前に予備的な構想段階を持つ古典的なプロジェクト開発の基本構造と矛盾します。要件を十分に詳細に書き留めるのに必要な労力は、高度に開発されたローコードプラットフォームで要件を実装するのに必要な労力よりもはるかに多くなる場合が多いため、これは明らかに非効率です。

通常のプロジェクトでは、画面に表示されて初めて具体的な要件が明らかになるため、事前の取り組みはメリットよりもむしろ障害となり、プロジェクトのコストも不必要に増加します。したがって、機敏である方がよいのですが、具体的にはどうすればよいのでしょうか?

基本原則としてのデザイン思考

ユーザーの目の前でコンピュータプログラムをリアルタイムで再構築したり、画面上でユーザーと一緒に再構築したりできるようになった場合、スクラムに典型的なアジャイルソフトウェア開発の毎月のリズムは明らかに遅すぎます。たとえば、最適な（つまり、ユーザーにとって賢明であると同時に技術的に実現可能な）ソリューションを共同で見つけるために、ユーザーと開発者の間で直接対話することは計画されていません。この意味で、スクラムは明らかに俊敏性が十分ではありません。

さらに、実際には、この全知全能のプロダクト所有者が存在するのかどうかという疑問が常に生じます。自分が何を必要としているのかを最もよく知っているのは、個々の専門ユーザーではないでしょうか?したがって、プロジェクトマネージャーは、自分自身を、結果として得られる製品の所有者であると考えるのではなく、限られた予算や限られた時間の制約など、与えられた条件下でも最適な結果を達成するために、ユーザーと開発者の間の調整者であると考える必要があります。

バックログよりもはるかに優れた媒体は、プロジェクトの初期段階だけでなく、プロジェクト期間全体にわたって定期的にデザイン思考ワークショップを開催することです。デザイン思考は、混合チームでの学際的なコラボレーション、オープン性と創造性、そして同時にツールへの依存度を大幅に下げることを意味します。デザイン思考のツールはコンピュータープログラムではなく、画面デザインをペイントしたり、プロセスをスケッチしたりできる紙と鉛筆、ホワイトボード、スタンディングテーブルです。そして、「これは本当に必要なものなのか？」という原則に基づいて、常にすべてを疑う寛容さ。ディスカッションの基礎として、参加者は常に現在の作業ステータスを画面上に表示します。つまり、スプリントや完成したモジュールはありませんが、進行中の作業ステータスが表示されます。未完成でテストもされていませんが、処理が現実的で、多かれ少なかれ実際のデータが含まれています。

プロジェクトを垂直方向ではなく水平方向にトリミングする

その一方で、スクラムは機敏すぎるため、間違った順序で物事を進めてしまう誘惑にさらされてしまいます。一般的なデータベースアプリケーションの場合、新しいユースケースがデータベースアプリケーションに影響を与える場合に、すでに完成したプログラム部分へのコストのかかる変更を避けるために、プロジェクトの初期段階で少なくともデータモデルの基本構造を結合的かつ最終的な方法で定義することが合理的です。データモデル。また、最初から古いデータを匿名で転送したり、現実的なテストデータを生成したりすることで、より現実的かつ負荷の高い開発を行うことができます。

さらに、ローコードの原則は、その驚異的な実装速度と 98% のアプローチにより、プログラムする必要がある可能性のあるものと、プログラムしないと実行されない「長時間実行されるタスク」をプロジェクトの開始時に特定して開始することを提案しています。開始が遅すぎると、終了日が危うくなる可能性があります。

最後に、特定のコンテンツと操作手順を開発する前に、ユーザー管理、レイアウト、UUX ガイドラインを含む完全なプログラムフレームワークを事前に開発してから、ユーザーとプログラムの詳細を掘り下げることができます。このようにして、後で説明する作業ステータスがより鮮明かつ現実的なものになり、後続のユーザーとの特に重要なクリエイティブなコラボレーションが大幅に簡素化されます。さらに、実際のコンテンツに関するより広範な作業を少し遅らせることができるため、計画が改善され、適時性が高まります。

読書のヒント:利害関係者の分析 – プロジェクトの参加者を特定する方法

フェーズアジャイルプロセスモデル

これにより、範囲と内容が明確に定義された秩序立ったプロジェクトフェーズでありながら、同時に個々のフェーズで可能な限り機敏な、ローコード開発に最適なプロセスモデルが実現します。これらのフェーズが正確にどのようなものであるかは、特定のフレームワーク条件、プロバイダーのビジネス領域、およびおそらく使用されるローコードプラットフォームの特定のプロパティによって異なる場合があります。 5 段階のフェーズモデルは、コストが重視され、期限に制約のあるプロジェクト環境におけるデータベースアプリケーションに最適であることが証明されています。個々のフェーズは次のように定義できます。

初期化
データベース
プログラムの枠組み
スペシャリストモジュール
ファイナライズ

5 つのフェーズのそれぞれに必要な時間はほぼ同じです。ただし、主な作業はフェーズ 4 にあり、複数のデザイン思考チームが同時に活動する場合があります。初期段階ではコンピュータサイエンティストの需要が高くなりますが、プロジェクトの後半では市民開発者、つまり少なくとも IT と同じくらい技術面に深く関与するプロジェクト参加者がより積極的になってきます。

アジャイル固定価格

強力な設計思考を備えたフェーズモデルは、おそらく、アジャイルな固定価格プロジェクトを可能にする最良の方法でもあります。ユーザーのアイデアの急増に対抗するには、専門ユーザーと開発者が協力して適切で手頃なソリューションを開発し、予算に優しい方法で交渉する必要があります。必要に応じて、双方のプロジェクトマネージャーは、プロジェクトの共同の成功によって評価されるため、妥協を奨励し、同僚を穏健にすることができます。必要に応じて、プラスマイナスリストも保存され、追加および削減された経費を相殺するために使用できます。

プロジェクトの成功には、デザイン思考ワークショップを厳密に計画し、プロジェクトマネージャーが今後の意思決定が実際に行われるように効果的に保証することが重要です。

「常に火曜日の原則」

ローコードプロジェクトの場合、プロジェクトの全期間を通じて、毎週のサイクルがデザイン思考ワークショップに最適であることが証明されています。この期間を過ぎると、ローコードプラットフォームの使用に携わる人々が十分な新しい事柄を議論に持ち出すことができるようになり、会議と実際の取り組みが合理的な比率になり、外部サービスプロバイダーの出張の負担が合理的に抑えられるようになります。プロジェクトの段階によっては、他の人が会議に参加する場合もありますが、それでも、毎週火曜日など、プロジェクトの開始時に請負業者とクライアントの間で曜日を固定することに同意することが合理的です。これにより、組織の労力が軽減され、関係者全員がより適切に計画を立てることができます。

瞬間的な開発方法論

クライアントにとって重要なのは、可能な限り最短の時間で可能な限り最高の結果をもたらすことだけである場合、ローコード製品の技術的に可能な柔軟性を限界まで押し上げることは理にかなっています。これは、プロジェクトの開始時にタスクがまだ明確でない場合に特に当てはまります。つまり、事前、プロジェクトの特定のフェーズ、またはバックログの進行中の更新中に、体系的な要件分析が不可能であることを意味します。

そして、開発はほとんどの場合、エンドユーザーの目の前で、ある程度オンデマンドで実行されます。これは、開発プロセスの大部分がユーザーの自発的なインスピレーションによって制御されることを意味します。試行錯誤によって必然的に発生する問題にテクノロジーが対処できれば、このプロセスにより、アプリケーションソフトウェアを実際に必要なものに徐々に適合させることができるという貴重な利点が得られます。ここでは、まずデータ構造とコンテンツについて考え、次にプロセスとプログラムインターフェイスについて考えるのが理にかなっています。

欠点は、瞬間的な開発手法を使用したプロジェクトは実際には計算できないため、固定予算で、あるいは固定価格のプロジェクトとして立ち上げることがほとんどできないことです。即座に行動するには経済的な柔軟性が必要です。全体的な費用対効果のバランスの観点から言えば、即時的なアプローチは確かに最も経済的な方法であり、双方のプロジェクトマネージャー間の良好な協力によって、各部門にとって最高の達成可能な結果をもたらすことができます。

ウォーターフォール、スクラム、それともフェーズアジャイル?

3 つの手続きモデルにはそれぞれそれぞれの正当性があり、どれが最も適しているかは特定のフレームワーク条件によって異なります。古典的なウォーターフォールモデルはそれ自体は優れており正しいものですが、ローコード開発には実際には遅すぎます。やや時代遅れのスクラムの概念と新しいフェーズアジャイルプロセスモデルは 2 つの賢明な代替案であり、より異なるアジャイルソフトウェア開発の 2 つのアプローチです。そんなはずはない。

スクラムは、ソフトウェア製品やオンライン製品の社内開発、および既存のソフトウェアの継続的な改善により適しているように見えますが、フェーズアジャイルのコンセプトは、予算と期限に制約のある新規開発や、アジャイルな固定価格プロジェクトを可能にします。特定のコンステレーション、特に比較的小規模なプロジェクトや比較的余裕のある予算で管理可能なサイズの分離されたモジュールやマイクロサービスの場合、さらに一歩進んで完全に瞬時に開発することが理にかなっています。これは最新の低コストシステムなしでは実現できないアプローチです。コード技術はほとんど不可能でしょう。 (bw)

IT プロジェクトを正しく管理する: ローコード プロジェクトの 3 つのプロセス モデル

スクラムに従ったアジャイル ソフトウェア開発が意味を持つのはいつですか?

改善されたウォーターフォール モデルはありますか?