多くのプログラマーは、すでに実行中のシステムでバグを見つけた場合、その責任は彼らにあることに同意するでしょう。 そして他に誰が？ 結局のところ、彼らは彼を許可しました！ その結果、モチベーションが低下し、イメージが悪化し、一般的に-最も働く人が最も多くのキックを得ます。 そして、マネージャー、セールス、その他の人たちに認められています...
約9か月前に、1つのプロジェクトにプロセスを導入するように依頼されました。 プロジェクトは組織にとって非常に大規模で戦略的です。システムは、国内のすべての学生のすべての推定値に従って計算を収集、処理、実行します。 毎年9月に運用サイクルが開始されますが、これは時計仕掛けのように機能し、エラーや遅延はありません。 1月以降、計画によりシステムの変更が開始され、その間、運用サイクルが継続されます。
私はプロセスの専門家ではないため、以下はすべて個人的な経験に基づいています。 ただし、システムがUATに入った欠陥の数は0であり、3年ぶりにUATがその時点で開始され、サインオフで合格しました。
ステップ1-問題はどこにありますか？
プロセス開発の最初のステップは、現在何が間違っているのか、それを回避する方法を確立することです。
この質問で、私はプログラマー、テスター、アナリスト、マネージャー
この段階の結論は、責任の正確な配分が必要であるという事実でした。 例：
-プログラマーがコードを実装するとき、彼はユニットテストと、実装が何も台無しにしないという事実に責任があります
-テスターがすべてが機能していると言うとき-この決定の責任はすでに彼にあります
-システムがUATに適していることをアナリストが確認した場合-アナリストは機能について責任を負います
等
ステップ2-プロセスを特定する
次に、説明するプロセスを特定しました。 システムはすでに開発されているため、「変更」（変更要求）およびバグ（欠陥）のプロセスが必要でした。
各プロセスには、初期条件（前提条件）、ステップ（手順）、および最終条件（事後条件）があります。 プロセスステップは、単純なステップ、分岐、または別のプロセスのいずれかです。 各プロセスとステップには、独自の入力と出力があります。
「変更」のプロセスでは、初期条件は「変更およびクライアントによるビジネス仕様の承認」でした。 これは、変更が必要であり、仕様がクライアントの要件に従っていることを保証します。 クライアントは、以前によくあったように、彼が要求したことをまったくしなかったとは言わないでしょう。 以下は、「変更」プロセスの完全な図と、その主なサブプロセスの説明です。
「変更」の最初のステップは仕様です。 変更を担当するプログラマーによって準備され、要件に対する彼の理解が正しいことを保証する必要があります。 アナリストが仕様を確認すると、直接開発を開始することは青信号です。 アナリストによると、仕様が不完全または正しくない場合、編集のためにプログラマに送信されます。 その結果、プログラマーがユーザーの要件を満たすというモチベーションと自信が高まります。 以前は要件が「明確」であることがよくありましたが、プログラマーは気づかないうちにアナリストやクライアントの期待を満たさない仮定を立てていました。 そして今、私たちは何をどのように行うかを知っています。
次のステップはプログラミングで、ユニットテストで終了します。 すべてのオブジェクトはSVNに保存され、追加時にはコメントが必要です。コードの変更箇所は少なくともバージョン番号などでコメントされます。 SVNの使用に関する推奨事項も導入されました。新しいブランチが作成されたとき、メインブランチとマージされたときなどです。
彼の後-はじめに。 アーティファクトとして、リリースノートには、変更されたオブジェクトの完全なリスト、テストのヒントなどが含まれます。 プログラマーは、生きているシステムに直接導入される前に、アナリストから正式な許可を得て、変更が「運用サイクル」に違反しないようにする必要があります。 アナリストは、コードが正しいことを確認する必要があります。機能を実証するプログラマーの後ろに立ったり、データ出力を見たりすることもあります。 実装が許可されたら、分析でシステムに影響を与える責任。
テストと欠陥のプロセスについては詳しく説明しません。おそらく、誰もが持っているものであり、常に非常によく似ています。 私の場合、責任の分割、実装の許可に重点が置かれました。
ステップ3-プロセスの実装
これが最も難しい部分です。 ここでは、これらのプロセスが特効薬であることを全員と全員に納得させる必要があります。 少なくとも1人がそれらに従わない場合-すべて無駄だからです！
プレゼンテーションを行いました。 最初に最高の当局。 問題ありません。 その後-常にトリッキーな質問をし、何度も何度も編集する必要があるアナリストに。 さらに悪いことに、プログラマは仕様が必要であることを証明する必要があり、仕様は非常に短く、リリースノートはコストよりも有用です。
全員が納得した後、行動に移すことが急務です。 ドキュメントテンプレートを準備し、sharepointでライブラリを作成しました。これにより、誰もがサイトのどのメニューのどの正方形が図にあるかをすぐに理解できます。
稼いだ！
ステップ4-改善
プロセスを使用すると、最適化の方法、追加する場所について新しいアイデアが表示されます。 プロセス文書は生きた文書であり、同僚に変更を促すようにする必要があります。プロセスがすべての人に適合し、その目的に適していることが重要です。
結論
この9か月間、少しの官僚機構が必要な変更を加えました。 検証と確認のポイントが増えているため、各チームメンバーは比較的安全だと感じています。 一方で、誰もが自分の仕事に責任を感じています。なぜなら、彼はその品質がすぐにチェックされ、すぐにチェックされ、それゆえに一生懸命に努力することを知っているからです。 さらに、組織化されたチームで働くことで、誰もが必要なものとそうでないものを知っているため、モチベーションが高まります。
私の経験から誰かが恩恵を受けることを願っています。あなたの質問に喜んで答えます！