だんだん開発スピードが遅くなっていくのをどうやってとめたら良かったんだろう？ - Mitsuyuki.Shiiba

先日、モブプロをやってきた。その中で、モブプロとは別で、いくつか感じたことがあって、今日はその中のひとつを思い浮かんだままにメモ。 bufferings.hatenablog.com 要件を満たすプロダクトをより早く出す モブプロでTDDしながら、要件を満たすプロダクトをより早く出すことに集中してみた。例えば、第２ラウンドのお題はTDDBCなどでお馴染みの「自販機」。 「100円を入れてボタンを押すとコーラが1本買えること」 最初に「100円を入れてボタンを押すとコーラが1本買えること」と言われ。 assertThat(get(100), is("コーラ")); みたいなテストを書いて。 String get(int money) { return "コーラ"; } みたいな実装を書いた。爆速！ 「200円を入れてボタンを押すとオレンジジュースが1本買えること」 次に「200円を入れてボタ

[sonots]

「そのあいだ」を取るには、今後の拡張を考えはするけど、実装まではしないのがコツ。つまり、今後の拡張へのリファクタリングをしやすい構造にはしておくけど、過度な汎化実装はまだやらない。

[kz78]

あまり最初から拡張性を考え過ぎると、誰もつかってない機能を延々とメンテするはめになるからねぇ…。／id:turanukimaru 世の中、予測してた機能が増えなくて、予測してない機能が増える。（この例だとドルがみたいな

[t-murachi]

もう初手から0円でもマイナス10億円でもコーラが手に入る実装作っておいて何言ってくれちゃってるの…(´･ω･`) 早けりゃいいって問題じゃないでしょ(´･ω･`)

[htbman]

要件の解釈が雑。100円を入れるから引数を100にしたんだろうけど、であれば101や99のときのテストを書くべきだし、そんなテストが必要なのはなにか臭うぞとなる。考えるべきところを飛ばして早いと言っているだけ

[sakidatsumono]

最初のテストコードを見た瞬間あかんやつやと思った

[turanukimaru]

変化は発見するものじゃない。予測するものなんだ。特に増えるものを予測しよう。この例で言えば、コーラを買うから、他の商品は増えますか？別の価格が増えますか？と聞く。増えるとわかってるものは準備できる。

[endo_5501]

“最初の開発をやってた人がマネージャとかになる 「僕がやってたころは、もっと開発スピード速かったんだけどな」とか言ってる。”

[uturi]

開発ではよくある話。結果論であれば「こういう設計にしておけば良かった」と言えるんだが、開発が進むほど設計からの見直しは難しくなるよな。

[masatomo-m]

開発者側からのヒアリング不足に見える。機能面の仕様だけじゃなくてビジネスロジックやそのプログラムがカバーしたいビジネスドメインまで理解しに行ってPOと相談するという力が足りていない。SE力的なやつ

[takhasegawa]

“動いている部分には極力触るなの精神” て、なんのためのテストコードなのか。

[koemu]

お互いが思い浮かべたゴールがすれ違ったり、後から浮かんだ別のゴールがあったりすると、ありがち。キックオフ時にどこまで詰められるか。

[airj12]

DDDの話ってわけでもないのか / 追加開発の工数が予定を上回り続けるケースの多くはこのパターンな気はする

[teruyastar]

物語の始まり「スイッチ」と結末「取り出し口」だけ把握して、物語途中の追加キャラ「お金」「種類」「在庫」で話膨らませ。物語矛盾(if文)を極力減らすためキャラごとに章完結しておいて物語が結末いけばOKみたいな?

[hoozuki37]

こうやって開発速度どころかバグ対応すら硬直化したクソ設計が未だにでかい顔で居座っている業界、他にもありますよね（製造業とか）

[kita-tuba]

だんだん開発スピードが遅くなっていくのをどうやってとめたら良かったんだろう？

[AKIY]

要件を確認して整理するとか、業務を理解するとか、スコープについて折衝するとか、そういう開発手法以外の要素が欠落していないか。やり方はスクラムでもダメなウォーターフォールと本質的に同じ。

[uxlayman]

闇が深すぎる。自販機ってお金を入れてボタン押すんやろ。なんでその2つが入力にならんの

[niship_0822]

変化の速度よりも「変更容易性の確保」か。

[nisisinjuku]

未来に起こることを予見して備える。仕様整理してから着手。クライアントの話をよく聞きその近辺に潜む闇を認識し潰しこんでおくこと。だいたいそんなんでなんとかなると思うのですが、開発は早くなるかは知らない。

[tettekete37564]

もの凄いあるある感。結局マネジメントと同様､最初にステークホルダーとアクティビティーを全部集めてゴールを共有することが大事。

[risouf]

根本的にはゴールイメージが共有されていないことが問題のように見える

[mather314]

やってることはTDDで、このモブプロで開発している「価値」が単機能のレベルになってませんかね…？五月雨で要求が出てくる開発じゃなくて目的の共有とバックログの優先度付けをして何を作るか見通しを立てるべき。

[ryota-murakami]

実例に具体的なサンプルコードを提示しているエントリは認識のズレから正じるWebの不毛な議論を避け、建設的な議論を齎す貴重な存在だと思う。

[toritori0318]

このプロセス、エンジニアなら大抵通る道な気がする

[tekimen]

関わっている業務のドメイン知識とプログラミングの知識とのバランスだろうか。

[Kuichi]

"自販機"という大抵の人は知っているものならいざ知らず、開発案件で作るものってオーダーメイド品だから、そもそも完璧な要件定義は無理だよなあ、って思う。都度リファクタリングしかないのかも。

[TETOS]

バグは最悪直せばいい。最悪なのはほとんど使われていない癖エンハンス困難なクソ設計のクソ機能。

[fops]

完成後に仕様変更を何度もしたらそりゃ炎上するよ

[ngsw]

本旨とずれるかもしれないが「実装者はどうデザインしたいか」なるものは案外重要なのかもしれないなと思ったし「動いてるからいいでしょ」よりは「このパターンは明示的に実装してません」の方が嬉しかったりとか。

[lazex]

全体的に置き換えると綺麗になるし修正し易いものになるのに、今動いてるとこは絶対に書き換えたくないと言う人のせいでどんどんグチャグチャなヒドイものができあがるんだよね。ムリな増設ほどコストかかってるのに

[damedom]

プログラミング教育で教えるべきはコードの書き方というよりも、こういった概念を実装に落として行くときのジレンマだと思う

[hase_done]

動いている部分も都度作り変える

[Dicco]

これは面白い。

[shuuuuuny]

自販機

[snowlong]

これを上から目線で語れるのは開発をやったことない奴か天才のどちらか

[daibutsuda]

#TDD

[kojette]

リファクタリングやねー。そして、自分が欲しいものを自分で作るのが一番楽だ。

[satokumakuma]

何はともあれこれじゃないか？ “それと「自販機」というものを知って、早く小さくブレイクスルーを起こすために、POはもっと中から発言をすると良さそうかなー。”

[chintaro3]

最初に予算の概念が無いのがまずマズい（暗黙知として有るんだろうけど）。10万円の仕事と10億円の仕事では何もかもが違う。

[ryo_ryoo_ryooo]

この要件以外なにも満たさないコード書ける人は、めっちゃできる人に違いない。普通の人は要件以外の関係ないコードまで書いてしまう。