coding-style - 権限のない責任は無意味です - 技術ベースのソリューションですか?

Question

私の父はいつも「権限のない責任は無意味だ」と言います。

ただし、開発者として、私たちは常に次のような状況に陥っています。

ソフトウェアに「バグがない」ことを確認する責任がありますが、バグ追跡システムを実装する権限はありません
プロジェクトの期限を守る責任がありますが、要件、品質、またはチームリソース (プロジェクト管理の 3 つの部分) に影響を与えることはできません。
等

もちろん、これを回避するためにあなたが言うことができることはたくさんあります - 新しい仕事を見つける、上司と戦うなど....

しかし、この問題に対する技術的な解決策はどうでしょうか? つまり、これらの問題のいくつかを修正するようにチームを説得する必要なしに、自分でどのようなコーディングを行うことができるか、または追跡されていないバグがあなたを傷つけている理由、締め切りに間に合わない理由を示すためにどのようなツールを使用できるかです。また、これらのツールを使用して、上司になることなく、より多くの「権限」を得るにはどうすればよいでしょうか?

***例 - 上司があなたのところに来て、「なんでこんなにバグが多いの!?!?」と言います。- 私たちのほとんどは、「追跡するための優れたシステムがありません!」と言うでしょうが、これは通常、私の経験では言い訳と見なされます。では、レポート (マネージャーはレポートが大好きです) を指して、「ほら、これが理由です」と言うことができたらどうでしょうか?

score 4 · Accepted Answer

あなたができることは最善を尽くすことです。成功するソフトウェアの鍵はあなたの手にある、チームの一員であるとは思わないでください。すべての責任を負う必要はありません。

明らかに、あなたはあなたのソフトウェアに悪影響を与える環境にいますが、彼のすべての振る舞いを変えることはできないので、あなたから始めて、あなた自身のバグ、期限、要件、品質、リソースを持ったチームとして働き始めることをお勧めします残りの混乱を気にしますが、あなたの仕事で最高になるようにしてください。

上司にあなたの計画を示し、進捗状況を報告する自主的なチームとして働き、必要なときにさらにリソースを求め、上司があなたに計画を与えるかどうかにかかわらず、あなたの計画がどのように影響を受けるかを示します。

ウィキペディアのPSPおよびTSPの記事で、これに関する詳細なアドバイスを見つけることができます。

上司に良い仕事を見せ、自分の締め切りに間に合った後、彼はきっとあなたをもっと信頼し、あなたのアイデアのいくつかをチーム全体に流します。

score 3 · Accepted Answer

簡単な答えは、自分でツールを使い始めることができるということです。

自分の仕事を改善します。コードの修正を求める人がいたら、バグを報告するよう伝えてください。方法を示します。何もインストールせずに実行できることを確認してください。彼らはステータスの更新を望んでいますか? バグをチェックするように伝えます。彼らはあなたが行ったコードの変更について尋ねますか? ソース管理履歴クエリの作成方法を示します。または、ボックスに表示するだけです。これが機能することを彼らに示し始めてください。

そして、彼らから同じ結果が必要な場合は、彼らに足を運ぶように要求してください. ソース管理で変更が見つからない場合は、バックアップテープから手動でリビジョンを比較するよう依頼してください。彼らの仕事、またはソース管理とバグ追跡の仕事を彼らのためにしないでください。

そして最も重要なことは、この仲間からのプレッシャーを適用するときは、親切にすることです。ハエと蜂蜜とすべて。

彼らがそれを理解していない場合、あなたは会社またはグループで唯一のプロの開発者であり続けることができます. または、少なくとも履歴書を埋めるのに役立ちます: 「製品の品質を向上させるために、CVS と FogBugs をセットアップして他の人に指示した経験」など。

score 3 · Accepted Answer

バグ追跡システムは必要ありません。自動化されたテスト (単体テストなど) が必要です。Makefile を使用して自動テストをセットアップできます。管理者によってブロックされているパスを常に見つけることができますが、それは仕事の制約内でできることがないという意味ではありません. もちろん、答えは「別の仕事を探す」かもしれません。今すぐ別の仕事を見つけることができない場合は、できるようにいくつかのスキルを学びましょう。

score 2 · Accepted Answer

追跡されていないバグがチームの品質コードを生成する能力に悪影響を与えていることを示すための特定のツールについては、バグの影響を示す前にバグを追跡するための何かが必要であるため、ここでキャッチ 22 を取得します。追跡できないものは測定できません。じゃあ何をすればいいの？

類似の例として、最近、電子メールによるコードレビューのやり方がばかげていると感じている男性がチームに加わりました。そこで、彼はオープンソースツールを見つけて自分のボックスにインストールし、オープンマインドなチームメンバー数人にしばらく試してもらい、チームリーダーにデモを行いました。数週間以内に、彼は私たちのすべてのチームにデモを行う機会を得ました。その新人は会社全体に影響を与えていた. このゲリラ的なツール採用の話はよく耳にします。

秘訣は、誰が決定を下す権限を持っているかを特定し、彼らが何を重視しているかを見つけ出し、実装したいものが彼らに価値を与えるという十分な証拠を収集することです.

組織の中間または底部からリードする方法についてのより広い視野については、John Maxwell のThe 360 Degree Leaderを参照してください。

score 1 · Accepted Answer

品質とそれが生産性に与える影響についてのレポートが必要な場合は、こちらが最適です：http: //itprojectguide.blogspot.com/2008/11/caper-jones-2008-software-quality.html Caper Jonesには、数冊の本があります。まだ会議に現れています。優れたIDE以外では、開発者/ ITグループはソースコード管理（VSS、SubVersionなど）と問題追跡を必要とします

score 1 · Accepted Answer

会計士が、複式簿記を使用せずに残高を計算せずに一連の勘定科目を作成するように求められた場合、会計士がそうするとは誰も期待しません。

しかし、複式簿記は 13 世紀頃から会計士によって標準的に使用されてきました。

専門家としての私たちが、オンワンがそれらなしで機能するほど根付いた標準的な慣行を身につけるまでには、長い時間がかかります。

ですから、申し訳ありませんが、この種の問題に今後何年も直面する必要があると思います。

score 0 · Accepted Answer

質問に直接答えなくて申し訳ありませんが...

あなたが言及している失敗はコミュニケーションの 1 つであることを強く感じます。職場環境とプロセスを改善するために必要な権限を活用するのに十分なほど尊敬され、信頼されるようになるまで、コミュニケーションスキルを開発することが専門家としての私たちの義務です。あなたが提案する方法。

つまり、職場でのコミュニケーション不足によって生じるすべての問題を解決できる技術的な解決策はないと思います。

どちらかといえば、テクノロジーは直接対面するコミュニケーションの減少を引き起こしました。

申し訳ありませんが、私はまた接線を離れています - お気軽に downmod してください。

score 0 · Accepted Answer

コーディングのみを行うと、自分のソースファイルを整理し、コメントを付け、テストでバグ数を少なくすることしかできません。しかし、進行状況とバグを追跡するための外部ツール (bugzilla、yoxel、trac、ガントダイアグラムツール、Mylyn for Eclipse、ブログなど) が必要になります。このような場合、人、規律、良い習慣、リーダーシップが圧倒的な力を発揮します。ソフトウェアツールや個人からのオファーだけでは勝てません。

coding-style - 権限のない責任は無意味です - 技術ベースのソリューションですか?

8 に答える 8

Related

Reference