春節から戻った後、新しいチームでの仕事に適応しました。
チームはすでに存在しており、使用されるテクノロジー スタックはなじみがなく、行われているビジネス分野もほとんど関与していません。課題は比較的大きいです。
経営陣はチームの成果に不満を持っています。私の最優先事項は、チームの有効性を向上させることです。
現在、チームのソフトウェア開発管理は定型化されておらず、比較的カジュアルであり、多くの問題はソフトウェア開発に共通しています。
この場合、私はまず自分自身をコーチと見なし、過去の経験と教訓を整理し、チームの現在の状況に応じて選択および調整し、個々のプロジェクトでチームと一緒に使用して、このビジネスに適したものを形成することを選択しますそしてこのチームのドライメソッド。その過程で、習慣、規範、人、人と人との関係など、必然的にいくつかの変化がもたらされます。会社にも慣性があり、チームには慣性があり、変更を加えなければならない、思い切った薬ではなく、ゆっくりと調整し、小さく始め、受け入れたい部分から始め、結果を出し、徐々に推進する必要があります。
同時にコーチと学生になり、新しいテクノロジー スタックを学び、新しいビジネス分野を学び、できるだけ早くチーム メンバーになれるようにします。
この場合、チーム内のコミュニケーションを容易にするために、ソフトウェア開発のルーチンを抽出して文書化する必要があります。
分野：応用システムのソフトウェア開発
主な内容は、次のキーワードで要約できます。
-
ビジネス分析: オブジェクト関係図、状態図、アクティビティ図、ユース ケース図、およびレポート要件。
-
分析と設計プロセス: 静的モデル => 動的モデル; モデリング結果 => ストレージ構造、メモリ データ構造; フロントエンドとバックエンドのドッキング用の安静な API のリスト。
-
プロジェクトの範囲: ユース ケース図 => 機能機能 (非機能機能の重ね合わせ) => タスク分割 => ワークロード評価 (フロントエンド、バックエンド、テスト)。
-
プロジェクト プロセス: プロジェクトの開始、プロジェクトの計画、チェックポイント、アジャイル、レビュー。
1. ビジネス分析
アプリケーションシステムを作ることは、ビジネス上の問題を解決することです。
ビジネス上の問題を解決するには、まずビジネスを理解し、ビジネスにどのアクター (Actors) がいて、どのような要求があり、どのような問題を抱えているかを理解する必要があります。
したがって、まずビジネスの理解と分析から始め、ビジネス モデル化を行う必要があります。
近年業界で多く提案されているDDDもビジネスモデリングの手法です。ビジネス オブジェクトの識別、サブドメインの分割、集約関係の設計も重要な要素です。
私は 3 つの写真から始めることに慣れています。
-
オブジェクト図
-
状態図
-
活動図
ここでのオブジェクト関係図は、UML のクラス図に近く、目的はビジネス オブジェクトとそれらの間の関係を識別することです。状態図やアクティビティ図も基本的にUMLで定義されています。
私にとって、この3枚の絵はユビキタス言語の役割を担っています。ユビキタス言語は、ビジネス関係者、製品、開発、テストなどのプロジェクト メンバー間でビジネスやソリューションを伝達するための共通言語として機能します。
ビジネス オブジェクトを識別することは、最も基本的でコアです。
オブジェクト関係図は、ビジネス オブジェクトとその関係を識別して整理するのに役立ちます。一般に、システムのビジネス オブジェクトとそれらの関係を記述するには、複数の図が必要です。オブジェクト間の関係がより複雑な場合、さまざまなグラフを使用して、さまざまな次元のオブジェクト間の関係を記述する必要があります。
リレーションシップの説明は、単純かつ大まかに、1 対 1、1 対多、および多対多を区別できます。昨年、私は Feishu が UML ダイアグラムを描画するための優れたツールを持っていることを発見しました.これらの標準化された関係の集約、構成、および展開を使用して、より良い結果を達成することができます.
例 1: 1:n の関係
例 2: 集約、拡張などで正規化された説明
システムのユーザーは、通常、オブジェクト関係図で分析されます。
オブジェクト図は静的モデルです。
動的モデルは状態図とアクティビティ図で記述され、両者は相互に検証できます。シーケンス図はめったに使用されません. 通常、呼び出し関係がより複雑な場合、または第三者との呼び出し関係が多い場合にのみ描画されます. 通常、設計またはコーディングの段階で使用されます.
状態図: まず、オブジェクトが状態を持っているかどうかを識別する必要があります。状態が存在する場合、どの状態が存在するか、複数の次元で状態が存在するかどうか、オブジェクト間の状態間に関係があるかどうか。
アクティビティ図は通常、スイムレーン図の形式で描かれます。ビジネスが比較的単純な場合は、単純化することもできます。
これら 3 種類のダイアグラムは、一般的にビジネス モデリングで使用されます。
この3種類の図を書いていく過程で、名詞表や各種列挙値などのマスターデータが自然と形成されていきます。
業務モデリングだけでなく、システムの要件境界を整理してシステム機能を設計する必要があるため、業務目的から機能点や特徴を分解するユースケース図も必要です。
各機能ポイントでは、ビジネス ロジックに加えて、関連するオブジェクトへの制限と影響の説明に集中できます。
レポート要件も、この段階で収集する必要がある重要な情報です。レポートから、ビジネス オブジェクトとその関係を逆にして検証できます。レポートの統計要件は、一部のディメンション、マスター データ、および見過ごされやすいものを発見するのに役立ちます。さらに、レポートはデータ ストレージ構造の設計に比較的大きな影響を与えるため、できるだけ早く収集する必要があります。一部の製品所有者は、この点を無視して、システムが稼働した後にレポート要件を実行できると考えています。これまでの業務では、レポートを作成する際に、データが欠落していたり、データの粒度が要件を満たしていなかったりすることが何度もあり、作業負荷が大きくなりました。レポートの要件を満たすために、データ構造を調整してデータの冗長性を高めることがより一般的です。
私が恵甸科技にいた頃は、顧客のニーズを調査するために顧客のところに行くのが標準的な行動でした.さまざまなビジネス部門にインタビューすることに加えて、組織構造とさまざまなフォームとレポートを要求することが標準的な行動でした. これらを踏まえ、取材内容を組み合わせ、各業務プロセスを整理します。20年経った今でも機能しています。
普段は業務分析に最も力を入れており、実際の業務でも最も時間を費やしています。
2.概略設計
設計書は基本的に概略設計のみを行います。特に複雑な業務ロジックがない限り、別途フローチャートを描いて詳細設計を行います。
ドキュメンテーション、少ないほど良い。
読まない文書を書かないでください; 書けるか書けない文書を書かないでください。
ドキュメント管理で最も難しい部分は、更新と維持、つまり最新の状態に保つことです。書けば書くほど、メンテナンスの労力は大きくなります。メンテする時間がなくなるとドキュメントの有効性が低下し、誰もゆっくり読まなくなり、誰も読まないとメンテするモチベーションがなくなる、という悪循環に陥ります。
アウトラインデザイン、私は主に2つの部分に焦点を当てています:
-
データベースのストレージ構造
-
API リスト (現在は一般的に Restful API リスト) は、フロントエンドとバックエンドのドッキング、またはサービス間の呼び出しに使用されます。Restful API リストでは、メソッドと URL を記述するだけで、パラメーターと戻り値を詳細に記述する必要はありません。
これらの 2 つのカテゴリに加えて、配置トポロジの設計、特定のモジュールのコード構造の設計など、特定のトピックに関する設計ドキュメントも必要です。
デザインについて、私の見解：
-
デザインとは、構造上の問題を解決することです。データ構造、コード構造、インターフェイス定義はすべて構造を伴うため、注意を払う必要があります。構造の細部に影響を与えるものではなく、設計段階で一般性を知っていれば十分です。
-
デザインはその理由に答えます。このオプションを選択する理由、別のオプションを選択しない理由。私はよく「どうして」が良い質問だと思います。設計プロセスでは、設計に影響を与えるキー ポイントを見つける必要があります.キー ポイントごとに、少なくとも 2 つのオプションが提供され、B ではなく A が選択された理由を示して、設計の決定を明確にします。
文書の特定の形式はさまざまです。
マインド マップ、Excel テーブル、ppt、または手書きや手描きの写真をアーカイブに使用できます。データ構造の記述は、ドキュメントとして個別に記述することも、コードを直接参照することもできます。
3. プロジェクト管理
私たちはしばしば仕事で問題に直面します: この問題はいつうまくいくでしょうか?
多くの場合、簡単な答えを出すことは困難です。
プロセスを分解してみましょう。
まずはターゲットの確認
多くの場合、ビジネス側は一般的な説明を提供するだけであり、最初に実際の要求と目標を把握する必要があります。
目標の記述は、ビジネスの観点から行う必要があります。シナリオと組み合わせて、ユーザーがシステムで達成できることを説明し、これらのことに優先順位を付けます。実際の操作はもっと複雑になります. A を実現するのと B を実現するのとでどちらが重要かを比較するだけではありません. 多くの場合、A のようなものの経験値は 60 点から 80 点に上昇します. サポート (60ポイント）が優先されます。比較しやすいように、分解して比較的小さな項目に分割する必要があります。それが WBS (Work Breakdown Structure) です。
ユースケース図を描いて、ユーザーの要求を特定の機能点と特徴点に絞り込みます。これは、ユーザーの懸念を見つけて優先順位を付けるのに役立ちます。機能的な特徴、非機能的な特徴、ビジネス規模、パフォーマンス、可用性、およびセキュリティに加えて、これらも理解し、業務に追加する必要があります。
注意すべきことは、解体後、真の目的は事業目的の達成であることを忘れてはならず、多くの機能点に迷い込んで初心を忘れてはならないということです。
続いてワークロードの評価
Barclays でスクラムを使い始めてから、ストーリー ポイント方式は非常に優れていると思います。ビジネス オブジェクトの属性の数と複雑さなどの要因に応じて、総合評価、およびベンチマーク タスクに基づくスケール評価。例えば、属性数が10以下の単純なオブジェクトのCRUD機能をベンチマークとして設定し、2SPに対応させ、それとの比較に基づいて他のタスクを推定します。タスクの作業負荷の見積もりは、1、2、3、5、8、13、21、∞からのみ選択できます。
フロントエンド、バックエンド、テスト、それぞれが自分自身を評価します。
設計、コーディング、自己テスト、統合テスト、および問題解決を含む推定ワークロード。タスクの受け入れから配信目標の達成まで、プロセスで必要なコミュニケーションと文書化を含み、完了する必要があるすべての作業。チームの全員が各タスクの評価を行います。
3 人対 8 人のように、人によって見積もりが大きく異なる場合は、コミュニケーションが必要です。この場合、2 つの一般的な理由が考えられます: 1. タスクの目標と境界の理解に一貫性がない; 2. 大きな違いがある実装計画の不一致で。
できるだけ早く問題を見つけ、連絡を取り、できるだけ早く解決します。
3つ目はスケジューリング
1 人が 1 週間に達成できるストーリー ポイント数などのデータが蓄積されている場合は、スケジュールが立てやすくなります。
プロジェクトの時間と人員は固定されていることが多く、その際、各タスクの顧客価値と作業量に応じて優先度を総合的に評価し、プロジェクト範囲を選択する必要があります。
実際にはもっと厄介なのは、人が同時に複数のプロジェクトに参加していることです。多くの人、特にソフトウェア開発のバックグラウンドを持たない人は、エンジニアが並行して作業することを望んでいます。1 人が同時に複数のプロジェクトを処理し、タイムシェアリングと並行処理を行っているため、非常に効率的です。しかし、一人の人間が複数の作業を行ったり来たりすること、アイデアを切り替えること、環境を切り替えることはすべて消費を引き起こし、品質に影響を与えやすくなります。
また、タスク間の依存関係、複数人でのコラボレーション時の進行調整、クリティカル パスと優先順位の調整はすべて日常的なタスクです。小さなチームや小さなタスクの場合は、口頭でのコミュニケーションで十分です。中程度の規模では、ガント チャートの古くからあるツールがうまく機能します。
これらは日常的な行動です。
プロジェクト管理において、私が目にする問題はさらに 2 つです。
一つは、コミュニケーション不足と情報の非対称性です。情報の非対称性には多くの点があり、より大きな問題は、第一線の従業員が目の前の特定のタスクしか見ておらず、背景や目標を理解しておらず、その後の仕事の手配に期待を寄せていないことです。プロジェクトのキックオフミーティング、朝のミーティング、毎週のミーティング、毎月の部門ミーティングを通じて、情報を上から下に渡す必要があります。相乗効果を生み出すために、ここで行わなければならない具体的な作業がたくさんあります。
もう 1 つは、リプレイもクローズド ループもありません。個人、チーム、レビューの欠如、方法と方法の改善なし、低レベルの繰り返し。
私のルーティンはほぼ同じです。
クーデターはありません。手だけです。具体的なツールや手法は独自のものではなく、10 年前、20 年前、あるいはそれ以前から業界で広く使用されていたもので、多くの人にとっては基本的なスキルにすぎません。
私の日課は、これらの基本的なスキルを身に付けて、それをしっかりと行うことです.
実際には、個人でもチームでも、基本的なスキルが整っていれば上位 20% に到達し、市場で競争力を持つことができます。
最後に、プロセス、ツール、方法がどんなに優れていても、R&D システムを担うのは人です。チームを率いる上で最も重要なことは、人々をツールやリソースとしてではなく、人として扱うことです。チームメンバーの成長を気遣い、彼の感情に注意を払うことによってのみ、真の信頼を築き、戦闘の有効性を形成することができます.
黄色い鶴
2023-03-18