アジャイルソフトウェア要求vol4最後

Agile手法に対するアーキテクチャーは、個々のチームから複数のチームへとAgile手法の拡大を進めていくと必要になっていく。一方で、AgileやLEANを失わずに進めていくことが課題。

基本的な原則

続きを読む »

アジャイルソフトウェア要求 第3部を読んで

13章以降の、第三部に属する箇所に関していくつか記載。

 

13章

従来のソフトウェア開発では、Product Requirement DocumentやSoftware Requirement Documentなどの要求仕様書を用意し、開発を行っていた。これらのドキュメントは重く、リーンな開発では特に、小さく始める、Just In Time、動くものをより素早くというところがあり従来のように重たいドキュメントは歓迎されない。また、リーンソフトウェア開発の原則にある「決定を送らせる」ことを実現するには、やはり従来のように重たいドキュメントは歓迎されない。

一方、AgileやLEANではビジョンを伝え、共有することが必須である。そのため、それらの共有に力を入れる。これは以下のような問いに対する回答であり、一般的に5〜10ページ程度の文章となる。

  • このシステムはなぜ構築しているのか?
  • これがどのような問題を解決するか?
  • どのフィーチャーと恩恵(価値)を提供するか?
  • 誰に対してフィーチャーと恩恵(価値)を提供するか?
  • どのような性能/信頼性/スケーラビリティで提供しないといけないか?
  • プラットフォームなどのサポートは?

ひな形は本書の付録にあるので、そちらを参考に。

続きを読む »

Reading Best practice of story test

最近、Story Testの形に関して考えています。
目的は、AgileやLEANにて検証の対象となるStory/User Storyに対する評価としてStory Testをベースにしていきたい、というためです。
なぜなら、検証したい対象の形式に沿って、自動化するなりするときに”検証すべき興味の対象”と表現をあわせて試験を実施するほうが、価値に対する妥当性の議論の火種になったりという副産物を得ることができる可能性があるためとなります。
いくつかざっと目を通したのですが、ひとまずの参考と考え方を整理するために以下を参考にしました。
以下のExampleは、いずれも参考先を引用させてもらってます。

続きを読む »

アジャイルソフトウェア要求を5章まで読んで

Explore it! を読んでいたのですが、勤先での立ち振る舞いから、こちらの情報を早くインプットしたくなったので・・・

アジャイル要求を5章まで読んで。

書かれていたのは、ソフトウェア開発プロセスの歴史のお話しと、LENAなAgile開発での中核となる成果物、User Storyからその達成までの全体像でした。

以下は私の理解の要所要所を。詳しくは本書をお読みください。
http://www.amazon.co.jp/アジャイルソフトウェア要求-Dean-Leffingwell-ebook/dp/B00IMRDXZW/ref=sr_1_1?ie=UTF8&qid=1396105566&sr=8-1&keywords=アジャイルソフトウェア要求

※過去に紙の本買ってたのですが、携帯性からついついKindle本にも手が出てしまった・・・

続きを読む »

“Turnip or RSpec” x Appium

過去、こちらにて、AppiumにおけるテストシナリオをTurnipとRSpecのそれぞれの記述で比較してみました。
当時からまたいろいろ試し、考えてみた結果、ひとまずこうかな、という結論に達したのでメモがてら。

続きを読む »

Agile開発における acceptance testing と developer testing

Agile Testingにおける、Developer TDDとAcceptance TDDに関する2012年の統計情報を見てみて。

参考:
http://www.ambysoft.com/essays/agileTesting.html
http://www.ambysoft.com/surveys/agileTesting201211.html

続きを読む »

テストレベル in Google

多くの伝統的なソフトウェアテストでは通常、単体テスト、結合テスト、シスムテストなどによりテストレベルを区分しているかと思います。

一方で、自社の開発スタイルがLEANやAgileのように伝統的なV字型に適合しない場合も多いかと思います。(私が現在勤めているところでは、伝統的な開発スタイルが合していないように。)そのような場合にも関わらず、V字型の時のテストレベルを使い続けると、開発スタイルとテストの間に溝がうまれてくることでしょう。おそらく明らかに。

その中でも、やはりスピードのある開発を継続していくためには、開発者への負荷を高めないながらも、サービスとして不具合というようなリスクを抑えた開発を継続できるよう、テストレベルを区分して、組織として妥当な開発を行うことができる必要があると考えます。Agile開発でいう、開発とテストの結合ですかね。

少し今更感もありますが、Googleにおけるテストレベルに該当する箇所を振り返ってみることにします。

続きを読む »