ヘビー級の開発方法論で個人的な練習をする方法は？

私は新しい仕事に取り組んでいます。プロジェクトは厳しい品質基準を満たす必要があり、詳細に文書化され、非常に詳細に管理され、UMLダイアグラムなど、これまでのほとんどの仕事の経験である「カウボーイコーディング」とは反対のすべてのものです。 。大規模な航空宇宙または医療機器ソフトウェアの開発方法を考えてみてください。

カウボーイコーディングの混乱を残してよかったと思います。ヘビー級のエンジニアリング手法がどれほどうまくいくか知りたいです。しかし、どのようにして重いメソッドの経験を迅速に得ることができますか？

単に数か月/数年の間仕事にいるだけでなく、それはです。

単なる言語、または新しいAPIで、おもちゃのテストプログラムをハックしたり、読んだり、意図的に間違いを起こして何が起こるかを確認したりできます。自転車に乗ったり楽器を演奏したりするのと同じように、練習は不可欠です。フルートを手に取り、毎日30分を費やすのは簡単です。オーケストラに参加したり、フルタイムのフルートコンサルタントになる必要はありません。しかし、大規模で複雑で、チームが関与するソフトウェアエンジニアリング活動をどのように実践するのでしょうか。そのほとんどは、コミュニケーションと計画、コミュニケーションの誤りの回避、およびスケジュールと予算の制限の超過に関するものです。

これは一人で行うことは不可能のようです。少数の人が大きなプロジェクト全体を短時間で（1日）小規模にエンジニアリングできる方法はありますか？

少数の人が大きなプロジェクト全体を短時間で（1日）小規模にエンジニアリングできる方法はありますか？

はい、これはある程度可能です。約10年前、私はミュンヘンでのOOP会議のワークショップに参加しました。そこでは、16人が中小企業向けソフトウェアの大まかな分析と設計を行うタスクを与えられました。1日の前半は主に16人でタスクを解決するためのチーム構造を見つけることであり、1日の後半はこのチームでタスクを解決することに焦点を当てました。

最初の部分では、16人を4人のグループに分けるように案内されました。4人のチームごとに、チーム構造の提案を（時間のプレッシャーの下で）解決する必要があり、その後、シュートアウトプロセスを適用して、どのチーム構造が最適であり、ワークショップの2番目の部分で使用する必要があるかを決定しました。

残念ながら、最初の部分では、16人のそれぞれに意図されたチーム構造内での仕事を与えようとすることを間違えました。その間違いは後半に混乱をもたらします-16人はそのような課題を解決するには多すぎるためです。有効な解決策は、16人をさらに小さなチームに分割するか、3人または4人を選択して主な作業を行うことでしたが、猛暑の中でこれを見逃してしまいました。

大きなプロジェクト組織でその日に直面する典型的な問題について多くのことを学んだという印象はまだあります。こんなワークショップをどこに行ってくれるのか、最近誰がそういうのを提供してくれるのかは分かりませんが、機会があれば是非参加したいです。

チェックリストから始めます。（あなたはそれが最初のステップだと知っていましたよね？）
チェックリストに現在のプロジェクトのすべての標準ドキュメントがリストされていることを確認してください。すなわち。UMLダイアグラム、機能仕様、高レベルおよび低レベル設計など...私のシステムエンジニアは、RTVM（要件トレーサビリティ検証マトリックス）の使用を提案します

作業するサンプルプログラムを選択してください。あなたがそれを思いつくことができないなら、グーグル「コードカタ」をググするか、チャレンジのグーグルのcodejamアーカイブをチェックしてください。または、電卓を作成します。:-)

サンプルプログラムの機能仕様を作成します。次に、高レベルの設計、UML図などに移ります。仕様に合わせて構築します。試して。（現在の作業慣行で定義されているように）仕様に重大な欠陥を見つけるたびに、SDLCのその段階に戻って修正し、次に進む必要があります。

最初のラウンドでは、先に進んでそれを小さくしてください。プロセスを循環させることは、特定のステージ内でのやり過ぎよりも重要です。後続のラウンドでは、中断した機能を追加します。トレース、ロギング、パフォーマンス分析、テストの足場など。何を追加するかは、雇用主が実際の仕事に何を期待しているかによって異なります。

設計、構築、テスト、繰り返しのサイクルを数回繰り返した後、今気になっている「重い」コンポーネントのスキルと経験を積み上げます。反復は、さまざまなステージと生成されたドキュメント間の相互接続も示します。ドキュメントの更新とテスト要件により、5分間のコード変更が他の場所で数時間の波及効果をもたらす可能性があることを示す貴重なレッスンです。

「ヘビー級」の実践での経験は、本当のことをすることからのみ得られます。単独で効果的に実践する方法はありません。ただし、学習することはできます。多くのケーススタディとソースがあり、検討したり熟考したりできます。

しかし、あなたが見たり研究したりするすべての習慣が必ずしも肯定的であるとは限りません。ソフトウェア開発は流動的なものであり、ハードコアで厳格な今日のことは、明日はばかげた冗長なものに見えるかもしれません。これは、新しいツールと実験的な経験の両方を通じて、新興企業からより保守的な組織へと沸騰しています。

基本的に、変更とリスク管理は組織ごとに独自の形をしているようです。あなたの最善の策は、オープンマインドを保つことですが、チーム間であまり多くの仮定を行わないでください。