19

私はときどき、技術者と非技術者の両方のために、ホワイトボード (非仮想) データ フロー、アーキテクチャ図などに即興で呼ばれます。残念ながら、私の描画スキル (および印刷物の読みやすさ) はひどいものです。

どうすればこれをより効果的に行うことができますか? 使用する標準記号とコネクタ、情報を整理および分類する標準的な方法 (例:スイムレーン) などに関するヒントを探しています。

これが上手くなるには何を練習すればいいですか？私はこれらの視覚的なプレゼンテーションが私の考えを伝えるのに効果的であることを望んでいます.

4

12 に答える 12

23

ホワイトボーディングは素晴らしいツールです。私はそれを自分でかなり行っていますが、いくつかのことが非常に効果的であることがわかりました。

  • 最小限の記号のセットを使用します。ボックス、矢印、円、および線を使用すると、長い道のりを歩むことができます。より高度なモデリング手法よりも単純なものを優先します。誰もがボックスと矢印を理解しています。
  • あなたが描いているものを聴衆が理解できるように、絵を描いている間は声を出して考えてください。
  • 視聴者とコミュニケーションを取りましょう。ホワイトボーディングは一方向のコミュニケーションではありません。メッセージが伝わったのか、絵が理解できたのかわからない場合は、質問してください。
  • 聴衆が十分に少ない場合は、人々をボードに近づけ、人々があなたと一緒に描くことができるようにペンをすぐに利用できるようにします。これにより、視覚的に支援されたコミュニケーションが向上し、さらに効率的なホワイトボードセッションが可能になります。
  • 「きちんと」書いたり描いたりするのに十分な時間をかけますが、完璧な手書きよりも安定したコミュニケーション速度を好みます。これは難しいトレードオフであり、ある程度の練習が必要です。書き込みと描画を理解しやすくしながら練習すると、書き込みと描画の両方の速度が向上します。
于 2010-02-23T18:31:29.597 に答える
12

徐行。

時間をかけて丁寧に書いても大丈夫です。

于 2010-02-23T18:26:51.643 に答える
11

かなり基本的ですが、漫画の吹き出しを描くことからのこのヒントは、私に大きな違いをもたらしました。ボックスを描いてから、その中にテキストを書いてはいけません。通常、必要なサイズを誤って判断すると、テキストが押しつぶされて判読できなくなります。代わりに、最初にラベルを書き、後でその周りにボックスを描きます。

この1つの単純な原則を適用することで、図の明瞭さがどれほど向上したかに驚きました。

于 2010-02-23T18:32:35.183 に答える
9

ホワイトボーディングのもう1つの良いヒントは、デジタルカメラを持ってセッションの写真を撮ることです。ミーティングの後でそれをシェアに投げることができ、そのように過去のセッションをレビューできるのは素晴らしいことです。

于 2010-02-23T18:34:21.520 に答える
2

少し遅れていることは承知していますが、実際に達成しようとしていることを文章または箇条書きで書き留めておくことをお勧めします。さまざまなことに取り組むことは非常に簡単であり、これは非常に早い段階でそれを乗り越えます。また、要件のクリープを管理/監視するためにも使用できます。

最後になりましたが、ERダイアグラムやその他のモデリングに進む前に、最初から始めることもできます。

于 2011-03-08T16:47:52.573 に答える
2

オブジェクト間の関係について話し合うときに簡単に移動できるので、私はよくポストイットノートに書き込みます。また、異なる色のポストイットは意味を伝えることができます。

以下に例を示します。

代替テキストhttp://www.matterco.com/wp-content/themes/matter/images/art057.jpg

于 2010-02-23T18:34:15.410 に答える
2
  • 1 つの図に多くのことを詰め込もうとすると、混乱する可能性があります。
    • より大きなモジュールを描画して接続できるアイデアのドリルダウンを視覚化してみてください。アイデアをホワイトボードに保存してフィードバックを得る方法として、この図のスナップショットを撮ってください。
    • より小さなモジュールに焦点を当て、該当する場合はドリルダウンを適用します。

Wikiには、さまざまなシナリオに適したさまざまな図に関する基本的な情報がいくつかあります。

これが役立つことを願っています。

乾杯

于 2010-02-23T18:35:26.743 に答える
1

ER 作図に精通していますか? データベースをモデリングしている場合、ER図はほとんどの人にとって非常に普遍的です。

于 2010-02-23T18:28:00.797 に答える
1

大きなホワイトボードを用意してください。
大きければ大きいほど、アイデアをより明確に説明できます。

于 2010-02-23T18:54:52.977 に答える
1

多くのプログラマーがUMLを「絶対に見られない文書に入れさせたがる愚かながらくた」と考える傾向があることは知っていますが、実際にはUMLはプログラマーのコミュニケーションの問題を解決するために設計されました。

開いた矢印を使用するか閉じた矢印を使用するかはめったに重要ではありませんが、間違った矢印を使用すると一部の人々を混乱させるという事実があるため、UML を理解してください。プログラマーは非常にひたむきな生き物であり、それは彼らがしばしば「立ち往生」することを楽しむものの 1 つです。

いくつかの基本的な UML 図の種類を知っている。誰もがある程度のオブジェクト図を知っています。私はよく、継承図と包含図を同じ図にまとめます。厳密になりすぎないようにします。

いくつかのフロー ダイアグラムを読み、実際に作業中の複雑なフロー用に 1 つ作成します。彼らは、何が起こっているのかを分析し、些細な単一のメソッド呼び出し/リターンを超えて何かを伝えるのがとてもクールです。私は自分のキャリアの約 3 分の 1 の間、これらのことを知りませんでした。誰かがホワイトボードに最初にそれを投げ出したときはただ唖然としました (これは私がすべてを知った後でしたが、もちろん、毎年より多くを学んでから決定します)私は最終的にすべてを知っています）。

最後に、あなたはそこに立ってその人と話しているのです。実際、ホワイト ボード上のボックスは、次に指差したときに、同じことを意味していることを相手が理解できるように、指差すことができるものにすぎません。これは、口頭でのコミュニケーションを強化するための視覚的な補助手段です。それだけです。

編集：

このページは、多くの優れた例を含むシーケンス図の優れた紹介です。

于 2010-02-23T18:59:52.613 に答える
0

アーキテクチャ図は UML である必要があります。

でも。

詳細な UML ダイアグラムを作成するのは骨の折れる作業なので、技術的な深さは求めないでください。

ただし、「高レベル」の要約図で多数のベースをカバーできるようにするのに非常に役立つ分類子のステレオタイプがいくつかあります。

Control、Boundary、および Entity クラスの「Objectory クラス ステレオタイプ」( http://doc.sumy.ua/prog/umld/AD970806.PDFを参照) は、金の価値があります。これらのステレオタイプをクラス図に追加することは、クラス (またはパッケージ) が全体にどのように適合するかを定義するのに役立ち、迅速かつ正式な方法です。

于 2010-02-23T18:39:11.447 に答える
0

私自身、Galactic Modeling Languageの大ファンです。

于 2010-02-23T18:48:40.743 に答える