1.機能設計の3W1H
1.機能設計とは？
迅速なイテレーションを実現するために、ソフトウェア開発ライフサイクルでの概要設計と詳細設計を合理化することによって生成される中間製品は、プロジェクト管理のための管理担当者のコアコントロール能力であり、開発者が開発をガイドするためのコアアイデアです。
2.なぜ機能設計をするのですか？
建設期間は合理的で、分業は合理的ですか？
それらの半分は、ブロック機能が欠落していることを発見しましたか？
マネージャーとして、何に注力すべきかなど
管理または羊管理を行ったばかりの多くのマネージャーは詳細な制御を持たないため、チームを泥沼に連れ込むのは簡単です
3.機能設計はいつ行うべきですか？
機能設計を開発プロセスに組み込み、次にコンテンツを共有する
4.機能設計を行う方法は？
これは大きなコンテンツであり、さまざまなシナリオに応じて異なるデザインにする必要があります
2.機能設計を開発プロセスに統合するには？
2.1機能設計を開発プロセスに統合する
（新しいタブを右クリックして開き、全体像を表示します）
2.2主要な時間ノードの例
2.3コア出力製品
需要フィードバック
現在、より良い方法は、オンラインでの質問に答えたり、コメントを追加したり、将来のクエリのためにアーカイブしたりできるオンラインドキュメントであることがわかっています。
機能設計実績
クラス図、タイミング図、状態図などのオブジェクト指向の設計方法を描くことにより、要件を解体
主な成果の最終出力：
機能設計書、
機能、サブディビジョン（担当者に明確）
開発者の出力スケジューリング
機能設計レビューの後、開発者は機能設計を理解して吸収し、独自の設計をスケジュールします。
もちろん、これは開発ラインの終わりではありません。マネージャがまだレビューされる必要があるからです。
開発スケジュールのレビュー：
3日間でフライトコントロール1.各行に、分割の三日以上
のデザイナーの上方または下方2.スケジュールが意図し、理解や設計指針の違いを補うために、通信する
予定の期待3.プロダクトマネージャーより、プロダクトマネージャー/スーパーバイザー/開発者が互いにコミュニケーションを取り、機能の範囲を狭めるか、開発時間を短縮する方法を見つける
コードレビュー
今日のテーマは、機能設計を開発プロセスに統合することであり、コードレビューではありません。ここでのレビューは、主に、開発されたコードが機能設計から逸脱しているかどうかを再度確認することです。これは検証環境であり、開発者として共有することもできます。リンク
開発テストの完了後、コードレビューを整理し、各開発者
が設計のレビューとして作成した汎用モジュールを紹介し、さらなる改善の基礎として設計の品質を要約し、
潜在的な問題を見つけ、開発者のコミュニケーションを行使します。集計能力は、担当者が休暇を求めて問題が発生したときに、問題をすばやく特定して解決する
別のトピック：機能設計を行う方法？
このトピックは、オブジェクト指向設計を含む幅広い側面をカバーし、クラス図、状態図、タイミング図などのツールを使用でき、大きなトピックです
まず第一に、設計の習慣を身に付ける必要があります。これは、管理が簡単で、開発効率とチームワーク効率の向上にもつながります。