修正不可能な無限のプロジェクトへの対処

私たちは、技術的な負債を多く抱えた大規模な（1200時間以上）ウェブサイトを持っています。これは主に次の（通常の）理由が原因です。

1. 開発中に出入りする複数のプログラマー。
2. 開発中の仕様変更。
3. 多数の追加機能が（短時間で）追加されました。

顧客は多くの新しい機能を望んでおり、それは基本的にこのプロジェクトに毎週 10時間以上取り組むことになります。

技術的な負債があるため、問題の修正または調査に多くの時間を費やしていますが、通常、問題の原因は次のいずれかにあります。

1. 人々を泣かせる、恥知らずで愚かなバグ。
2. 新しい機能が影響するすべての場所を予測していなかったため、新しい機能は上記の結果をもたらしました。
3. 私たちが直面しているいくつかの他の問題（サーバーの移行、アップグレード）

私たちは毎日問題を抱えており、これを停止するために以下のことを試みました：

1. ウェブサイトのインポート、支払い、および一般的な作業に関する技術文書を作成しました。
2. 週の初めに会議を開き、現在の問題または改善点とそれらにどのように取り組むべきかについて話し合います。
3. テスト計画を立てます。プログラマーAテストB、BテストC、CテストA.次に、プロジェクトマネージャーがいくつかのテストを行います。この機能の影響については、ステージング環境に投入し、お客様に確認してもらいます。

問題は、問題が発生し続けることです...そしてどういうわけかそれを把握することができません。新機能は依然としてバグを引き起こし、古いバグは挨拶を続けます。どういうわけか-おそらくプロジェクトの規模のため-このプロジェクトを把握できていないようです。

私はこれよりも大きなプロジェクトに取り組んでいるプログラマーがたくさんいると思います。それが私が私の質問に来る理由です：

私たちは何ができるのか、何をすべきか、あなたは大規模なプロジェクトでこれらの問題を回避するのですか？

細かい編集、追加情報：

1. バージョン管理（SVN）を使用しています。
2. DTAP開発プロセスがあります。

私は悪魔の擁護者を演じますが、これがどのようになるかをあまりにも頻繁に見てきたので、あなたはそれに対処できません。私はあなたが実際にシステムの実際の問題を実際に見ている唯一の人であることを保証します、そうでなければ会社の文化はバグを打ち消してコードを修正するものであるため、それに対処する方法を尋ねる必要はないでしょう可能な限り、つまり実際の専門家がどのように機能するかを操作する

ユニットテストの作成を始めるには大きすぎると思います。ユニットテストの方法を知っている人がいないため（そしてチームの他の人の運が良ければ）、どこから始めればいいのか、場合によっては不可能です。テストは正確な実装と具体的なデータに依存しているため、すべてをインターフェース、モック、スタブなどに取り除いて最初からテストできるようになるには、非常に長い時間がかかります。また、リファクタリングが必要なものは密結合しすぎており、テストがないため、不良コードを修正することで何が破損するかを知っているため、単にリファクタリングする必要はありません。要するに、それはおそらく癌性になり、真剣に修正することはできませんが、もちろんそれを切り取って新鮮に始めることはできません。

あなたは敗北の戦いを戦っています、私の友人。あなたは欲求不満から燃え尽きて、やがてやめちゃくちゃになるか、または他の人に問題を認識させようとするのに十分長い間不平を言うなら、彼らは唯一の問題はあなたであると考え、あなたはドアを見せられるでしょう。

何もしていなければ、ユニットテストを行うことをお勧めします。少なくとも、古いバグを修正するときに新しいバグが追加されるのを防ぐことができます。

使用していない場合を除き、ソース管理も役立ちます。特に、非難とログの機能は、バグのあるコードがコミットされた方法/理由を特定するのに素晴らしいものです。

お客様の側では、変更や追加機能がリクエストされるとすぐに価格や（長い）遅延について話し合うことは、それらの話し合いや設計に費やした時間に対する請求と同様に、適切に機能することがわかりました。多くの場合、お客様は待つことができると思い直します。

（対照的に、すぐに仕様と実装のアイデアを彼と一緒に掘り下げると、彼らは通常、「ああ、とにかくこれを行うことに同意したと思った」または（さらに悪いことに、数日間戻ってから詳細はこちら）「でも、見た目はすでに設計されており、私たちが話し合った内容はそれほど難しくありません！」

最後に重要なことですが、1日1回（仕事に到着したとき）だけメールを読んでいること、および緊急事態に備えて電話を持っていることを前向きにすると、生産性が大幅に向上することがわかりました。

主に最も頻繁に壊れる領域で、CIベースのテストを追加することをお勧めします。これは、プロジェクトで作業が行われているときに品質を向上させるのに役立ちます。

また、どの領域/機能が頻繁に壊れるのかがより明確になり、リファクタリングが必要な部分や、少なくともテストの増加が必要な部分を決定するのが容易になります。

手作業によるテストのリスクを追加すると、追加された機能ごとに必要な$$$および時間の点で、プロジェクトが間違った方向に進みます。

一部のコードレビューは適切ですが、それはおそらくA-> B-> C-> Aテストスキームの一部です。（たぶん反対方向のコードレビュー？）

あなたに寓話を投げかけましょう。あなたは通りを下った日の早い段階で人と散歩をしていて、あなたは目的地に到着しました。あなたが一緒に歩いている人は、彼が途中でどこかで彼の指輪を失ったことにすぐに気付くので、あなたは両方ともバックトラックしてそれを探しに行くことにしました。歩いている人はすぐに街灯に立ち止まり、必死に見始めます。あなたは、「路地を切り開いたときにランプポストを失ったと思うのに、なぜランプポストを見ているのですか？」と言います。彼は「私は知っているが、ここでは光の方が良い」と答えます。

私はこの状況を何度か経験しており、いくつかの共通点に気づきました。これらの種類のメンテナンスの悪夢プロジェクトは、通常、プロセスの負荷が高い環境で実行され、管理によって大きな監視とプロセスの改善が課されます。プロセスの改善が悪いことだと言っているわけではありませんが、多くの場合、経営陣が実施したいと考えているプロセスの改善には、2つの重要なポイントがあります。

1）彼らは通常、オフィスの政治と権力のバランスを混乱させません。2）彼らは、問題の核心を打つのではなく、経営者による支配の幻想を生み出すことに成功している。

「光はここが良い」という経営陣は、通常、「すべての新機能には詳細な技術仕様が必要です」、または「問題とその克服方法について話し合うために、1時間ごとのステータスミーティングを毎日開催する」と言います。

これらはどちらも問題の中心にあるものではなく、生産性を低下させるだけかもしれませんが、経営者による制御の幻想を確かに検証します。

あなたが推進するのを助けることができる唯一の本当の変化は、物事を揺さぶるものです。しかし、あなたのWebサイトの怪しさはおそらく現時点では修復不可能であり、あなたはさらに再構築して書き直すことになるでしょう。ただし、将来的には、アジャイル方法論、継続的インテグレーション、テスト駆動開発、コードレビュー、および厳密な変更管理手順の下で規制されるビジネス要件仕様の重要性を覚えておくことで、スケジュールを調整せずにスコープのクリープを最小限に抑えることができます。

これらの種類の変更には、管理レベルでの考え方の変更が本当に必要であり、私の専門家としての経験全体では、なんらかの中間管理レベルのシェイクアップなしでこれが発生することはありませんでした。現状維持を愛する人々から激しい抵抗を受ける可能性があるため、困難な戦いをしている場合でも、正しいことを試す必要があるので、それがあまりにも落胆しないことを願っています。

私は少し前に同じ場所にいました。もう2つの単純なルールのおかげで、私はもうそうではありません。

• 毎週、1〜2日がアプリのほとんどの毛深い部分の修正/書き換えに費やされています。バグハンティング、新機能の開発はありません。
• 新しい機能を実装している間、お客様が期待しているよりも多くの時間を費やした場合でも、正しく機能するように努めています。

唯一の問題は、他の人々に彼らを尊敬させることです。意外と簡単な部分はお客様でした。理由を実際に説明することはできませんが、どういうわけか私たちは彼を納得させました。機能をもう少し長く作業するときは、誰にとっても良いことです。最初のルールを尊重することは問題が多いことがわかりますが、それは私たちにも非常に役立つと感じています。アプリケーションのさまざまな部分が改善されているため、着実な進歩を保証します。

コードレビュー。ユニットテスト。実際のQAテスト。仕様収集プロセスと段階的な開発-これらは、ほとんどの問題を解決するためのいくつかのことです。

また、顧客に開発者に直接pingさせないでください。これは通常、問題を解決する最も非生産的な方法です。顧客と開発者の間のインターフェースを形成する優れたプログラムマネージャーを採用します。彼の仕事は、製品のエンドツーエンド、現在のステータス、将来の方向などを知ることです。顧客が別の新しい機能を必要とするときはいつでも、彼はアイテムの現在のリストを提供し、この新しい要求が行われる場合に何が妨げられるかを顧客に示すことができるはずです。

使用量が少なすぎる、または多すぎる場合、プロセスは不良です。元の状態だと思います。

Deniが述べているように、プロジェクトに単体テストを追加できる場合は、これが役立ちます。変更/修正しようとしているシステムの一部をカバーするテストを用意してください。コードをリファクタリングするときは、そのテストをガイドとして使用して、何も壊していないことを確認してください。

また、コードの最も壊れた部分を切り分けます。影響が最も大きいものをリスクのリストに入れ、それらのリスクを個別に管理するようにしてください。バグが最も多く発生している場所を照会することにより、コードベースにどれだけの破損したコードがあるかを把握してください。次に、バグカウント（または報告された問題など、問題のないもの）ごとに影響を受ける領域を一覧表示できます。

コードのパッチとクリーンアップには時間がかかりますが、チームの各開発者がコードを少しクリーンなままにできる場合は、コードを実行する前の状態にしておけば、時間の経過とともにコードベースが向上します。あなたが迅速で軍のスタイルを探しているなら、今すぐそれを解決してください、役に立つと思われる実用的な（または推奨される）ものがあるとは思えません。

乾杯。Jas。

明確な機能仕様を記述します。あなたがそれを耐え、それらの仕様に対して機能を定期的にレビューできるならば、それは経験的にです。開発者が開発することになっていることについて開発者が持っているアイデアが少ないほど、開発者が開発するはずの方法である可能性が低くなります。

コードを書き始める前に、事前に設計作業を行ってください。これは完全なもの、巨大なもの、UMLを含むものである必要はありませんが、解決する必要のある問題に対するかなり確かな解決策の概要を示す必要があります。私が知る限り、計画されているソフトウェアの数が少ないほど、計画は悪化します。作業を始める前に、設計について話し合ってください。

コードの明らかに悪い部分で作業を開始すると、進行が本当に妨げられます。それに追加するのをやめ、問題から一歩下がって、障害がそこになく、将来より適応できるようにアーキテクチャを再設計する方法を考え出します。技術的負債に取り組む前に、それを長く残すほど、完全な書き直しなしでそれに取り組むことは難しくなります。それは指数関数的だと思います。

動作をテストし、アーキテクチャに密結合しないテストを設計します。ファッショナブルではありませんが、コードの真の目的が明確になるまでテストを開始しないでください。具体的には、何をテストしたいかがわかるまでテストを開始しないでください。IMOのよく考えられていないテストは、テストがないよりも悪いです。そして、より多くのテストを行うと、内部でコードを変更することが難しくなります。プロダクションコードと同じようにテストコードを扱います。それは計画され、よく書かれている必要があります。

定期的/毎日のコードレビューを行う：これは、開発者がコースから遠く離れていないことを確認するための健全性チェックの詳細です。これらのセッションを使用して、翌日の作業を計画します。これらが5分または1時間かかる日もあるかもしれません。重要なのは、対話を開いたままにし、開発者が他の開発者と自分の作業について話し合い、アドバイスを求める機会を与えることです。コードの難しい部分やアイデアのプロトタイプを作成するために、いくつかのペアリングセッションを行いますが、人々は自分の時間を使って作業することができます。

コードのビルドとデプロイを簡単にします。ビルド時間を短くするようにしてください。構築するのが簡単であればあるほど、構築される量が多くなるほど、迅速に構築されます。

コーディング標準を採用し、厳格に適用します。これは、プロジェクトがファイルシステムのどこにあるかから、プライベートconstのケーシングまですべてをカバーする必要があります。これは無意味で不愉快に思えるかもしれませんが、良い習慣は開発プロセスの基礎です。

基本的に、私はあなたが使うプロセスはそれほど重要ではないと思います、ファッションは行き来します。本当に重要なのは、ソフトウェアの開発方法についてプロであり、実践において規律があるということです。

最初に、煙のテストを設計および自動化し、CI環境に投入します。それらは機能するはずです。何かがうまくいくはずだと顧客から言われたら、後で参照できるように書き留めてもらいます。ソフトウェアで特定のソリューションを見つけたら、質問し、回答を受け取ったらすぐに、それらを知識ベースに組み込み、追跡可能にします。

ポジティブケースの基本機能が機能することを確認します。次に、不正確なデータ処理の増分テストの構築を開始し、必要と思われる場所に欠陥を配置します。優先順位について長く詳細に話し合い、テストマネージャーにそれを知らせて、それに応じてテスト時間を割り当てることができるようにします。すべてを自動化しようとしないでください。ただし、いくつかのテストケースが自動化されることに意味があるとすぐに、ためらわないでください。

一般的に、テストは製品への信頼を高めるために使用し、品質を即座に向上させるツールとしては使用しないでください。冷静でありながら、断定的に:)。たぶんアジャイルにしようとするかもしれませんが、あなたが絶対的に、積極的に認定されたPMに従事する場合にのみです。アジャイルを知らない人がアジャイルを紹介すると、おそらくプロジェクトが中止されます。