スクラムのような適応的でアジャイルなエンジニアリング方法論に入る人の中には、自分が何に夢中になっているのか理解できない人もいるかもしれません。
アジャイルエンジニアリングである理由は、現在使用可能なものをすべて顧客にリリースし、その使いやすさと機能を徐々に構築することです。
- プロジェクトが18か月で完了すると予測されているが、2か月ごとに使用できるものが増える可能性がある場合は、どちらの方法でもプロジェクトが18か月続くので、18か月先の壮大な聖日まで待つのではなく、2か月ごとに機能をリリースしてみませんか。 。
- 顧客の要件が変わる可能性があるため、手遅れになる前に頻繁に考えを変える機会を顧客に与えると、顧客は元気になります。
- 誰かがあなたのモジュールの1つのオープンソースモジュールを今から10か月後にリリースするかもしれません、そしてあなたは他に多くをする必要はありませんがそのモジュールを統合します。
したがって、スクラムマー、または少なくともスクラムマスターおよび/またはプロジェクトマネージャー/アーキテクトは、モジュール化するためにスクラムのダイナミクスによって必要とされます...モジュール化は十分ではありません。しかし、プロジェクトを細かくします。
モジュール内の変更がモジュール内で管理されるように、モジュールを適切なサイズに細分化し、それぞれにコントラクトインターフェイス仕様を提供する必要があります。モジュール自体または他のモジュールの依存によりコントラクトインターフェイスを満たすことができない場合は、コードをフリーズしてコントラクトインターフェイスバージョン1をブロードキャストできるようにする必要があります。これにより、他のチームは予想よりも少ない機能で続行できます。次の一般的な製品リリースで。
コードフリーズはコードフリーズです。
コードのフリーズで解凍の遅延が頻繁に発生する場合は、スクラムマスターと製品アーキテクトが通信していないか、適切に作業を行っていません。おそらく、彼らがアジャイルプログラミングと呼ばれる業界の流行を使用していることを経営陣に印象づけたり黙認したりしようとしても意味がありません。または、経営陣は、チームのスキルだけでなく、顧客の期待やプロジェクトの技術的制約の範囲内でプロジェクトを設計および細分化できるアーキテクトとスクラムマスターを雇う必要があります。
優れたアーキテクトがスクラム環境にとってどれほど重要であるかを理解しておらず、採用を拒否している管理要素とそのスクラムマスターがいると思います。チームに耳を傾け、チームと協力できる優れたアーキテクトは、変化する粒度と期待にアーキテクチャを絶えず適応させる必要があるため、スクラムプロセスにとって非常に貴重です。
また、ウォーターフォールなどの開発サイクルが長いという悪い経験のために、プログラミングユニバースの他のスペクトルに属する管理要素とそのスクラムマスターがいると思います。したがって、スクラムは1か月以内に製品を生産することを目的としているため、綿密な調査が必要です。クロスモジュール効果に実際に必要ではありません。彼らは座って、空中で指を濡らし、素晴らしいスプリントを思いつきます。
チームでコードフリーズの解凍が頻繁に発生している場合は、プロジェクト全体をコードフリーズして戦略を再考し、モジュールの粒度に適合するモジュールコントラクトを定義することを拒否したことが原因であることを確認する必要があります。または、スタックしたモジュールの機能を現在希薄化して他のチームやモジュールを続行できるようにするために、モジュールコントラクトを定義していますか？
プロジェクトリリースの予測される機能を発見し、取り残されたモジュールの効果を確認してから、目的の製品リリースレベルに到達するためにどのモジュールに焦点を当てる必要があるかを確認できるUML戦略がありますか？スクラムやスプリントに参加していて、UMLの写真がないので、自分がどれだけ進んでいるか遅れているかを示しているので、楽しくまたは盲目的にぶつかっていますか？または、スクラムマスターは、いや、いや、うーん...そのモジュールは重要だと思いますか？実際には、製品リリースに関連して最もストランド可能なモジュールを明確に把握する必要はありません。
製品リリースのコードフリーズは、モジュールの段階的なフリーズによって実現されます。モジュールが完了するとすぐに、製品テストが実行され、モジュールがその契約を満たし、そのモジュールがバージョン2.1と言うようにコード凍結されていることを確認します。2.2ではそのモジュールで作業が進行しますが、プロジェクト全体は2.2ではなく2.1に依存する必要があります。戦略は、製品リリースのテスト時にコントラクトを解凍する必要があるモジュールの数を最小限に抑え、製品リリースでその機能を縮小する必要があるかどうかを確認することです。プログレッシブモジュラーフリーズが開発チームに役立たない場合...製品が非常に複雑で、管理者が適切なリリースを達成するための反復回数を過小評価しているか、モジュラーアーキテクチャと戦略を真剣に再考する必要があります。