なんたって”DevQA” アジャイル開発とQAの合体が改善を生む - 永田 敦 氏 #postudy
鷲崎弘宜, "アジャイル品質パターン (Agile Quality, QA2AQ), アジャイル時代の組織ケーパビリティ向上 CMMI V2.0 / APH(アジャイルパフォーマンスモデル) / アジャイル品質パターンセミナー, 早稲田大学, 2019年6月6日 近年日本のソフトウェア開発チームでも取り入れられるようになったアジャイル/DevOps開発では,今まで主流であったウォーターフォール開発と異なり,短い開発サイクルの中で小刻みなフィードバックループと改善活動を繰り返しながら開発する特徴がある.そのため,品質保証や信頼性でのメトリクス活用においても,メトリクスにもとづいたQAテストを実施することは依然重要であるが,それに加え開発から運用までの一連のプロセスの中でプロダクトとプロセスの品質を見える化し継続的な改善活動を促進するフィードバックを提供することがアジャイル開発では求められる.
スクラムにおける技術的スパイクの進め方
みなさんこんにちは。@ryuzeeです。 スクラムでは、スプリントに投入するプロダクトバックログアイテムはReady（準備ができている）である必要があります （Readyとはどんな状態なのかについては以前に詳しく説明したので、そちらを参照してください）。 Readyにしておくことによって、成果の量が安定しプロダクトオーナーやステークホルダーにとっては予測精度が向上していきます。 Readyにする活動は単に受け入れ基準を用意したり、プロダクトバックログの内容を精緻化したり、並べ替えたりするだけではありません。 スプリント内でプロダクトバックログアイテムが完成する可能性を上げるために必要な活動すべてが含まれます。 そしてその中の1つが技術的な調査です。 スプリントでプロダクトバックログアイテムに着手してから実現方法を調べたり、技術的な制約によって大幅な方針転換したりするのでは遅い上に予測性が低
プロダクトバックログ項目はReadyなものだけスプリントに投入するべきという話
みなさんこんにちは。@ryuzeeです。 プロダクトバックログはスクラムにおける生命線の1つです。 プロダクトバックログが良くないとプロダクトの価値がでなかったり、そもそもスクラムチームとして安定したデリバリーを行えません。 プロダクトバックログでよく起こる問題プロダクトバックログを管理する上でみなさんがよく知っているのは、並び替えをする、という点ですが、これだけではまったく不十分です。 単に並び替えだけをしたプロダクトバックログで、スプリントを始めてしまうと以下のようなことが起こります。 選択したプロダクトバックログアイテムの中身に対してプロダクトオーナーと開発チームの理解が違ってしまうそのためスプリントを開始した後に頻繁にプロダクトオーナーと会話をする必要が出てきてしまい、場合によっては本来の要求が別のものであることが判明するもしくは色々会話をしていたら、当初の想定以上に規模が大きいこ
リリースプランニングの10個のTips
みなさんこんにちは。@ryuzeeです。 Release planning 10 Tipsを抜粋・意訳にてご紹介します。 スクラムにおいては、プロダクトバックログの重要性が極めて高いので、それをどうやってメンテナンスしていくか、という点について参考になると思います。 以前、コーチで行ってた現場で、「プロダクトバックログを最初に抽出して固定して一括請負契約できますか？」という質問を受けたことがありますが、アジャイルにおいては要件は可変パラメータなので、プロダクトバックログの固定自体はあり得ません。 プロダクトバックログは常時変化していることを認識することプロダクトプロダクトバックログアイテムの優先順位を継続的に付け直すこと次のスプリントのためのプロダクトバックログアイテムを継続的に準備することプロダクトバックログアイテムの個数は60〜70項目までにすることプロダクトオーナーは開発チームと一緒
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
