キャラクターの動き方、操作感、魔法のエフェクトなどを試し試し作って数人の関係者を呼んで確かめながら作っていた
これがアジャイルそのものだ
説明終わりだ
と言うと続かないので続きを書く事にする
この試し試しと言うのが重要で
仕様書作ってそのまま作りましょうでは無理なのだ
ゲーム業界から外資系ソフトハウスを経験し、その後業務系アプリを経験した時に、
日本の業務系はなんてクソ無駄な事やってんだ？
と感じた
仕様書通り動くなんてあるわけがない
大きなプログラムを作っていれば
どんどん共通化しようと設計の修正が入ってくる
その都度全体の作りも変えて行くべきなのだ
それなのにフローチャートの通り作れと？
フローチャートなんか、数人に書かせれば同じフローチャートにはならないのだ
要するにフローチャートなんかこんな感じ？
程度のものでしかない
そんなの口で言えばプログラマは分かる
だけど仕様書がないままプログラマが勝手に書くと
仕様書がない
テストしてないと横槍が始まる
では聞きましょう
仕様書通り作って、テストしたものの品質は高いと断定できるのか？
そんな事はない
バグだらけだろ？
何度同じことを繰り返せば気がつくのだ？
仕様書通り動いてるプログラムなんてこの世に存在しない！
わたしはやるべきテストはしている
問題点があれば報告する
共通化しなければならないなら部品も作る
これは当たり前なことなのだけど
普通のプログラマはやらない
普通のプログラマは
言われたことを言われた通りにしか実装しない
そして終わりましたと言う
そんな仕事楽しいか？
アジャイルは「機敏な」「敏捷な」と言う意味がある
一般的なクソな流れは要件定義、基本設計、詳細設計、コーディング、単体テスト、結合テストだ
プロジェクトリーダーは、線表引いて遅延確認を毎日する
こんなクソな事はアジャイルでは全部やらない！
ではどうするのか
要件をまとめる段階でプロジェクトリーダーと一緒に実際に操作の紙芝居が出来るように画面を作る
プロジェクトリーダーがこれでお客さんに見せられるなと判断したら関係者全員に確認を取る
プロジェクトリーダーが確認をとっている間に、先に進む人はデータの持ち方、テーブルのカラムなどを考え、WebAPIが必要ならダミーでもなんでも作り始める
誰からも指示なんかされなくても自分で次の仕事を探して取り組む
プロジェクトリーダーが紙芝居を終えてやって来たら今こんなの作ってんだよと見せるとともに紙芝居の結果を聞き、修正があればその場で直す
この段階でお客様の要件と実装はほぼ終わり、
しかもチーム全体が要件を理解して実装のイメージが掴めるようになっているはずだ
朝会で進捗確認するまでもなく
完全にチームは全体像を把握する事になる
したがってゴールするまでにかかる見積もりも明らかになってくる
まさにアジャイル（機敏）
そうして、直したものをリーダーがお客様にプレゼンしている間に、プログラマはデータベースのテーブルやWebAPIも大体動くようにしておく
これをやるには
プロジェクトリーダーは要件を全部把握する必要があり、それをプログラマに正確に伝え、一緒になって画面を見つめながら出来上がるまで一緒に作業しなければならない
プログラマはプロジェクトリーダーと一緒に考え、おかしなところも相談しながら仕上げていく
「この画面無駄じゃね？こっちの画面にカラム追加してリンク押せばそっちの画面に行くようにしたら一画面減らせるぞ？」
「ここの操作こうしたら、警告なんかそもそも出る状態にはならないぞ？」
そう言う話し合いをしながら作れば、妙な仕様に頭を悩ませる時間も無くなる
チーム全体が自分のやるべき事、役割を把握していないと出来ないのだ
プロジェクトリーダーが
「お客さん何言ってんのかわからないんだよ、毎回言うこと変わるんだよ」
「ここ、わたし全然詳しくないんだよ」
と言うならリーダーやめろ
やめたくないならお客様の言いたいことを必死に汲み取れ
わからない事はわかるまで勉強しろ
人に聞け
わからないまま放っておくな
ブワログラマが
「プロジェクトリーダーの言ってる事はおかしいと思う」
「あれこれ言ってくるから何を作ればいいかわからない」
「注文が多すぎる！」
「なんでわかってくれないんだろう」
と思うなら
会話をする姿勢とはなんなのか必死に考えろ
意固地になるな
他人を認めろ
画面くらいすぐさま人に見せられるようになれ
わたしはディレクションもコーディングもグラフィッカもやっていたので、チーム全体の気持ちがほぼわかる
だから、仕事は流れるように進む
プロジェクトリーダーもプログラマも、互いに意思疎通をしようと努力し。自分の役割を理解し。やれることをやる。やれない事は相談する。
こう言う事が全体で、出来ている状態を
マインドセットが出来ている状態と言う
さて、要件定義が残って居ないとお客様からあらぬ記憶を頼りにこんなの頼んでいない！と言われるので、大体プログラムが動いてきたら何度もお客さんのところに行ってしつこく確認が必要となる
そして、それをきちんと文章に残す
この段階で要件定義をまとめるべきだ
次に仕様書だが、
プログラムの中身がクソスパゲティになるのはクソ仕様書の通りに組むからであって、ポリシーを持って共通化をしたり、フレームワークを作れば結構綺麗に仕上がるはずだ
だが、残念な事にある程度プログラムを書けるようになったものには罠が潜む
クソプログラマの口にしがちなセリフを書いておこう
MSDNに書いてある！
（MSDNはあてにならない）
こことここは共通化出来る
（だからって何でもかんでも共通化して読めなくするのは間違い）←これ本当にやばいから、これしか言わないプログラマはマヂクソ
ラッパクラス作ろう！
（やめろ、特にそのまま使えばいいものをラッピングするな、log4jとかラッピングするな、礼儀を知れ）
DDDではこうだ！
（Javaの人はそれで幸せになってください、でも、それを他の言語に持ち込むな、てか、Javaの人は自分で自分の首絞めてて、コーディング量の割には碌でもないのがわからないらしい、他の言語を勉強しろ)
オブジェクト指向的にはこれが正しい！
（オブジェクト指向覚えたてだとこうなりがち、もっと簡単な方法があるならそれを選んでも良い。ちなみにGoはオブジェクト指向ではない。オブジェクト指向的に作れなくもないが、それは作者への冒涜だと思う。彼はC++が嫌いだと言うことをモチベーションにGoを作ったのだ）
デザインパターン的にはこれが正しい！
（あんなもの忘れろ、奴ら如きがギャングとかいい気になってるのがわたしは本気で気に入らない）
仕様書はUMLで書かないと！
（日本人にはUML合わない、もっとマシな絵を日本人は描けます、日本人舐めるな、読むのにテクニックが必要な段階であんな物要らん）
コメントは1行ごとに全部書け！
（勘弁してください）
さて。プログラムの仕様書だけど
ちゃんと綺麗に動くコードなら読めば分かるし、コメントがきちんとJavaDocなり、XMLスタイルで書かれてれば、DoxygrnやSandCastleで綺麗に仕様書が出てくるはずだ
だから、関数の定義や戻り値など、一生懸命Excelで書かないでいい
DoxygenにGrapvizを組み合わせて、Call Caller図を出せば、かなり役に立つ図が出来上がる
プログラムを直して、仕様書を直して、テストになってもいない無駄なテストして、品質を保証します！なんて、本気で無駄です
なんのお遊戯ですか？
最後に
大手様で特に、要件定義からの流れをやっています
それはなぜかと言うと
大手様の流れの提唱者が論文を書いているからです
でも、わたしは彼らがプログラマではないことも知っていますし、マネジメントで成功を収めた人たちではないことも知っています
つまり、全部虚構！
今すぐそのやり方をやめましょう
0 件のコメント:
コメントを投稿