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

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

基本的な原則

Continue reading “アジャイルソフトウェア要求vol4最後”

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

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

 

13章

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

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

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

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

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

Reading Best practice of story test

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

Continue reading “Reading Best practice of story test”

アジャイルソフトウェア要求を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本にも手が出てしまった・・・

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

“Turnip or RSpec” x Appium

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

Continue reading ““Turnip or RSpec” x Appium”

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

Continue reading “Agile開発における acceptance testing と developer testing”

テストレベル in Google

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

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

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

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

Continue reading “テストレベル in Google”

Pull Requestにドメイン知識を載せること

最近、レビューの話でいろいろ盛り上がってましたが、あわせて考えてみた。

主にはLEANやAgileを重視している、サービス業を展開している開発現場の話しです。
また、以下ではPull Requestベースの話です。

いきなり本題ですが、技術的な実装に対するレビューのためのPull requestに関しても、User Storyを書き、そのStoryの何を行うための実装かをまとめることって、必要なんでないかなと。
ここには利点がいくつかあると思っていて、

Continue reading “Pull Requestにドメイン知識を載せること”

「サイトパフォーマンスのインパクト」を読んで

LEAN START UPのMeasureを行うために何を品質をとらえればよいのかを日々考えているのですが、今回は以下のワザノバの記事から少し考えてみました。

サイトパフォーマンスのインパクト

サイトパフォーマンスがプロダクトにどのような影響を与えるかは色々な資料で見たのですが、数字が頭には残ってなかったので、EtsyのLara Swansonがこちらのブログで事例をまとめてくれていて助かります。

  • ページの読込みに3秒かかれば、40%のユーザが離脱する
  • Amazonによると、ページの読込み時間が100 ms増えると、売上が1%落ちる。
  • Googleは、検索結果の表示数を増やして、ページの読込み時間が0.5秒増加すると、売上とトラフィックが20%低下した。
  • Akamaiによると、75%のオンライン購入者は、フリーズ / クラッシュ / ページ読込みが長過ぎる / 購入フローが複雑という経験をするとそのサイトでは購入しない。
  • Googleでは、Google Mapsのサイズを100KBから80KBに削減したら、ユーザの再訪率が改善した。
  • Etsyではモバイルページに160KBの画像を追加すると、12%の端末で直帰率が増えてしまった。
  • DoubleClickでは、クライアント側でのリダイレクトを1箇所取り止めると、モバイル端末でのCTRが12%改善した。
  • Amazonが画像ファイルを圧縮JPEGファイルに変更すると、モバイル端末でのバッテリー消費が20%減り、Facebookの場合は30%削減できるという研究結果もある。

Continue reading “「サイトパフォーマンスのインパクト」を読んで”

LEAN UXを呼んでその1

メモがてらなのですが、LEAN UXを呼んでのまとめをざっくり記載してきます。より詳しく確認したい方は別途、同本をお買いください。

大事な所
* Design thinking
* Agile software development
* Lean start up

Principles
* Cross-Functional Teams
* Small, Dedicated, Colocated
* Prigress = Outcomes, Not Output
* Problem-Focused Teams
* Removing Waste
* Small BatchSize
* Continuous Discivery
* GOOB: The New User-Centricity
* Shared Understanding
* Anti-Pattern: Rockstarts, Gurus, and Ninjas
* Externalizing Your Work
* Making over Analysis
* Learning over Growth
* Permission to FailGetting Out of Deliverables Business