Explore it! を読んでいたのですが、勤先での立ち振る舞いから、こちらの情報を早くインプットしたくなったので・・・
アジャイル要求を5章まで読んで。
書かれていたのは、ソフトウェア開発プロセスの歴史のお話しと、LENAなAgile開発での中核となる成果物、User Storyからその達成までの全体像でした。
以下は私の理解の要所要所を。詳しくは本書をお読みください。
※過去に紙の本買ってたのですが、携帯性からついついKindle本にも手が出てしまった・・・
LEANの無駄なく、価値あるものだけを小さく開発していく、という思想は主流となりつつあり、試行錯誤されてきたAgile開発へLEANの思想も浸透してきた。
LEAN開発では、Build-Measure-Learn のサイクルを回すとき、通常は検証したい仮説を設定している。その仮説に対する計測を行うためにMがある。一方で、このMの前にBuildがあり、Buildの終わりを評価するために開発物に対する検証が存在する。
※本当のStart upか、それとも市場リリースに向けたテストか、というもので差があることは事前に断っておく。
User Storyを just in time で適用し続けていくことは、過度に詳細な要求仕様書からのWater Fall的な開発の抑制へとつながる LEAN applocach になる。
=>
LEANを信条とする組織の評価単位としても、User Storyを基本とすることは、開発速度を落とさない検証として世界的に有効な手段であるということも出ていることを忘れず。（伝統的な形にとらわれている人や、その形が必要とされる分野の人はこれに大きく疑問を持つと思うが、スピードあるサービス開発に重点を置くアプローチをとる場合はこれを芯としていく必要があるのはLEANやAgile経験者が発表していますね。）
LEANでAgileなチームでは、一般的にOwner/Developer/Testerが1つのチームを構成し、受け入れテスト込みでシステムを段階的に素早く構築していく。Tester(Test engineer)がいることで、検証のための受け入れテストも含めた高速なフィードバックを回す開発を継続することができるようになる。
User Storyは、あるユーザのためにシステムが行われなければならないことを記載した意図の短い説明。Agileでは、一定の周期において対象となるUser Storyを開発、検証し、リリース可能（検証も終えた状態）なものを用意する。
=>
LEANでは、このリリース可能なものがBuildの段階を終えたものであり、次のMeasureに進むのでしょうね。ここで、User Storyの検証に対する網羅性（正常系/異常系）をどの程度行うのかは、限定的なMVPとしてのものなのか、一般ユーザへ利用してもらうものなのかなどを決めた上で決定されるべきでしょう。
User Storyと、その親となるFeatureの記述
- Feature:
- 大枠の機能名
- User Story:
- <役割> として、私は <活動> を行うことができる。これにより、<ビジネス価値>がもたらされる。
こうみると、Specification by Exampleに近い形で開発を行っていく、というスタイルにも見えますね。
LEAN start upでは、この<ビジネス価値>が本当に<役割>に対してもたらされているのかを、外部の測定値により判断する、ということだと思います。一方、それはBMLでいうBに対する検証が終わったあとのMの場面。なので、Buildが終わったことを検証するために、User Storyの受け入れ試験は程度はさておき、行われるべきところです。
具体例
- Feature:
- ログイン機能
- User Story:
- サービス利用者として、私はサービスにFacebookアカウントを使ってログインしたい。これにより、容易にログインユーザ向けのサービスの利用ができるようになる。
ここでさらに、User StoryからのTaskへ落とし込んだ例を示します。LEANやAgileの開発では、これらのUser Storyに紐づいたタスクがすべて完了することがUser Storyの検証まで終えたことを意味することになる。
UserStoryからTaskへの例:
User Story 10: サービス利用者として、私はサービスにFacebookアカウントを使ってログインしたい。これにより、容易にログインユーザ向けのサービスの利用ができるようになる。
Task 10.1: 受け入れテストを定義する (User Storyの完了基準の定義)
Task 10.2: User Story をコーディングする
Task 10.3: 受け入れテストをコーディングする
Task 10.4: テストに合格させる
Task 10.5: サービス利用者へ必要なドキュメントなどあれば作る
ここで、たとえば文言変更などの修正に関してはUser Storyを終えた後でも許容するなどの軽量なルールには落とし込む必要がある。※ここは企業に適宜あわせる、という感じでしょうか。
ここで、User Storyを実装にもっていくまでには以下の3つが必要だという。
カード: Storyの意図を文字として説明するために。
会話: User Storyの肉付けを行うために必要。関係者で会話を行い、実装内容の詳細をつめたりするもの。ここで、動くソフトウェアを素早く構築するためにドキュメントよりもコミュニケーションを重視していく。
確認: 実装した内容が、User Storyの意図を反映していることを確認する。
下の図は、FeatureやUserStory、Backlog、検証としてのテストなどの関係を表現したもの。ここで、StoryがUser Story もしくは other Developmentとしているのでは、必ずしも開発項目がUser Storyの形式に落とし込めるとは限らないから。ただし、その場合も達成基準であるテストは存在する。
こうみると、LEANもAgileも素早いフィードバックを得て開発をぐるぐる回すために、それを検証するスキルを専門に磨く、もしくは高い知識を持つ人が必要だとわかる。
多くの場合、このTester/Test Engineerが入る必要が無く、さらにはそれらは内部的であったりそのドメインに対して専門的な知識は必要ではない、というスタンスの人もみるが、その立場のまま効率的なテストを広めるとかいわれても抽象的な、一般論的な話ししか無理ですよね。。。
Agile Testingの話しも少しあわせて。
達成の条件を考えるにあたり、洗い出すべき課題はざっと以下がある。
– ビジネス上の達成の条件
– 既存機能への影響
– 法律に関する考慮
– 定期スケジュールされたプロセスへの影響
– UIストーリーに対するモックアップへの参照
– ヘルプテキスト、誰がそれを提供するか
– テストケース
– データ移行
– 必要な内部コミュニケーション
– 外部コミュニケーション
~ my tech diary ~ 