Agileについて学ぶ

師匠のところで。

Feature=特徴
* 自分は今までFeatureを「機能」と紹介してきた。
* 同じ「機能」でも開発者が対象にするのはFunctionで、利用者が対象にするのはFeatureですよ、と説明してきた。
* でも、安井さんと角谷さんの本29頁を読むと「特徴」がいいのかな、と思った。

Story=粗筋
* その特徴(Feature)を利用者が具体的に体験する過程を記述したのがStory。
* AgileではこのStory単位で見積りや計画を行い、開発が進められる。
* これは「粗筋」かな、と。
* 理由は、この後にでてくる「Scenario」との関係で。

Scenario=脚本
* 粗筋(Story)をより具体的に記述したもの。
* 受入検査*6の根拠となる。

以前やった開発でも、Featureのところで何度もアドバイスをもらいました。

僕にとって、それぐらいFeatureは難しく感じました。(理論は理解できるのですが、実践がむずい)


そして、画面設計の無駄についても何度も指摘を受けた。

画面から要件分析をすると、こうなる

* どうやら要件分析する前の段階で「コンサルタント」の人達が、画面を使ってお客さんと「要件定義」をしていたらしい。
* 「この画面でこういうデータを入力すると、こんな画面に遷移します」みたいなやりとりがあったのだろう。
* 紙芝居感覚で交渉できるからわかりやすい。

客との調整、およびデザイナーとSEの調整をする「だけ」ならこれでいいんでしょうね。
でも、目的はシステムを作ること。
おそらくその視点を、そういう人たちは持ってないのが多いのではないだろうか。

「釘の打ち方、木材の切り方を知らない建築設計士」みたい?!

上記話はこう続く。

* だけど、先に画面を決めちゃうというのはいくつかの(そして時に致命的な)問題を抱えている。

* 実装をフィーチャとして捉える可能性。
o 例えば「利用者は正しいIDとパスワードを入力することでシステムにアクセスする権限を得られる。権限には一般利用者、部門管理者、前者管理者が存在する。」というのは実はフィーチャではなく実装の話である。
o 「部門管理者として、私は所属社員の電子メールアドレスを初期設定できる」、といった具合にストーリを記述することで「部門管理者ができること」を表現できる。
o にも関わらず、認証の実装をフィーチャとして捉えると、その分工数は確実に増える。
o そしてその受入テストは認証の実装を確認するテストと何が違うんだ? というくらい重複したものとなるはずだ。

たしかに、受け入れてテストで細かい権限を見たりしないことが多い。
実際に管理者や一般の人がアクセスし、画面を確認するぐらい。

問題はさらに続く。

* ストーリの数が増えちゃう可能性
o 実装をフィーチャとして捉えちゃうと、ストーリがどんどん増えてしまう可能性がある。
o なぜなら実装を言葉でもって表記しているから...
o 当然受入テストも増える。本来なら結合テストでやるべき話が受入テストにやってきてしまうのだ。

* 硬直化の可能性
o 作っているうちに「こうUIを変えた方がいい」などの改善案が生まれるのは避けられない。
o 先に画面を固めてしまうと、こういう改善を拒むような力が働く。
o Agileじゃないでしょそれって。

これは多くの人が体験することじゃないでしょうか。

先に画面をきっちり作っちゃってるから、修正がごっつ億劫になる。

最後に当てはまればええやんと、毎回感じてしまう。

まあ管理するものとして、早くより実物を見たいからだろうか。

以前いたプロジェクトでは、PGの協力さんですら画面を早く見たいからデザインくれという始末。
で、途中で修正が入るとあーだこーだいう。

* なぜ、先に画面設計からはいるのか考えたことある?
* 「昔からそういわれてきたから」とかそういう理由ではないか?
* あるいは「分業体制でそうせざるを得ない」とか?

はい、そうでした。。。(すんません
当時の自分のポジションでは不可抗力でした。

いつかまたなんかサイトの構築とか携わったら、フル開発メンバーとか形成してみたいですね〜。
#仮にうまくいかなくてもそれはそれで得られるものがあるはず。



これを書いていて、ふと大学時代を思い出しました。

ある日、教授が僕を呼びました。

 授業の宿題でクイズ形式のサイトを作ってほしいんだけど。

今思えば、これは要求定義だ。

で、教授の話は続く。

 機能としては4つ。
  + 2択(Yes or No)
  + 4択(単一選択)
  + 4択(複数選択)
  + 記述式

これがFeatureか!?
で、さらに話は続いた。


 クイズは画面上から管理者が登録できる。
 クイズは1つのタイトルに複数紐付く。
 管理者は、解答者(生徒)の正答率を閲覧できる。
 記述式は、あらかじめ設定したキーワードが何個入っているかを判定するだけでよい。

これぐらい言われただけでした。

あとは大体のイメージを紙に殴り書き(笑)

で、僕はというと、まずはHTMLで超簡単な一連の画面を作成。

大体のOKをもらってGo。

その後も教授と頻繁にやり取りし、結局1ヶ月もかからずに完成。
それがたしか2002年ごろ。
今も使われているようです☆彡

ちょっとAgile入ってたのでしょうかね。



一応、ソフトウェア工学講座だったこともあり、教授も少し試したのだろうか!?

#そういや、同級生の一人がAgileについていろいろ調べてたなー(といってもこの翌年ですが

最近、ちょっと作りたいサイト(完全に趣味)があるので、それを一度Featureに落としてみて、プチAgileを練習してみようかな。