“特集リクエスト！!!”
私たちのソフトウェアエンジニアは、顧客の問題の緊急性を軽視するために使用することが多い戦いの叫びです。 結局のところ、私たちが直面している終わることのないバグログを注視するときに、新しい機能を追加する時間はありません。
米国のソフトウェアエンジニアにとって、バグと機能要求の違いは明確です。 バグとは、コードが実際にどのように動作しているかと、コードがどのように動作するように意図されていたかの間の不一致です。 機能要求では、現在のコードベースでは処理できないケースを満たすために新しいコードが必要です。
このような思考プロセスは、常にDoneDoneのようなソフトウェアをどのように使用すべきかというより一般的な問題につながります。 組織では、ある種類のソフトウェアを使用してバグをログに記録し、別の種類のソフトウェアを使用して今後のタスクを管理し、さらに別の種類のソ
私たちは、クライアントや顧客によって記録された問題を取捨選択し、問題を”バグ”バケットまたは”機能要求”バケットにスローするかどうかを判断しようとするために、多くの精神的なエネルギーを費やしています。 コンサルティング業務では、ソフトウェアがどのように動作するべきかについて事前に定義された合意を得て作業しているとき、これは理にか 機能のリクエストには追加料金が必要な場合があります。
しかし、良いソフトウェアを構築する純粋な練習だけになると、特に私たちが自分の製品に取り組んでいる場合、このように問題を分類することにど
私たちは、専門性（と技術）が問題を修正する邪魔になるようにしました。
Robert Martin(A.k.a.Uncle Bob)はソフトウェアについて多くのことを話しています。 彼は、ウェブは単なる配信メカニズムであり、それ以上のものではないと考えています。 これはエンドユーザーエクスペリエンスではなく、ソフトウェアの目的ではありません。 それは単に小さな小さな愚かな詳細です。 しかし、プログラマがプログラムするとき、アプリケーションのアーキテクチャは、Webアプリケーションであるという事実に完全に影響されます。
同じように、”完了する必要があるもの”に使用する用語をダムの詳細と考えた場合はどうなりますか？
その”事”を記録している人の観点から、彼女がバグを発見するのではなく、新しい機能を要求していることは本当に重要ですか？ 彼女はちょうど彼女の問題が別の人間によって解決され、好ましくは、彼女の問題がいつ解決されるかを知ることを望んでいます。
ソフトウェアの世界を離れると、より明らかに専門性を見ることができるかもしれません。 配管工が漏れやすいシャワーを修理するために来るとき、私はあなたが細部を気にしないと想像します。 シャワーヘッドが誤ってインストールされていた場合（バグ）またはガスケットが壊れている場合（バグ）またはテフロンテープが安価なパイプ（機能）から欠落していた場合、あなたが気にするのは、それが修正するのにかかる時間とどのくらいの料金がかかりますかです。
バグやリクエスト？ それは両方です。 そして、それは問題ではありません。
先週、中小企業のための人事ソフトウェアツール”Kin”をリリースしました。 Kinでは、各従業員のオフリクエストを簡単に追跡できます。 Kinが今していないことの一つは、週末と休日を仕事の日と区別することです。 あなたは感謝祭の間に完全な週を離陸したいのであれば、あなたは手動であなたがオフに要求している時間の量を入力する必要があります。
チームはすでにKinにこの追跡を自動的に行うように要求をいくつか受けています。 実際には、それはリリースキューにあります。 しかし、それがログインしている場所にログインしているとき、Kinチームはそれをバグ、機能要求、タスク、またはto-doとみなすべきですか？
私の内側の叔父ボブを呼び出すと、私の答えは簡単です：それはあなたが要求をどのように分類するかは関係ありません。 それはただの愚かな詳細です。
それは私たちがそれを全く分類すべきではないと言うことではありません。 Kinチームは、”機能要求”の下に問題をタグ付けし、最初に（承認の問題を持つユーザーのように）より重要な問題を修正することに取り組むかもしれません。 それは罰金とダンディ、そして有効なアプローチです。
しかし、すべてのthings-we-call-feature-requestsがすべてのthings-we-call-bugsよりも緊急性が低いと自動的に仮定するのは間違いです。 それは、問題をどのように分類するかのかなり小さな詳細を、私たちがそれを解決するときの目玉にしています。 そうすべきではありません。 一日の終わりには、これらの要求のすべては、単に解決が必要なものです。
専門性をダムの詳細とする
そのためには、これらの要求すべてに与えるラベルはほとんど重要ではありません。 もっと重要なのは、誰かが彼らに出席しており、これらの要求がいつ対処されるかについての一般的な考えがあるということです。 さらに重要なのは、アイテムAとアイテムBがどのようなタイプのものであっても、アイテムAはより価値のあるものです。 それだけです。 それ以上は何もない
だから、次回はタスク、バグ、機能要求、およびto-doの分類に時間を費やしすぎているときは、専門的なことを忘れてください。 彼らはただの愚かな詳細です。
30秒でDoneDoneアカウントにサインアップします。 Ka Wai Cheungによって続きを読みたいですか？ 現代のプログラマに関するKa Waiの新しい本、開発者のコードは、電子ブックと印刷で利用可能です。 あなたはTwitter@developerscodeで彼に従うことができます。