InfoQ: アジャイルのプロジェクト憲章には何を書くべきか？Spring BootによるAPIバックエンド構築実践ガイド 第2版 何千人もの開発者が、InfoQのミニブック「Practical Guide to Building an API Back End with Spring Boot」から、Spring Bootを使ったREST API構築の基礎を学んだ。この本では、出版時に新しくリリースされたバージョンである Spring Boot 2 を使用している。しかし、Spring Boot3が最近リリースされ、重要な変...
インデセプションデッキ｜ネスケラボ
インセプションデッキとは インセプションデッキとは、プロジェクトの全体像(目的、背景、優先順位、方向性等)を端的に伝えるためのドキュメントです。ThoughtWorks社のRobin Gibson氏によって考案され、その後、アジャイルサムライの著者 Jonathan Rasmusson氏 によって広く認知されるようになりました。 インセプションデッキについては、Jonathan氏のブログ「The Agile Inception Deck」にて説明を読むことができます。 Jonathan氏が作成したインセプションデッキのひな形 インセプションデッキ（Inception Deck）を直訳すると「最初のデッキ(カードの束)」という意味となり、アジャイルプロジェクトにおける「プロジェクト憲章」に近い意味合いを持ちます。 プロジェクト憲章とは PMBOKにおけるプロジェクト憲章(Project Ch
バーチャルパネル: コードとテストの比率、TDD、BDD
JB:この件について一般化するのは嫌なので、私がTDD/BDD使うときとその理由を説明させてください。 私が初めてTDDに出会ったのはミス(欠陥といってもバグといってもいいでしょう）を防ぐ方法を求めていたからです。プログラム上の多くのミスのおかげで私は完璧さの感覚を失ってしまいました。どんなことを成し遂げても仕事が完璧に近づいたと感じたことはありませんでした。そして、書いたコードをテストすれば、ばかげた小さなミスを見つけ修正できるのではないかと考えました。テストをしてミスを見つけたかったのは、愚かにみられるのを防ぐためというより、仕事に対する完璧さの感覚を失わないようにするためです。実際テストは役に立ちました。数年経って、TDDはコーディングのミスを防ぐのに役に立つだけでなく、デザインの失敗を防ぐのにも役に立つことに気づきました。そしてBDDを学び、どのような機能を実装するかについての失敗
ユースケース、それともユーザストーリー？
Murali Krishnaはこう言う(リンク)。 アジャイル開発へ効果的に移行できないという失敗は、ユーザストーリーが何たるかを理解できていないという根本的な失敗に根ざしていることが多い。 ユーザストーリーの最も重要な側面は、ユーザストーリーが要件（機能）の「スケジュール可能な」ユニットであり、スケジュールは他に依存していないということです。ユーザストーリーの「他に依存せずスケジュール可能な」特徴を実現する鍵となるのが、「ユーザ」がどう使うかという目線に立ってユーザストーリーを表現することです。そうすればユーザが実際にインタラクトできるエンドツーエンド（UIからバックエンド）に実装された機能性のユニットが手に入ります。 Krishnaはアジャイルコミュニティで多数の人々が信じている「ユーザストーリーは唯一、最良のよりどころ」を正確に描写し、Mike Cohnによる「Advantages
スクラムにおけるメトリクスの扱い | Ryuzee.com
みなさんこんにちは。@ryuzeeです。 最近よく「スクラムではどんなメトリクスをどう取ればよいですか」と聞かれるので整理しておきます。 スクラムでよく登場する数値データスクラムでよく登場する数値データとしては、プロダクトバックログアイテムのビジネス価値や見積り、スプリントバックログのタスクの理想時間があり、スプリント中に完了したプロダクトバクログ項目の見積りポイント（相対見積りの場合）の合計がベロシティ、全プロダクトバックログアイテムの未完了分の合計見積り値の推移をプロジェクトバーンダウンチャート、スプリント期間中のスプリントバックログ項目の合計残時間の値の推移をスプリントバーンダウンチャートとして表現することができます。 最新のスクラムガイドでは見積りを相対ポイントで行うべきであるとか、これらチャートを書くべきであるとかは規定されておらず、またメトリクスをいつどのように取得するのかにつ
【資料公開】Doneの定義 虎の巻
みなさんこんにちは。@ryuzeeです。 この年の瀬にスクラム道.08を開催しました。今回のテーマはDone(完了)の定義です。以下に資料を公開します。 なお、議論を誘発するために、あえて細かいことを書きすぎないようにしていたりしますのでそのあたりはご了承ください。 スクラムでは、完成の定義は必須です。これがないとどこまで作業をして良いか分からないし、完成の定義を見ることでチームの成熟度を把握することもできます。 いつもの通り感想などを。 今回はいつもの永和システムマネジメントさんではなく、KDDI Webコミュニケーションズさんに会場をお借りしましたが、綺麗で広くて良かったです。スクラム道のWebサーバについてもご提供頂いておりありがたい限りです最近Scrum Boot Campばっかりだった気がして、久々に道場だったのでやり方を忘れてた（汗完成の定義は書籍には、それを作れ、としか載って
The Scrum Guide
Scrum is defined completely in the Scrum Guide by Ken Schwaber and Jeff Sutherland, the originators of Scrum. The Scrum Guide is maintained independently of any company or vendor and therefore lives on a brand neutral site. The Scrum Guide is translated and available in over 30 languages. You can read and download the Scrum Guide here. This site contains both the 2020 and 2017 versions of the
グラス片手にアジャイル開発 第5回（後編） － アジャイル開発によくある課題と解決方法
バックログ 第3回でも触れたように、全体のタスクを管理するのに重要なのがバックログです。アジャイル開発では始めからすべてを詳細化はしません。優先度は低くとも重要で粗い要求までもリストアップするプロダクトバックログ、次のリリースのためのリリースバックログ、直近のスプリントのためのスプリントバックログの3つに分かれます。 スプリントバックログ自体は、タスク管理システムに統合されれば、あえてバックログ単体として意識することは少ないかもしれません。プロダクトバックログとリリースバックログは詳細化しすぎず、全体感を捉えきれる程度（例えばExcelでリストする程度）で良いでしょう。 タスク管理システム スプリントバックログに相当する部分は、タスク管理システムを中心に据えることが多いです。"チケット駆動開発"（すべてのタスクにチケットを発行して管理）といった言葉に代表されるように、間接タスクも含めてすべ
プランニングポーカー かんたんガイド 作りました。 - kawaguti’s diary
デブサミで、ご希望の方にプランニングポーカーを有償でお分けしました。一個単位で輸入すると送料がばかにならないのですが、弊社で多めに買ったものをお分けしており、少量でもコスト安く手に入ります。 (2014年現在は行っておりません。アギレルゴコンサルティング社にお問い合わせください。) Mountain Goat 社製プランニングポーカーカード を一個単位でお分けします。 - アギレルゴコンサルティング株式会社 残念ながら在庫が十分に足りず、ご興味を持っていただきながら手に入らなかった方がたくさんいらっしゃると聞きました。弊社の方でもほそぼそとお分けしておりますので、ご興味のある方は、ご検討いただければ幸いです。ほとんど原価販売です*1。 ※2012/2/20追記: 日本マイクロソフトの長沢さんがノベルティとしてプランニングポーカーを配布されていますので、そちらもご参照ください。 使い方の説明
プランニングポーカー・オブジェクトゲームでアジャイルゲーム！～Agile 2011 Conference
プランニングポーカーでアジャイルな見積もりを！ 今回は、4日目に行われたJames Grenning氏による「Beyond Planning Poker - The Planning Poker Party」の様子を紹介します。アジャイルマニフェスト起草者の一人であるJemes Grenning氏は「プランニングポーカー」という見積もり手法を定義した人物であり、組み込みのC言語におけるアジャイル開発の第一人者としても知られています。セッション概要は次の通り。 世界中の人々がプランニングポーカーから発見を得ているだろう。プランニングポーカーは技術として役立つものだが、ただのゲームではない。ゲームのルールを知っているだけでは、「見積前ストーリーの大群」の前では正しく機能しないことがある。このセッションでは、プランニングポーカーやその原則、別の利用方法などを紹介する。そして、プランニングポーカ
アジャイルソフトウェア開発宣言
私たちはソフトウェア開発を実践あるいは実践の手助けをする ことによって、よりよい開発方法を見つけだそうとしている。 この活動を通して、私たちは以下の価値に至った。 プロセスとツールよりも個人と対話に。 包括的なドキュメントよりも動くソフトウェアに。 契約交渉よりも顧客との協調に。 計画に従うことよりも変化への対応に。 すなわち、左側に書かれたことがらに価値をおきながらも、 私たちは右側に書かれたことがらにより価値をおく。 Kent Beck Mike Beedle Arie van Bennekum Alistair Cockburn Ward Cunningham Martin Fowler
スクラム道バーストに参加した感想＆doneの定義の話
2011/06/24にスクラム道バーストに参加してきました。申し込みを忘れていたのですが、当日行けそうに無かった方のご好意で代わりに参加してきました。@ledsunさんありがとう。 内容は過去のスクラム道の再演とトピックに対する議論の場でした。詳しい内容は他の方の素晴らしいレポートがあるのでそちらをご参照くださいw 選手ってなに？ってことが良くわからないまま選手として参加してしまいましたが、壇上に上ってもそんなに緊張しないものですね。変なこと言っても殴られたりしないので、このような形式があったらどんどん選手として名乗りをあげるといいと思います。 スクラム道バーストで「doneの定義を拡大/縮小することの是非」がトピックに上がりました。思い返すとストーリーのdoneの定義なのかタスクのdoneの定義なのかがあやふやだったので、それぞれ検討しました。 結論としては、拡大するにしろ縮小するにしろ
スクラム提唱者から学ぶ、チームの不幸を減らすたった2つの方法
スクラム提唱者から学ぶ、チームの不幸を減らすたった2つの方法：スクラム提唱者が教える、チームの不幸を減らす方法（1/2 ページ） スクラム提唱者のジェフ･サザーランド氏を講師に招いた、日本初の「スクラムアライアンス認定プロダクトオーナー研修 レポート」レポート。チームも顧客も不幸な状態をなくす方法は実にシンプルだ。 2011年はアジャイル実践者にとって歴史的な年となった デスマーチ続きでリリースは遅延、チームはプレッシャーを受けてマネージャはてんてこ舞い、顧客も不幸……そんな状態を良い方向に転換する方法はたった2つである――「スクラム」提唱者の1人である、ジェフ・サザーランド氏の言葉です。 1月11日と12日、サザーランド氏による日本初のスクラムアライアンス認定プロダクトオーナー研修（Certified Scrum Product Owner 研修、以下CSPO研修）が開催されました。翌日
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
いまアツいアジャイルプロジェクト管理ツール9選＋Pivotal Tracker入門
かんばん！～もし女子高生がRedmineで「スクラム」開発をしたら
塹壕より Scrum と XP
グラス片手にアジャイル開発 第5回（前編） － イテレーション単位のアクティビティ
)
バックログ ビューで使用できる機能 [リダイレクト]![バックログ ビューで使用できる機能 [リダイレクト]](https://cdn-ak-scissors.b.st-hatena.com/image/square/d6e4cb632c7025e9f5e05fd314fbf6dcd6144e8d/height=288;version=1;width=512/https%3A%2F%2Flearn.microsoft.com%2Fen-us%2Fmedia%2Fopen-graph-image.png)
)
イテレーションの完了 [リダイレクト]
スクラム道.03 スプリント計画ミーティング