タグ

関連タグで絞り込む (2)

タグの絞り込みを解除

agileとバックログに関するp260-2001fpのブックマーク (5)

  • アジャイル(scrum)とテスト - ブログ@kaorun55

    特徴(Feature)、粗筋(Story)、脚(Scenario)とチケットの関係: プログラマの思索 [TiDD] 計画できないことの管理と計画できることの管理: ソフトウェアさかば あきぴーさんとさかばさんの記事を読んで、こっちも少し。 そもそも TestLink の適用範囲って、要求に対するテスト(受け入れテストと呼ばれるような)だと思っている。 TestLink 自体に要件管理機能がついたことからも。 で、Redmine (Trac)のチケットの適用範囲は、基的にバグ、タスクのレベル。 あきぴーさんはそこに フィーチャーとストーリー(つまりは要求)を入れようとしているので認識の違いができているように見えた。 TestLink の適用範囲が scrum のどこに当たるかといえば、フィーチャー/ストーリーだと思うので、フィーチャー/ストーリーに対するシナリオを TestLink で

    アジャイル(scrum)とテスト - ブログ@kaorun55
  • 特徴(Feature)、粗筋(Story)、脚本(Scenario)とチケットの関係 - プログラマの思索

    ユースケースとストーリーカードの関係、特徴(Feature)、粗筋(Story)、脚(Scenario)とチケットの関係についてメモ。 【1】「システム要求、システム要件をどのように書くか?」はどのSW開発手法でもバラバラ。 オブジェクト指向分析(OOA)なら、ユースケース記述書のフォーマットに従って、システム要件や要求、フローを書いて、そこからモデリングしていく。 ユースケース記述書の書き方で一番優れていると思うのは、コーバーン著の「ユースケース実践ガイド―効果的なユースケースの書き方」。 ユースケースの書き方、観点のノウハウが詰まっている。 特に、ユースケースの観点を、アイコン(雲・凧・海水面・魚・貝)で表示して区別するのを推奨しているのは要注意。 ユースケース記述書のサンプルは下記を参考。 ユースケースについて システムユースケース記述 [C02あんしん電話(高齢者] ユースケース

    特徴(Feature)、粗筋(Story)、脚本(Scenario)とチケットの関係 - プログラマの思索
  • 特徴(Feature)、粗筋(Story)、脚本(Scenario) - masayang's diary

    Agile開発に限らないが、システム*1業界用語ってカタカナ*2表記が多すぎる。 「いや、元々が舶来なので日語では微妙に表現できないのですよ」という人もいるかもしれない。 でも、この「カタカナ表記のまま」ってのが意思決定者の判断を誤らせたり、新規参入者に対する壁を高くしたりしている可能性は排除できないのではないかな。 今日、この後打ち合わせが入ってるプロジェクト*3もFeature、Story、Scenarioがごっちゃになりかけている。 なんとかわかりやすく表現できないかと悩み中。 以下、自分の案。名訳があったら、是非教えていただきたい。 Feature=特徴 自分は今までFeatureを「機能」と紹介してきた。 同じ「機能」でも開発者が対象にするのはFunctionで、利用者が対象にするのはFeatureですよ、と説明してきた。 でも、安井さんと角谷さんの29頁を読むと「特徴」がい

    特徴(Feature)、粗筋(Story)、脚本(Scenario) - masayang's diary
  • プロダクトバックログとスプリントバックログの違い~要求マネジメント - プログラマの思索

    「成功する要求仕様 失敗する要求仕様」の最後に、要求マネジメントに関するクイックレシピがある。 その方法が、Scrumのプロダクトバックログとスプリントバックログを上手に使い分けるのと同じように思えたのでメモ。 【1】あるシステムを作るために、要件定義をしているとしよう。 その時、「成功する要求仕様 失敗する要求仕様」のクイックレシピによると、以下の手順が必要になる。 1.ブレーンストーミングで要求をまず洗い出す。 要求の実現性は問わない。 要求の優先度や重要度も洗い出す。 2.ブレーンストーミングで洗い出した要求リストから、要求か否かを決定する。 実現できる要求のトリアージを行い、要求の候補を決定する。 但し、この段階では、コストやスケジュールは未決定。 3.リリース計画を作る。 実現可能なスケジュールと予算を作り、リリース計画へ入れる要求を足していく。 但し、作成中のリリース計画では不

    プロダクトバックログとスプリントバックログの違い~要求マネジメント - プログラマの思索
    p260-2001fp
    p260-2001fp 2009/12/07
    プロダクトバックログとスプリントバックログの使い分け
  • プロダクトバックログについて海外の例も踏まえ考えたこと

    Agile経験がほとんど無いチームにScrum+XPの開発方法を教えながら開発しているのだが、 プロダクトバックログと見積もりポーカーのあたりでメンバーがもやっとしていたようなので 自分自身の整理も兼ねてメモ。 事例検証 まず以下は海外サイト等で公開されているプロダクトバックログのサンプルをいくつか見てみよう。 SimpleProductBacklog http://agilesoftwaredevelopment.com/scrum/simple-product-backlog 気になるところ Sprintに入る前に「#1 CI環境を構築する」「#4 Webサーバを構築する」とかあるけど、顧客から見るとどうかな?これはSprint0のタスクであるような気がする。 このリストはフィーチャーなのかストーリなのかが分かりにくい。Sprint1の項目はフィーチャー。Sprint2の内容はストーリ

    プロダクトバックログについて海外の例も踏まえ考えたこと
  • 1