私は何百人もの人が本質的に同じ製品のソフトウェアを書いている会社で働いています。非常に多くの人々 (特に開発者自身) がソフトウェアに依存しているため、ソフトウェアの品質は高くなければなりません。このため、すべての主要な問題は、自動または手動のいずれかで新しいチェックを行いました。
その結果、ソフトウェアを配布するプロセスはますます負担が大きくなっています。そのため、より多くの開発者が必要になります...悪循環であることがわかります。
現在、ソフトウェアを迅速にリリースすることに問題があります。非常に深刻な問題のためにコードを 1 行変更するだけでも、リード タイムは少なくとも 1 日です。
ソフトウェアの品質を維持しながら、大規模な組織でソフトウェアの配信をスピードアップするために、どのような手法を使用していますか?
私はまた、大規模で扱いにくい組織で働いています。私はいくつかのアジャイル ソフトウェア開発方法論の実装に成功しましたが、特に価値があると感じたものが 2 つあります。
反復的で漸進的な開発- リリース サイクルを短くタイトに保ちます。大規模なチーム全体で、リリースの間に多数の変更が加えられた場合、統合の悪夢に陥る可能性があります。
大規模な組織は、開発期間が長い大規模なプロジェクト計画に傾倒しています。これと戦ってください。開発の最初の 2 週間後に全体的な認識が変わる可能性がある場合、丸 1 年かけてプロジェクトを計画しても意味がありません。小さな増分リリースを作成し、絶え間なく変化する要件に適応するという考えに慣れるように、利害関係者を調整します。
自動化された単体テスト- これは、高品質のソフトウェアをリリースしていることを保証する優れた方法です。最悪のバグは、一見無害に見えるコード変更によって引き起こされ、他の場所で意図しない結果をもたらします。包括的な単体テストは、この種のバグを発見する最良の方法かもしれません。卒業してテスト駆動開発または動作駆動開発に進むことができれば、なおさらです。
大規模な組織には、平凡な開発者が何人かいます。それは人生の事実です。自動化された単体テストは、それらを監視する優れた方法です。優秀な開発者の 1 人に単体テストを作成してもらいます。少なくとも彼らのコードが (醜いものであっても) 動作するという保証が得られます。
継続的インテグレーションを参照してください
プロセスを改善する方法はたくさんありますが、重要な要素はモジュール性です。責任を (コード内と組織内の両方で) 明確に分離し、明確で一貫性のあるインターフェイスを定義することで、1 つの大規模なチームが、すべてが結ばれた多くの小規模なチームのように機能することができます。
賢明だが悲観的なことわざ：
Fred Brooks:遅れているプロジェクトにプログラマーを追加すると、プロジェクトが遅くなります。
Gerry Sussman: プログラマーは抵抗器を並列に組み合わせます。
他の誰か: プロジェクトのコストは、プログラマーの数にスケジュールの長さを掛けたものです。
うまくいくかもしれない何か：
プロジェクトを編成して、1 人または 2 人で構築されたコア アプリケーションが存在するようにします。できれば、言語を介して操作します。次に、その言語でコーディングすることにより、すべてのプログラマーを効果的にコアのユーザーにします。