第34回GOSTを開発した人たちは、明らかに、物事がそのような方向に進むことを期待していませんでした。 また、柔軟な開発方法論に関する本も、これに対処する方法に関する推奨事項を提供していません。
そのとき、私たちにはあまり重要ではないと思われたすべてのものが、時間の経過とともに大規模に、深刻な問題の形になりました。
- このボリュームのドキュメントで、特定のシステム機能の操作を説明するドキュメントを見つける方法は？
- 見つかった20のドキュメントから、過去5年間にどのように機能が開発されたかを説明し、現在の構造をどのように理解していますか？
- 「作成、追加...」という要件のリストの背後にある組み込みビジネスロジックをどのように検討しますか？
パート1「TKの開発」
「顧客：皆さん、これはなんらかのゴミです。何も機能しません。
開発者：すべてがToRに従って行われます。
CISの参照条件は、要件の体系的なリストのように見えました。 フォームを開発し、そのような次元のフィールド、そのような次元、形成のロジックを作成します...実行する必要のあるチェックリストにすぐになり、実行したことをチェックする開発者向けの優れたドキュメント。
1つの問題がありました。CISの開発とロケットの構築を比較すると、そのように見え、必要な詳細を作成しましたが、それらは別々の場所で組み立てられたり取り付けられたりしませんでした。収集する必要があります。
このようなロケットを宇宙に発射しようとすると、CISで爆発します。
「顧客：皆さん、これはなんらかのゴミです。何も機能しません。 開発者：ToRによると、すべてが揃っています 。 」
KIS機能の範囲が広いほど、詳細にこだわるアナリストが多くなり、タスク全体のビジョンを失ってしまうことが多くなります。
結論：顧客は不満を抱いており、私たちは悪いアナリストだと信じています...そして彼は正しいです。
このドキュメントは開発者向けに書かれており、顧客はそれに署名します。 「追加するフィールドなど」に記載されているものはすべて彼に興味がありません。彼はこれを理解しておらず、理解してはいけません。彼はビジネス上の問題に対する実用的なITソリューションを得ることに興味があります。 顧客が作業明細書に署名するとき、彼は正確に後者を受け取ると信じています。
私は監督のところに来ました。アルカディ・ライキン
-誰がスーツを作ったの？ 誰がこれをしたの？ 私は何もしません、私は悲鳴を上げません、私はただ彼を目で見たいです。
それは百人になります。 私は言う：
-スーツを作った人？
彼らは言う：
-私たちは！
私は言う：
-この「私たち」は誰ですか？
彼らは言う：
-狭い専門分野があります。 1つはポケットを縫い、もう1つは小さなポケットを縫い、私は個人的にボタンを縫います。 ボタンに関する苦情はありますか？
-いや！ 死ぬほど縫って、それを裂かないでください！ 誰が衣装を作ったの？ ズボンの代わりに袖を縫ったのは誰ですか？ 袖の代わりに誰が私のズボンをぶら下げましたか？ 誰がこれをしたの？
彼らは言う：
-dの袖を縫わなかったことに感謝します。
想像できますか？ それらの百があり、私は一人です。 そして、誰もがボタンのように立ちます。死ぬまでです。 そして私は言った：
-こんにちは！ あなたは落ち着いています！
新しいTKテンプレートを2つの部分に分割しました。1つ目は顧客用、2つ目は開発者用です。
作業指示書の最初の部分は、ビジネスアナリストがインストールとともに顧客とともに作成したものであり、何も否定することはありません。 この空想飛行の出口で 、 CISを使用した顧客のビジネスオペレーションの理想的な説明と図示の実施形態。 ビジネスシナリオとシステムユースケースで構成されていました。
さらに、ビジネスの夢は、システムアナリスト、アーキテクト、チーフデベロッパーがおとぎ話を実現する方法を考えていたCIS機能の定住地にまで及びました。 るつぼから、ToRの2番目の部分が生まれ、ビジネスロジックをシステムの要件にたどりました。
2番目の部分が表示され、最初の部分で説明したようにすべてが機能することを「開発」によって確認した後、顧客は作業指示書の最初の部分とそれにのみ署名しました。
サンプルビジネスシナリオ
システムシナリオの例
そこで、 「要件のリストの背後にある組み込みビジネスロジックをどのように検討するか」という質問に答えました。
部品番号2「TKの修正」
「20のドキュメントの機能の概要を収集する（パズル18+）」
文書番号1（主な作業指示書）：フィールド番号1を作成します。
文書番号2（ToRの補足番号1）：フィールド番号2を作成します。
ドキュメントNo. 3（作業指示書の補足No. 2）：フィールドNo. 1を変更し、フィールドNo. 3を作成します。
ドキュメントNo. 4（RPの方向が変更されたため、新しいToRが作成されました）：フィールドNo. 2およびフィールドNo. 3に変更を加えます。
ドキュメントNo. 5（新しいToRの補足No. 1）：フィールドNo. 3およびNo. 1を変更し、フィールドNo. 4を作成します。
ドキュメントNo. 6（新しいRPはメインTKを見つけ、メインTKのサプリメントNo. 3）：フィールドNo. 2とフィールドNo. 4を変更します。
...
これが機能文書セットでした。 新しいTKテンプレートには、「歌の単語を書き換える」ことを選択したソリューションとして、前任者の運命を繰り返す機会がすべてありました。 新しい変更のたびに、メインTKが対応しました。
動機：常に1つの関連ドキュメントがあります。
問題がありました。 顧客は、新しいフィールドが1つあるため、署名を付けるために文書全体を読み直す必要があることを悲しみ始めました。 平均して1つのTKが40ページであり、顧客が月に約10のドキュメント（工場/迅速な開発...）を受け取ったとします。
TORの修正が返され、主にTKを変更していること、または追加する新しいセクションを示しています。 顧客はTORへの追加を2〜3ページ承認し、それに基づいてメインTKが更新されました。 出力は、ITソリューションの現在のステータスを説明する同じ単一のドキュメントです。
追加でメインTKに変更を加える例
そこで、2つ目の質問「見つかった20のドキュメントのうち、過去5年間にどのように機能が開発されたかを説明し、現在その構造を理解していますか？」に答えました。
パート3「TKでのナビゲーション」
技術仕様をナビゲートするために、当初はTK用に部屋を予約し、履歴情報を示すように設計されたTKのレジストリを使用しました。
- 開発を発注する部門
- タスクを策定および設定したユニットの顧客
- 実装を担当した部門のプロジェクトマネージャー
- 開発者向けにToRを作成したシステムアナリスト請負業者
彼らは、会社の基本的なビジネスプロセス（狂信的でなく、大ストローク）を説明し、必要に応じて、プロセスを手順に細分化/粉砕しました。
各TKが示されました。
5.実行される作業はどのビジネスプロセス内であり、
6.どの手順を実装していますか？
ビジネスユニットの要求に応じて、自動化または改良するビジネスプロセスを決定した後、共通プールをソートし、それが新しい技術タスクか既存のタスクの追加か、既存のものとその動作方法を決定しました。
最後の質問に対する解決策は次のとおりです。「この大量のドキュメントで特定のシステム機能の動作を説明するものを見つける方法は？」
委託条件はどうあるべきですか？
常に最新のドキュメント。 ビジネスプロセスとその自動化がどのように機能するかを理解するには、それだけを読むだけで十分です。 必要なTKを見つけるために、CIS機能の名前、それが影響するビジネスプロセスおよび手順の形式のラベルがあります。
参照テンプレートの条件
あなたが持っているTK、あなたのために設定されているタスク、およびそれらに対処する方法を共有してください。
トピックに関する読み物
- TKの開発におけるユースケースの適用
- ユースケースとは何ですか、なぜ必要なのですか？
- アリスター・コックバーンの本「効果的なユースケースの作成」ロシア語
- サイトの参照条件
- サイトの参照条件。 練習する
- TKの例を含むNevlabsでのソフトウェア開発プロセスの説明（会社のWebサイトで入手可能）
UPD。
記事のコメントを読むことをお勧めします。 特にコメントスレッドhabrahabr.ru/post/312538/#comment_9897642
記事「TKの開発」の最初の部分（企業IPについて）は、よく公開されています。