アカウント名:
パスワード:
言ってることは大体合ってるけど、想定環境が違う。そして
TDDには自動テストが必須
と言ってるようにTDDを行うためには自動テスト環境が実現済みであるはずなので、自動テストを達成するためにTDDが足を引っ張る云々は間違い。達成済みなので。
TDDの解説で開発者がテストファーストをしているのは、あくまで勉強のため。実際には仕様策定する立場の人やその直属がテストを作成する。で仕様変更が入ったらテストを修正し、開発者はその差分やコメントを見てプログラムを修正するわけだ。
自分が何で「自動テストが目的」と言ったかというと、 ★自動テストが出来る時は、開発が終わる時 で有る位、作るのが大変だと見積もったからです。 確かに、テストを予め作ってくれる「仕様策定する立場の人やその直属」が居れば、大丈夫です。居ればですが。 最近の手法は、アジャイルとかもそうですが、 ★(無限の注意力を持った)『自分では無い』超人 を前提にしている事が多いですが、もし超人を望むなら、自分を貧乏にして高い費用を捻出する助けをしないといけないと思います。 もしそうで無いなら、せめて自動テスト作成準備の、予備的手動テスト位は手伝わないと、お金がもらえなくなると思います。 ★自動テストが出来る時は、開発が終わる時 だからです。
ちょっと違う。アジャイルもTDDも、最近の手法は常に開発を行い常に修正を続けていくことが前提です。だから昔からの人にとっては終わらない開発に見えますが、最近の手法に慣れた人にとっては常に終わり続けている開発なのです。
無限の注意力を持った超人はいません。ではどうするか。気付いたときに修正すればすむように、契約や開発運用体制を整えるのです。
最近の手法というのは極端な話、開発者にスキルを求めず誰でも開発に参加できるようにすることが目的です。それはOSSで参加の窓口を広くするためだったり、ブラック開発で人材の入れ替わりが激しかったりするためだったりなのですが。ですから、テストの成果物なども本来上流が管理するべきです。dotkuwaさんはどちらかというと下流の開発から見ているようなので、そのあたりで齟齬が起きているのではないでしょうか。現実的ではあるかもしれませんが、開発が属人的なものになっていきいつまでも開発に負担がのしかかるような気がします。
追記。
自分が設計に関与している訳でも無いプロジェクトで、勝手にやるのは単なるサボタージュ行為です。(これはファクトだと思います。)
なので、TDDを導入するのは上流の立場の人です。そしてTDDはテストファーストなので、テストが書けないなら仕様の変更は受け入れられません。だから
確かに、テストを予め作ってくれる「仕様策定する立場の人やその直属」が居れば、大丈夫です。居ればですが。
いないのならばそれはマネージャーの責任であり営業の責任であり発注者の責任です。最近の手法というのは、逆に彼らに知識やスキルが無いことを許しません。プログラム言語といった専門的な知識は必要ありませんが、抽象化された知識やそのシステムの対象領域となる知識を求められます。そして、下流との共通言語で説明できるようになるまで話が煮詰まっていないのならば流してはいけないのです。
たしかに下流の知識しかないのですが、 >彼らに知識やスキルが無いことを許しません。ですが、その様な人間が頑張って自動テストが出来る様になった後にやって来て、その部分だけ担当するというのは、彼ら・彼女らの米びつに手を突っ込む行為では無いでしょうか? 自分の携わった開発は、自動テストは作りませんでしたが、出来立ての、見通しの良いシステムの改修は、まさに作った時の人達がグリップするのが当然の様に見えました。そのグリップしている上流の人間が、彼ら・彼女らの部下や関係者にその見通しの良い、一そろいそろったシステムの改修という滋味に満ち溢れた学びをさせる事は、彼ら・彼女らの本懐だったと思います。 たしかに下流の知識しかないのですが、 その様な事情が、昔と今で変わるとも思えないのですが、どうでしょうか?
下流の知識しかないというよりは、下流にいるのに上流の仕事も行えてしまうのが問題なわけで。
その米びつが彼・彼女のものという感覚が困る。その米びつは、所属会社のものだったり発注会社のものだったりです。会社も飯を食べないといけないので。
いままでナアナアになっていた負担を、会社が負担し代わりに報酬を出す。米びつが壊れても責任は問わない。
その仕組みは発注側の自衛のため(開発会社や運営会社がなくなっても事業継続できる)だったり開発会社の自衛のため(プログラマーの属人化を防ぐ)だったりプログラマーの自衛のため(訳の分からない仕事を断る)だったりします。
規模が小さく会社や社員ががっちりと結びついていた時代は良かったのですが、規模が大きくなって会社が入り交じったり社員の入れ替わりが激しくなってくると、従来の仕組みはうまくいかなくなりました。それこそ「他人の米びつに手を突っ込む」ような状態になってしまうので。
上流か、下流かは、確かにプログラムを書くか書かせるかも有りますが、もっと大きく「オーナーシップを持っているか否か」だとおもいます。 下流の(自分も含めた)人間は、自分の仕事を「人ごとに過ぎない」とか、「人の見てる夢だ」とかでも思っていなければやってらんないですが、 上流の人のオーナーシップは(少なくともそれに関しては)本物で、何としてもやり切ろうという気構えと、先への期待がないまぜだと思います。 ご指摘の新しいやり方(「彼・彼女のものという感覚が困る」)だと、上流の人からもオーナーシップを取り上げる作用になると思いますが、 ・(それでもオーナーシップは誰かが担わなければならない為)誰が オーナーシップを担うのでしょうか?・それはより良い事なのでしょうか? 疑問です。
(それでもオーナーシップは誰かが担わなければならない為)誰がオーナーシップを担うのでしょうか?
先にも挙げましたが、会社(歴代の経営層あるいは部門トップ)です。システムを開発した会社かもしれませんし、システムを発注した会社かもしれません。個人に帰属させたいなら個人事業者になって受託してください。
それはより良い事なのでしょうか?
会社にとっては良いこと(継続が法人になるため)です。個人にとっては一長一短です。自分の仕事という意識が薄くなる代わりに、手離れの良いシステムとなるので。何か修正依頼があるたびに直接個人に依頼がくるのは嬉しくもあり面倒でもある。で、会社は開発体制をそのような方向に持っていくために、別の何かを報酬とするわけです。給料だったり福利厚生だったり。
それはおかしいですよ。 プログラマー(後の下流側)にオーナーシップ(当事者意識、自分ごと化)を丸ごと持たせると、間違いなく舞い上がってしまうので、上流側と下流側に分けて、互いにけん制する様にし、下流側はプログラミングを得、上流側がオーナーシップを受け持った訳で、 テストドリブンにしたいだけの為に、さらにオーナーシップを別の人間に渡す必要は無いと思います。上流側は(ピペドならぬ)エクドやワードなので、舞い上がり様が無いからです。もちろんテストドリブンが絶対的な善なら、有り得ますが、どうひいき目に見ても一得一失にしか見えません。 オーナーシップは金銭でも地位でもなく、やり遂げる事が出来る能力なので、会社(歴代の経営層あるいは部門トップ)に渡して何になるのか、さっぱり分かりません。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
長期的な見通しやビジョンはあえて持たないようにしてる -- Linus Torvalds
テストは仕様書兼指示書 (スコア:0)
言ってることは大体合ってるけど、想定環境が違う。
そして
TDDには自動テストが必須
と言ってるようにTDDを行うためには自動テスト環境が実現済みであるはずなので、
自動テストを達成するためにTDDが足を引っ張る云々は間違い。達成済みなので。
TDDの解説で開発者がテストファーストをしているのは、あくまで勉強のため。
実際には仕様策定する立場の人やその直属がテストを作成する。
で仕様変更が入ったらテストを修正し、開発者はその差分やコメントを見てプログラムを修正するわけだ。
Re: (スコア:1)
自分が何で「自動テストが目的」と言ったかというと、
★自動テストが出来る時は、開発が終わる時
で有る位、作るのが大変だと見積もったからです。
確かに、テストを予め作ってくれる「仕様策定する立場の人やその直属」
が居れば、大丈夫です。
居ればですが。
最近の手法は、アジャイルとかもそうですが、
★(無限の注意力を持った)『自分では無い』超人
を前提にしている事が多いですが、もし超人を望むなら、自分を貧乏にして
高い費用を捻出する助けをしないといけないと思います。
もしそうで無いなら、せめて自動テスト作成準備の、予備的手動テスト位は
手伝わないと、お金がもらえなくなると思います。
★自動テストが出来る時は、開発が終わる時
だからです。
Re: (スコア:0)
ちょっと違う。
アジャイルもTDDも、最近の手法は常に開発を行い常に修正を続けていくことが前提です。
だから昔からの人にとっては終わらない開発に見えますが、最近の手法に慣れた人にとっては常に終わり続けている開発なのです。
無限の注意力を持った超人はいません。
ではどうするか。気付いたときに修正すればすむように、契約や開発運用体制を整えるのです。
最近の手法というのは極端な話、開発者にスキルを求めず誰でも開発に参加できるようにすることが目的です。
それはOSSで参加の窓口を広くするためだったり、ブラック開発で人材の入れ替わりが激しかったりするためだったりなのですが。
ですから、テストの成果物なども本来上流が管理するべきです。
dotkuwaさんはどちらかというと下流の開発から見ているようなので、そのあたりで齟齬が起きているのではないでしょうか。
現実的ではあるかもしれませんが、開発が属人的なものになっていきいつまでも開発に負担がのしかかるような気がします。
Re: (スコア:0)
追記。
自分が設計に関与している訳でも無いプロジェクトで、勝手にやるのは単なるサボタージュ行為です。
(これはファクトだと思います。)
なので、TDDを導入するのは上流の立場の人です。
そしてTDDはテストファーストなので、テストが書けないなら仕様の変更は受け入れられません。
だから
確かに、テストを予め作ってくれる「仕様策定する立場の人やその直属」
が居れば、大丈夫です。
居ればですが。
いないのならばそれはマネージャーの責任であり営業の責任であり発注者の責任です。
最近の手法というのは、逆に彼らに知識やスキルが無いことを許しません。
プログラム言語といった専門的な知識は必要ありませんが、抽象化された知識やそのシステムの対象領域となる知識を求められます。
そして、下流との共通言語で説明できるようになるまで話が煮詰まっていないのならば流してはいけないのです。
Re: (スコア:1)
たしかに下流の知識しかないのですが、
>彼らに知識やスキルが無いことを許しません。
ですが、その様な人間が頑張って自動テストが出来る様になった
後にやって来て、その部分だけ担当するというのは、
彼ら・彼女らの米びつに手を突っ込む行為では無いでしょうか?
自分の携わった開発は、自動テストは作りませんでしたが、
出来立ての、見通しの良いシステムの改修は、
まさに作った時の人達がグリップするのが当然の様に
見えました。
そのグリップしている上流の人間が、彼ら・彼女らの部下や関係者に
その見通しの良い、一そろいそろったシステムの改修という
滋味に満ち溢れた学びをさせる事は、彼ら・彼女らの本懐だったと
思います。
たしかに下流の知識しかないのですが、
その様な事情が、昔と今で変わるとも思えないのですが、
どうでしょうか?
Re: (スコア:0)
下流の知識しかないというよりは、下流にいるのに上流の仕事も行えてしまうのが問題なわけで。
その米びつが彼・彼女のものという感覚が困る。
その米びつは、所属会社のものだったり発注会社のものだったりです。
会社も飯を食べないといけないので。
いままでナアナアになっていた負担を、会社が負担し代わりに報酬を出す。
米びつが壊れても責任は問わない。
その仕組みは発注側の自衛のため(開発会社や運営会社がなくなっても事業継続できる)だったり
開発会社の自衛のため(プログラマーの属人化を防ぐ)だったり
プログラマーの自衛のため(訳の分からない仕事を断る)だったりします。
規模が小さく会社や社員ががっちりと結びついていた時代は良かったのですが、
規模が大きくなって会社が入り交じったり社員の入れ替わりが激しくなってくると、
従来の仕組みはうまくいかなくなりました。
それこそ「他人の米びつに手を突っ込む」ような状態になってしまうので。
Re: (スコア:1)
上流か、下流かは、確かにプログラムを書くか書かせるかも有りますが、
もっと大きく「オーナーシップを持っているか否か」だとおもいます。
下流の(自分も含めた)人間は、自分の仕事を「人ごとに過ぎない」とか、
「人の見てる夢だ」とかでも思っていなければやってらんないですが、
上流の人のオーナーシップは(少なくともそれに関しては)本物で、
何としてもやり切ろうという気構えと、先への期待がないまぜだと思います。
ご指摘の新しいやり方(「彼・彼女のものという感覚が困る」)だと、
上流の人からもオーナーシップを取り上げる作用になると思いますが、
・(それでもオーナーシップは誰かが担わなければならない為)誰が
オーナーシップを担うのでしょうか?
・それはより良い事なのでしょうか?
疑問です。
Re: (スコア:0)
(それでもオーナーシップは誰かが担わなければならない為)誰がオーナーシップを担うのでしょうか?
先にも挙げましたが、会社(歴代の経営層あるいは部門トップ)です。
システムを開発した会社かもしれませんし、システムを発注した会社かもしれません。
個人に帰属させたいなら個人事業者になって受託してください。
それはより良い事なのでしょうか?
会社にとっては良いこと(継続が法人になるため)です。
個人にとっては一長一短です。自分の仕事という意識が薄くなる代わりに、手離れの良いシステムとなるので。
何か修正依頼があるたびに直接個人に依頼がくるのは嬉しくもあり面倒でもある。
で、会社は開発体制をそのような方向に持っていくために、別の何かを報酬とするわけです。
給料だったり福利厚生だったり。
Re:テストは仕様書兼指示書 (スコア:1)
それはおかしいですよ。
プログラマー(後の下流側)にオーナーシップ(当事者意識、自分ごと化)
を丸ごと持たせると、間違いなく舞い上がってしまうので、
上流側と下流側に分けて、互いにけん制する様にし、
下流側はプログラミングを得、上流側がオーナーシップを受け持った訳で、
テストドリブンにしたいだけの為に、さらにオーナーシップを別の人間に
渡す必要は無いと思います。上流側は(ピペドならぬ)エクドやワードなので、
舞い上がり様が無いからです。
もちろんテストドリブンが絶対的な善なら、有り得ますが、
どうひいき目に見ても一得一失にしか見えません。
オーナーシップは金銭でも地位でもなく、やり遂げる事が出来る能力なので、
会社(歴代の経営層あるいは部門トップ)に渡して何になるのか、
さっぱり分かりません。