テスト駆動型とビジネス要件の絶え間ない変化

CTO / CIOによって設定された開発チームの新しい要件の1つは、テスト駆動型の開発になることですが、開発のライフサイクルを把握していないため、ビジネスの残りの部分は役に立たないと思います。 1つのスプリント内で常に変更されました。これは、10のテストケースを書くことに時間を浪費することに苛立ち、明日は役に立たなくなります。

これらの要件の変更を回避し、開発ライフサイクルについてビジネスを教育するプロセスを設定することを提案しました。ビジネスがアイデアを得られない場合はどうなりますか？あなたならどうしますか？

あなたの質問は、TDDが開発ライフサイクルに拘束されていることを示唆しているようです。同意するかどうかわかりません。

柔軟で変化する要件に対する答えは、反復的な開発です。TDDはこれについて、またはソフトウェアのスケジュールについて何も言うことはありません。どんな要件やスケジュールでもソフトウェアを開発するためのツールです。要件が変わると、ソフトウェアも変わります。これは単体テストにも当てはまります。

TDDは要件を作成しませんが、一部の支持者は要件を作成することを提案しています。むしろ、要件は単体テストを推進し、それが次に書かれたコードを推進します。テストからアーキテクチャを拡張したり、テストで要件を開発したりすることはありません。代わりに、テストは指定されたアーキテクチャと要件の結果です。

ソフトウェア開発のアトミック（メソッド/ユニットテスト）レベルで要件が変化している場合は、要件が細かすぎることをお勧めします。 要件は、指定する必要がありますどのようなない、ソフトウェアがないか、それはそれをしません。ソフトウェアがどのように要件を満たすかは、主要な利害関係者ではなく、ソフトウェア開発者の領域と責任です。

別の言い方をすれば、私は顧客やビジネスオーナーに会社の運営方法を教えたり、クラスの設計方法を教えたりしません。

要件の変更は正常なことですが、日常的に変化し、スプリントの途中で要件を変更する場合、これは、意味のある定性的な方法でソフトウェアを開発するのに役立つ環境ではありません。言い換えれば、TDDはここでの問題の中で最も少なく、より根本的なものです。

あなたはスプリントについて言及しています。つまり、ある種のアジャイル開発を行っているということは、良いことです。短いクイックスプリントで開発を処理することは、優先順位と要件が不安定でプロジェクトの途中で変更される可能性がある場合に、プロジェクトでうまく機能します。深刻な問題は、スプリントの最中に開発チームとテストチームの要件が大幅に変化することです。

スプリントが開始されると、スプリントの優先順位は変更されません。スプリントは、以下の合意された機能とユーザーストーリーが特定の日付までに配信およびテストされるという、利害関係者と開発チーム間の合意であると想定されています。利害関係者は、開発の開始後にスプリントへの期待を変え始めたとき、合意の終了を支持しません。

したがって、利害関係者は彼らが求めていることを注意深く考えていなかったので、彼らは彼らの期待をすぐに変えるでしょう。開発者は、機能の配信日をプッシュする余裕がありますか？多くの場合、そうではありません。せいぜい利害関係者は過失または無能であり、開発者はとにかく日付を満たすために残業で代償を払います。時には、利害関係者でさえ、給与のある開発者からより多くの仕事を得ることができるとわざとこれを行うことがあります。

中心的な要件がスプリントの現在の作業が役に立たなくなるところまで変わったときに正直に起こるべきことは、新しいスプリントが新しい要件に基づいて計画できるようになるまで、スプリントの開発を直ちに停止することです。確かに、次の週に向けて継続する理由はありません。ビジネスがすでに彼らにまったく役に立たないであろうとあなたがすでに言っているソフトウェアを開発している半分。

実際に起こっていることは、ビジネスの利害関係者がスプリントのコミットメントを維持または満たしていないために開発チームに失敗していることです。彼らは、ソフトウェアに何を求めているかを決定する能力が完全に欠如しているか、または開発チームと品質の高いソフトウェアがどのように作成されているかを完全に尊重していないかのどちらかを示しています。

このようなビジネスグループがソフトウェア開発が実際に機能する方法を尊重する唯一の方法は、外部のコンサルタント会社またはソフトウェアベンダーを雇って、彼らのためにソフトウェアを開発し、スプリントで支払うことです。使用できないいくつかのスプリントに相当するスプリントでお金を失うと、利害関係者としてのコミットメントを維持することがいかに重要であるかについて理解を深め、機能と要件に細心の注意を払います。

特定のアジャイル用語に触れない限り、根本的な問題は、反復中のクライアントの責任に対する理解やコミットメントの欠如であるように見えます。イテレーションの場合、クライアントはイテレーションの終わりまで自分の考えを変えないことに同意します。

これにより、開発者は短期間の静止ターゲットになります。

要件が非常に不安定で、1日では生き残れない場合、プロジェクトには方法論をはるかに超える問題があります...その場合、プロジェクトの目標に戻り、提案された機能を再検討します。

開発のライフサイクルを意識しておらず、1つのスプリント内で要件が常に変更されているため、他のビジネスは役に立たないと思います。

企業が一般的に耳にするのは、予算に影響を与えるものです。絶えず変化する要件がばらばらに行われている場合、詳細な例を使用して議論を作成し、そのような変更がチームの効率にどのように影響し、重複する作業が発生し、会社の費用がかかるかを示します。一方、変更が必要であり、それが行われない場合は会社に損失をもたらす可能性がある場合は、単にそれを着用し、絶えず変化する要件に対処する方法を見つける必要がある場合があります。

しかしながら、あなたが提案したように物事が非常に高い速度で変化しているとき、それは以下の理由のためであるかもしれないというのが私の経験でした：

• 概念は実験的なものであり、その場合は、これらの変更をすべて、製品コードに直接実装するのではなく、急増したい場合があります。
• コンセプトは完全には分析されていません。これは、製品が実際には十分に検討されていないことを示しており、要件は、製品が考えられている間にコード化することです。
• 絶え間ない市場と競争圧力がひどい変化をもたらす
• すべての利害関係者が変更の必要性について自由にコミュニケーションする能力に関して、プロジェクトドライバー、マネージャー、および実装チームの間の貧弱な関係。
• タスクの優先順位付けが不十分であり、これは管理スタッフと実装スタッフの両方の責任である可能性があります。

プロジェクトの所有者は、基本的な概念を念頭に置いているため、製品がどのように機能するかを実際には知らないことがありますが、決心する前に、製品の動作を確認する必要があると感じています。これは、問題のドメインが十分に理解されていないか、ビジネス機能がソフトウェアベースのソリューションにどのように変換されるかについて本当に考えていないためです。このような場合、プロトタイピングは有益です。変更が表面的なものである場合は、モックオブジェクトを使用してGUIのプロトタイプを簡単に作成できます。または、アルゴリズムに基づいた変更をテストおよび調整する手段としてユニットテストを使用できます。ただし重要なのは、プロセスを比較的無駄なく、コストを抑えて維持するために、変更が可能な限り体系的に適用されるようにすることです。

これらの要件の変更を回避し、開発ライフサイクルについてビジネスを教育するプロセスを設定することを提案しました。

これは良い出発点であり、管理者と連携して、測定され構造化された方法で前向きな結果を生み出すための手段を提供します。教育は、開発者と管理者が思想的に同期していない問題に対処する最も効果的な方法です。ただし、最大の利益を得るためには、コミュニケーションと同様に、教育は双方向である必要があります。あなたは自分自身と経営陣にあなたのニーズを伝え、それらのニーズを推進する動機を理解するのを助け合うように教える必要があります。それが「難しすぎる」または「多くの仕事」または「時間の浪費」であると言うことは、不平を言って「怠惰」であることだけに遭遇します。あなたの推論は明確でなければなりません、そして、あなたが会社とあなたが取り組んでいる製品のためにポジティブな結果を達成するために取り組んでいること、そしてあなたの動機がこれらの最善の利益を念頭に置いていることを示す言語で。同様に、訴訟が迅速に物事を変える必要性を感じる理由について、訴訟が与える理由を受け入れることを学ぶ必要があるかもしれません。おそらくあなたとあなたの間に、双方がお互いの視点を理解することができるとき、あなたは良い実用的な中立を見つけることができるでしょう。

ビジネスがアイデアを得られない場合はどうなりますか？あなたならどうしますか？

期待した結果が得られない場合、おそらくタイミングが適切ではありません。おそらく、あなたの主張は異なる方法で行われる必要があります。おそらくあなたはそれをすべて間違っており、反対側が何を考えているかについてもっと学ぶ必要があるでしょう。最終的に特定のアプローチが失敗した場合、対処することがあなたにとってどれほど重要であるかを決めるのはあなた次第です。ただし、発生する可能性があることや発生しない可能性があることを心配するのではなく、前向きに考え、今日何ができるかを単純に決定してください。明日の問題は必ずしも保証されているわけではなく、実際に発生するまで心配するストレスの価値はありません。

考慮すべき最後のポイント。あなたのCTOは、あなたと同じ問題の多くを懸念している可能性があります。TDDを採用する命令があることは、コードが頻繁に変更される状況でTDDが非常に効果的であることを考えると、これは非常によく当てはまることを私に示唆しています。テストファーストのシナリオでは、セーフティネットが提供され、迅速かつ確実に変更を適用できるため、翌日テストが役に立たなくなることはありません。ただし、変更を効率的に管理するために、変更を要求する人々の期待を管理する方法を見つける必要があります。

より明確にするために、実際のサイズが500 kbを超える場合は、サイトで画像をアップロードし、500 kb未満にサイズ変更できる必要があります。

要件の変更は、この機能が不要である可能性があります（ほとんどの場合、ユーザーはそれを確認した後、実際には必要ないことに気付きました）。

これらの要件の変更を回避し、開発ライフサイクルについてビジネスを教育するプロセスを設定することを提案しました。ビジネスがアイデアを得られない場合はどうなりますか？

まず、ダミーのプロトタイピングをさらに行う必要があるようです。実際には実際のデータを保存または取得しないが、ソフトウェアがどのように動作するかをエミュレートする、機能するクリック可能なモックアップ。したがって、Webアプリケーションの場合、これは完全に行われたHTML / CSS / JavaScriptを意味し、コーディングはほとんど行われていなくても、ユーザーがソフトウェアをクリックすることができます。おそらくそれは、ユーザーがそれをコーディングする作業に投資する前に、何が求められているかをユーザーが理解するのに役立つでしょう。

次に、ビジネスの仕組みを決定するのはIT部門の責任ではありません。そして、ビジネスはそのソフトウェアのニーズに対する信頼性よりも機敏さを重視しているのかもしれません。したがって、今日変更されたものを取得することは、特定の機能が100％の時間動作することを保証するよりも価値があります。これを決定できるのはビジネス自体だけです。部門が品質の問題で非難されない限り、要件の変化とテスト駆動ではないコードでビジネスは完全に問題ないと考えるべきでしょう。あなたのCTO / CIOは、「テスト主導」になりたいと言っていますが、ビジネス要件が日常的に「この変更を午後4時までに行う」場合は、両方を使用することはできません。