ソフトウェアソリューションを設計するときにビジネスプロセスを描くことは理にかなっていますか
ソフトウェアの設計に取り組んでいます。再び一から開発した作品です。私のマネージャーは私にビジネスプロセスを描くように言っています。私はこの作品をすでに知っており、設計とプロトタイプの開発をすぐに始めることができるという事実のため、これには疑問があります。ソフトウェアを設計するとき、ビジネスプロセスは良い出発点と思いますか？これは、関係者に提示できるものです。彼らはお金を投資するので、おそらくこの方法で彼らは私たちがしていることを理解できます。彼らはビジネスプロセスの全体像を理解しています。
私の懐疑論は以下の理由によるものです：
- 私はすでにプロセスを知っているので、それらを描く必要はありません。他の参加者がそれらを知らない可能性があることに同意します。
- 最初のソフトウェアが作成され、次のプロセスがドキュメンテーションの一部として描画されるので、私には遅すぎるようです。
- プロセスはデザインを提示する不完全な方法です。さらに、データ構造、ロジック、ユーザーインターフェイスについて説明する必要があります。サードパーティシステムとのインターフェースなど.
プロセスを引き出すことで、お客様の代表者に計画を提示する可能性があることに同意します。これらのプロセスはカバーするものであり、カバーしないものであると言って、スコープを決定することもできます。プロダクトオーナーと相談することもできます。
コードベースのデザインについて聞いた。それについて何か教えてもらえますか？コメントで推奨されている「ソフトウェア設計の代替方法」に関する文を削除しました。
私が好む方法は、アジャイルチームが編成されるときに、段階的にプロトタイピングを行うことです。計画されたソリューションについてのアジャイルチームでの議論が大好きです。残念ながら、すべてのチームメンバーが平等に関与しているわけではありません。
私はこの作品をすでに知っており、設計とプロトタイプの開発をすぐに始めることができるという事実のため、これには疑問があります。
ソフトウェアを設計するとき、ビジネスプロセスは良い出発点と見なしますか？これは、関係者に提示できるものです。
そのため、プロセスを完全に理解し、コードを書き始めることができます。
よかったね。
あなたはこの仕事をするためにあなたにお金を払っている利害関係者のそれと一致する理解を理解していますか？どうやって知っているこれ？
同意済み彼らとのプロセスはありますか？
どのようにすればいいですかbefore離れて、潜在的に間違ったものを書き、彼らの時間とお金を浪費していますか？
多くの場合、知っている別の形式に「翻訳」すると、それを別の方法で考えるようになり、いくつかの奇妙な点やEdgeケースが木工品から飛び出し始めます。
一部の開発プロジェクトでは、ビジネスプロセスの描画は、コミュニケーションやドキュメント化、要件の収集または検証、システムの構造の設計、および場合によっては単にマーケティング目的のために役立つツールです。他のプロジェクトの場合、これは必要ないか、意味がありません。一部のプロジェクトでは、グラフィカルまたは文書化された他の形式のドキュメントが ビジネスプロセスモデル よりも役立つ場合があります。
これは依存します
開発するシステムの種類とサイズについて
システムがサポートするビジネスプロセスの種類
関係者、彼らの知識の異なるレベル、そして彼らの好ましいコミュニケーションと文書化の方法
プロジェクトの時点、およびその特定の時点でのコミュニケーションまたは文書化に必要な抽象化のレベル
質問には、特定のケースで何が意味があるかを説明するのに十分な情報がありません。しかし、あなた（またはあなたのチーム）が適切なソフトウェアを開発するのに十分なビジネスプロセスを知っていると思うという事実から、すべての利害関係者がすぐに同じと確信しているという結論には至りません。そのため、何をしているのかを知っていることを何らかの形で示す必要があるかもしれません。 方法これを決定するのは、あなた、あなたの組織、そしてあなたの利害関係者の考え次第です。
ビジネスプロセスに大きな影響を与えるソフトウェアの課題
既存のビジネスプロセスに影響を与える新しいソフトウェアをゼロから開発する場合、いくつかの課題があります。
- ソフトウェアとサポートされるビジネスプロセスは相互に依存しています。期待されるメリットを享受するには、それらを一緒に設計して進化させる必要があります。これらのアクティビティの順序付け（最初のビジネスプロセス分析、次にソフトウェア、またはその逆）は、多くの場合現実的ではないか、最適ではないソリューションをもたらします。
- 複雑なビジネスプロセスの再設計は 「組織開発」の一種 であり、関係するすべての利害関係者のコラボレーションが必要です。マネージャーはすべての詳細を認識していません）。
- ソフトウェアとプロセス開発の同期を保つには、ある種のプロセスモデリングが必要です。これにより、一見独立したユーザーストーリー間のリンクが作成されます。ユーザーストーリーのみに基づいてプロセスを開発することは、同じ方向で掘削が行われていることを確認せずに、両端でトンネルの掘削を始めるようなものです。
注：新しいソフトウェアがプロセスフローを根本的に変更しない場合、またはプロセスが単純な場合、プロセスの描画はソフトウェア設計に価値を追加しない可能性があります。
プロセスモデリングのリスクと落とし穴
ビジネスプロセスモデリング ソフトウェア開発のコンテキストでは、次のリスクに直面します。
- 既存のビジネスプロセスから始めると、古い世界を最初に描くという不便さがあります。これは、新しいシステムがもたらす可能性のあるイノベーションと機会に焦点を当てるのではなく、レガシー状況の方向にバイアスを生み出す傾向があります。
- 多くのユーザーはソフトウェアを使用せずに将来のプロセスを想像することが困難であり、ソフトウェアの専門家はすべてのニーズと必要な相互作用を予測するために既存のプロセスを十分に理解していない可能性があるため、将来のプロセスから始めることはしばしば機会を逃します。
したがって、プロセス「描画」が必要であるという点で、マネージャーは正しいです。あなたはそのような図面が不完全であり、十分ではないという点で正しいです。
提案された統合（アジャイル）アプローチ
幸い、両方のアプローチをアジャイルな方法で組み合わせることができます。
- ユーザーストーリーに相当するものから始めますが、エンドツーエンドのビジネスプロセス向けです。
- 最初の開発イテレーションは、プロセス開発イテレーションになります。それはあなたのプロセスとソフトウェアが使用されるプロセスステップの簡略化された高レベルのマップを提供します。ユーザーストーリーではUIの詳細を回避する必要があるため、この最初の「プロセスストーリー」の反復では、操作およびソフトウェアの詳細を回避してください。
- 潜在的な主要なプロセスのバリエーションと例外的な状況を特定するために、2回目のプロセス開発の反復が必要になる場合があります。
- それ以降、通常のユーザーストーリー主導のアプローチを使用してソフトウェア開発を開始します。ソフトウェアを開発するだけでなく、反復ごとにビジネスプロセスモデル（組織の「ソフトウェア」になります）を改良する必要があります（また、マイナーまたは無関係なプロセスの詳細でない場合にのみ改良します。DIN A3ダイアグラム。100の詳細なステップがあり、フォレストを非表示にするツリーと同じ数です）
通信機能と文書化機能の価値に加えて、私はそれを主要な時間節約とプロトタイピングのステップとして実行します。それはビジネスアナリストがやるべきことであり、なぜ多くの人が存在するのかです。
ref。 https://en.wikipedia.org/wiki/Business_process_modeling
他のチームとのコミュニケーションが現在のプロセスを文書化する大きな理由であることは正しいです。これにより、すべての利害関係者が、何が構築され、何が行われるかを理解しやすくなります。
現在のプロセスが実際に正しいことを検証することも非常に重要であるため、これをソフトウェアプロセスの一部として含めることは間違いなく理にかなっています。多くの場合、利害関係者はビジネスプロセスが引き出されているのを見ると、現実の世界で実際に必要なことと一致しない論理的な問題や事柄を見つけます。ユーザーがどのように作業する必要があるかをユーザーが最もよく知っていることを思い出してください。ユーザーとのコミュニケーションは、ソフトウェアを構築する上で重要な部分です。プロトタイプが動作する前に、フローダイアグラムはアプリケーションのロジックに関するフィードバックを得るのに非常に役立ちます。
ただし、通常、製品の所有者が承認基準/要件が形成されているときにこれらの議論を推進することを期待しますが、少なくとも、ビジネスフローがあなたの理解にとって正しいことを検証するための入力が必要です。
あなたはビジネスプロセスを知っています（またはあなたは言う）が、私は知りません。ビジネスプロセスを描くことで、何らかの理由でできない場合でも、私が仕事を続けることができることを確認できます。ビジネスプロセスを実際に使用している人は、図面を使用して、プロセスの理解が実際に正しいことを確認できます。
アジャイル開発についてあなたが言うことは、最も誤解を招くものです。すべての開発はあなたの目標を決定することから始まります。実際に欲しいもの-あなたの場合、より効率的な方法でビジネスプロセスを実装します。ビジネスプロセスを知るために必要なもの。 A 仕様は次のステップです後それ：あなたはソフトウェアがその目標を達成するために何をすべきかを指定します。ここから、アジャイル開発では、開始時に完全な仕様は必要ないことがわかります。それでも、すべてのタスクには仕様が必要なので、開発者がタスクが終了したと言ったら、そのタスクの仕様を取得して、実際に終了しているかどうかを判断できます。