以前はテスターでした。 当時はプログラマーにときどき非常に不満だったことを覚えています。
これらの永遠の疑わしい議論は、「これはバグではなく、これは機能です」または「これがバグであれば、それは取るに足らない、そのままにしておきます。」
しかし、システムがステークで上昇した場合、それはどのように留まりますか？
それからプログラマーになりました。 そして、すべてが変わりました-私はこれらの修正のための無限のリターンをひどく怒り始めました：
彼らはそれを好まない、それはここでは機能しない！ はい、一般的にこのウィンドウに読み取り不能な文字を呼び出して挿入するためのコンテキストメニューがありました！？ 彼らはどのようにそれを考えましたか！？ でたらめ、戦闘モードではユーザーはそれをしません！
私は支配しません、そのままにしておきます！
一般的に、古典はプログラマーとテスターの敵意です。
そして、私はマネージャーになりました。 そして、私はこの敵意が共通の原因にとって致命的であることに気づきました。 幸いなことに、私は自分がプログラマーでありテスターであることをよく覚えていたので、問題の本質を理解し、状況を変えることができました。
プロセス
当時、非常にシンプルで理解しやすい開発プロセスがありました。
タスク->プログラミング<->テスト->リリースさらに
- テスターは、テストへの移行時にのみタスクについて学習します。 新しいタスクの開発の開始に関する通知は受け取りません。
- プログラマーはテストタスクの完了を待たずに、すぐに新しいタスクを開始します。
さて、これは完璧なカプセル化の例です！
プログラマーで
- エントリー時：新しいタスクとテストからの戻り。
- exit：タスクをテストに転送します。
テスターで
- 入力：プログラマーからのタスク。
- exit：タスクをプログラマに返し、バージョンの公式リリースを返します。
実際には、プロセス自体は悪くありません-誰もが自分の世界に住んでいて、好きなことをします。
目的
しかし、このプロセスには非常に具体的な最終目標があります。つまり、必要な機能を時間通りに備えた高品質のソフトウェアを作成することです。
実際、この瞬間に問題が始まります。
問題
マネージャーが到着し、最終的な目標について思い出し始めると。
典型的な状況：
マネージャーはプログラマーのところに来て、「いつ？」と尋ねます。そして、彼らは「わからない、すべてをやった、テスターに尋ねる」と答えます。
マネージャーは、「いつ？」という同じ質問でテスターに行きます。そして、彼らは彼に答えます。プログラマーと。」
そして、マネージャーは前後に円を描き始めますが、リリースはありません。
その結果、マネージャーの忍耐は終わり、プログラマーとテスターを結び付けて、何らかの形で問題を解決しようとします。 実際、すべての決定は、プログラマーとテスター間の相互作用に関するルールの開発に帰着します。 そして、マネージャーのさらなる努力はすべて、これらの規則の遵守を監視することを目的としています。
以下は、マネージャーの数ヶ月の疲れた仕事の後、私たちの部門で形成されたいくつかのルールです。
- 共同計画 。 バージョンは事前に計画されています。 計画には、プログラマーとテスターが参加します。 これにより、誰もが何をすべきかを前もって知っています。 たとえば、これにより、テスターは事前にテスト計画の作成を開始し、必要なテスト環境を準備できます。
- ブランチの開発 。 開発者は、すでに注がれているすべてのタスクがテストされるまで、メインブランチに新しいタスクを挿入しません。 これにより、「雪玉」が回避されます。つまり、 メインブランチでの多数の半分完了したタスクの蓄積の影響。 また、プログラマーがいじくり回すことも防ぎます-ブランチでいつでも次のタスクを実行できます。
- 小型バージョン 。 これは、ブランチの開発を削減する試みです。これは、マージ、コードの更新、および再テストのオーバーヘッドであるためです。 小さなバージョンを作成する場合は、すぐにメインブランチで作業できます。
- 何もしません 。 ブランチ開発を減らす別の試み。 多くのタスクがブランチに蓄積され、テストがテストよりもはるかに進んでいる場合、プログラマーは何もせずに実行できるようになります。
- 早期通知 。 たとえば、テスターはタスクのテストを開始しました。 タスクは大きいですが、彼はすぐに欠陥を見つけました。 彼は、すべてのテストが完了した最後ではなく、発見時に直ちにこれをプログラマに報告します。 またはその逆に、プログラマーは、開発中であっても、実装の微妙な違いについてテスターに通知し、事前にテスト計画を準備します。 この種のことにより、プログラマーとテスターの作業を並列化できます。
これらのルールはすべて状況を改善するのに実際には役立ちましたが、根本的には変わりませんでした。 彼らは1つの小さな穴に差し込むように見えました。 他の解決策があり、何かが見落とされていると感じました。
たとえば、マネージャーがリラックスするとすぐに-すぐにプログラマとテスターの間のすべての合意が忘れられ、すべてが元の状態に戻りました。
さらに、プログラマーとテスターの関係は改善されませんでした-敵意があったため、そのままでした。
気づき
何が起きているのか、人々の行動、感情、ニーズ、動機について多くのことを考えたとき、さらに多くの日と夜が過ぎました。
そして、突然すべてが明らかになりました！
しかし、そのようなアプローチのまさに構造は、「あるプログラム-他のプログラムがテストする」とき、プログラマーとテスターの間に対立が生じます。
そして、この対立の全体的なポイントは、彼ら
が異なる目標を
持っているということです！
テスターの目標は「テスト」です。
開発者には「開発」という目標があります。 「テストに合格。」
そして、目標はマネージャーのみと「リリースをリリース」することです。 そして、彼がそれに努力を注ぐ間だけ-それは達成されます。
そして、人々が異なる目標を持っているとき-彼らは途中ではない、彼らはお互いに興味がありません。 彼らは引きつけられないので、彼らはまだ異なる方向で、彼ら自身の道を行くでしょう。
解決策
実際、問題の解決策は、プログラマーとテスターの両方に共通の目標を設定することです。
さらに、目標は明らかです-品質のリリースを時間通りにリリースします。
実際、この目標に到達しないと、「開発」と「テスト」というローカルの目標はすべての意味を失います。
一部の人々にとってお金は目標であるが、誰かにとっては手段であるという有名な言葉のようなものです。
つまり プログラミングとテストは楽しいものではありますが、手段です-それはさらに良いことですが、それでも手段です。 そして、目標はリリースです。
明らかに、目標の変更は容易ではありませんでした。 しかし、私は自分の思考の論理に完全に染み込んでいたので、変化に対する抵抗を打破する準備ができていました！
ここで行われた主なことは次のとおりです。
- 部門の組織構造を変更しました。 開発部門とテスト部門の代わりに、プログラマーとテスターの両方が集まったチームが形成されました。
- 移転 。 新たに形成されたチームは、別の部屋を受け取りました。 現在、テスターとプログラマーが別々の部屋に座って自分の生活をしている状況はありませんでした。
- 宣伝 。 当然、再編成を始めた理由と理由について、多くの激しいスピーチをしなければなりませんでした。 そして、主なことは、皆に共通の目標を伝えることです。そのため、私たちは皆ここに集まりました。 人々はすべて読み書き可能であり、アイデアは論理的であるため、プロパガンダは簡単で成功していることが判明しました。
- 解雇 。 悲しいかな、誰かが新しいアイデアに反対しました。 しかし、それは良いことです。彼らは今、はるかに良いことをしている人々に道を譲りました！
そして、これらすべての努力は価値がありました！ 効果は素晴らしかったです！
- プログラマーとテスターの間の緊張は、あたかもそうでなかったかのように、消えました。
- 相互サポートが登場し、製品が改善されました。
- プログラマーはテスターを支援し始め、ボトルネックを指摘し、さらに確認する必要があります。
- 検出された欠陥に対する一般的な態度が変わりました。 誰もが罪を犯したとは考えません。 それどころか、開発者はテスターに感謝し、製品の改善に貢献しました！
- プログラマーとテスターの相互作用に関するすべての合意は、誰もが彼らの有効性を理解しているため、自分で実装し始めました。
- 一般的に、すべてが時計のように機能しました-定期的なリリース、高品質の製品。
私たちの目の前で、約6か月間、真の変化が起こりました！
おわりに
競合には常に真の理由があります。 プログラマーとテスターの間の典型的な対立では、本当の理由は異なる目標です。 彼らの前に一つの共通の目標を設定する価値があります-そして、すべてがすぐに変わります！ プログラマーとテスターは親友になり、常に助け合い、プログラマー、テスター、マネージャー、製品、会社など、誰もがその恩恵を受けます！