アカウント名:
パスワード:
私自身の経験としては、デスマーチはありますが、恐怖を感じたことは皆無です。
そもそも恐怖 って何?、職場に恐怖なんてあるの?と思って、逆の概念として"信頼"ってのを考えてみました。信頼駆動開発です。
1) 組織的な信頼: 開発者はミスやビルドの破損、バグを生み出すことを恐れていない。なぜなら、組織は書類の作成にも注力しており、信頼できる仕様・テストケースがあり、開発者は各自安心してコードが書ける。
2) コード変更に対する信頼: 既存のコードを変更すること生じうる、予期しない副作用・バグが復活は簡単に検出・修正できる。開発者はストレスとは無縁である。なぜなら、コードベースが古かったり、実装がよく理解できていなくても、信頼できる仕様書・テストケースがあるため、副作用やバグは自動で検出でき、すぐに修正できるからである。
3)組織への信頼: 組織は契約に基づいた労働しか求めない。開発者がまともに動作しないコードをチェックインしても、それはユニット単位でのテストで検知でき、マネージャはユニット単位で修正を指示するだけ。コードを書く人、テストする人、修正する人、マネージャ、各自割り当てられた業務を粛々とこなすだけである。
こうやってみると、- 同僚やチーム全体を信用も信頼もできない- 自身にも彼らと上手く連携して仕事を進めるためのスキル(コードの質とか、テストや仕様書の作成能力、改善の提案能力)がない場合、その開発者は恐怖駆動に陥ると言えるかも知れません。
心理学的には、恐怖とは人間の防衛機制から生じるものです。ここからは意地悪な解釈ですが、恐怖駆動とは自分のスキルを超えた、自分ではコントロールできない状況(つまりデスマーチ)に陥った不幸な人が本能的に「自分は悪くない、同僚やチームが悪い(=信用できない)」と自己に言い聞かせて、現実逃避した結果であるようにも思います。
とにかく、私は良い職場に恵まれたようです :-)
「お前バカだろ」とか「愚かしい」みたいなモデレートが欲しくなるな
1,2の理由に書いてある「信頼できる仕様・テストケースがあり」と、3の「粛々とこなすだけ」ができるのも「信頼できる仕様・テストケースがあり」ということだろうから、なんだかんだ言っても
「信頼できる仕様・テストケースがあり」
という一点がクリアされれば、何とでもいえるってことかな。
ネタでも本気でも少し休んだ方がいいと思うよ。
> 私自身の経験としては、デスマーチはありますが、恐怖を感じたことは皆無です。
顧客にとってブラックな会社のように思います。
> 1)組織的な信頼: 開発者はミスやビルドの破損、バグを生み出すことを恐れていない。
恐れろよ。ミスやバグで人が死ぬことだってある。直接的、間接的に。
> 2)コード変更に対する信頼: 既存のコードを変更すること生じうる、> 予期しない副作用・バグが復活は簡単に検出・修正できる。> 開発者はストレスとは無縁である。
予期しないバグってのは、直すのが大変なんだよな~。
> 信頼できる仕様書・テストケースがあるため、副作用やバグは自動で検出でき、すぐに修正できるからである。
信頼できる仕様書がある開発プロジェクトなんて、日本にあるのかしら。
> 3)組織への信頼: 組織は契約に基づいた労働しか求めない。
そんなパラダイスな会社が存在するといいね。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
ナニゲにアレゲなのは、ナニゲなアレゲ -- アレゲ研究家
信頼駆動開発 (スコア:0)
私自身の経験としては、デスマーチはありますが、恐怖を感じたことは皆無です。
そもそも恐怖 って何?、職場に恐怖なんてあるの?と思って、逆の概念として"信頼"ってのを考えてみました。信頼駆動開発です。
1) 組織的な信頼: 開発者はミスやビルドの破損、バグを生み出すことを恐れていない。
なぜなら、組織は書類の作成にも注力しており、信頼できる仕様・テストケースがあり、開発者は各自安心してコードが書ける。
2) コード変更に対する信頼: 既存のコードを変更すること生じうる、予期しない副作用・バグが復活は簡単に検出・修正できる。
開発者はストレスとは無縁である。
なぜなら、コードベースが古かったり、実装がよく理解できていなくても、
信頼できる仕様書・テストケースがあるため、副作用やバグは自動で検出でき、すぐに修正できるからである。
3)組織への信頼: 組織は契約に基づいた労働しか求めない。
開発者がまともに動作しないコードをチェックインしても、それはユニット単位でのテストで検知でき、
マネージャはユニット単位で修正を指示するだけ。
コードを書く人、テストする人、修正する人、マネージャ、各自割り当てられた業務を粛々とこなすだけである。
こうやってみると、
- 同僚やチーム全体を信用も信頼もできない
- 自身にも彼らと上手く連携して仕事を進めるためのスキル(コードの質とか、テストや仕様書の作成能力、改善の提案能力)がない
場合、その開発者は恐怖駆動に陥ると言えるかも知れません。
心理学的には、恐怖とは人間の防衛機制から生じるものです。
ここからは意地悪な解釈ですが、恐怖駆動とは
自分のスキルを超えた、自分ではコントロールできない状況(つまりデスマーチ)に陥った不幸な人が
本能的に「自分は悪くない、同僚やチームが悪い(=信用できない)」と自己に言い聞かせて、現実逃避した結果であるようにも思います。
とにかく、私は良い職場に恵まれたようです :-)
Re:信頼駆動開発 (スコア:1)
「お前バカだろ」とか「愚かしい」みたいなモデレートが欲しくなるな
Re:信頼駆動開発 (スコア:1)
1,2の理由に書いてある「信頼できる仕様・テストケースがあり」と、
3の「粛々とこなすだけ」ができるのも「信頼できる仕様・テストケースがあり」
ということだろうから、なんだかんだ言っても
「信頼できる仕様・テストケースがあり」
という一点がクリアされれば、何とでもいえるってことかな。
Re: (スコア:0)
ネタでも本気でも少し休んだ方がいいと思うよ。
Re: (スコア:0)
> 私自身の経験としては、デスマーチはありますが、恐怖を感じたことは皆無です。
顧客にとってブラックな会社のように思います。
> 1)組織的な信頼: 開発者はミスやビルドの破損、バグを生み出すことを恐れていない。
恐れろよ。
ミスやバグで人が死ぬことだってある。
直接的、間接的に。
> 2)コード変更に対する信頼: 既存のコードを変更すること生じうる、
> 予期しない副作用・バグが復活は簡単に検出・修正できる。
> 開発者はストレスとは無縁である。
予期しないバグってのは、直すのが大変なんだよな~。
> 信頼できる仕様書・テストケースがあるため、副作用やバグは自動で検出でき、すぐに修正できるからである。
信頼できる仕様書がある開発プロジェクトなんて、日本にあるのかしら。
> 3)組織への信頼: 組織は契約に基づいた労働しか求めない。
そんなパラダイスな会社が存在するといいね。