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が最近リリースされ、重要な変...
■ スクラム実践入門の紹介 2013年末から1年くらい執筆やら編集やら取りまとめやら続けていたスクラム実践入門が本日発売開始しました。 この本は 2013年末くらいに同僚のあんちぽくんと一緒に自分たちがソフトウェア開発をする時に役に立つ本を書こうと @inao さんに提案したのがきっかけです。git log -p --reverse の1コミット目はこれ commit 710fc0c8cd065ceb24904a6f26bf21ac22d9ddf2 Author: SHIBATA Hiroshi <shibata.hiroshi@gmail.com> Date: Sun Dec 15 02:26:33 2013 -0800 Initial commit diff --git README.md README.md new file mode 100644 index 0000000..5a
アジャイル開発とスクラム 顧客・技術・経営をつなぐ協調的ソフトウェア開発マネジメント 作者: 平鍋 健児、野中 郁次郎出版社/メーカー: 翔泳社発売日: 2013/01/18メディア: 単行本（ソフトカバー） 3部から構成され、全部で10章から構成されます。 第1部「アジャイル開発とは何か、スクラムとは何か」は、平鍋氏が執筆されており、アジャイル開発およびスクラムが分かりやすく解説されています。普段、アジャイル開発の手法を取り入れて開発をしているのであれば、日々の開発活動と対比しながら読むことができると思います。完全なウォータフォール開発しか経験したことがない人にとっては、なかなかピンとこないかもしれませんが、アジャイル開発とウォータフォール開発の違いを理解することができると思います。 「スクラム」という言葉は、本書の共著者である野中 郁次郎氏が竹内弘高氏と共著した"The New New
みなさんこんにちは。@ryuzeeです。 よく聞かれるネタではあるのですが、スクラムの父ジェフ・サザーランド氏がストーリーポイントの見積りがなぜ時間の見積りよりも良いかについて過去にブログに書かれたものを意訳・抜粋にて紹介します。 以下の訳文は原文にしたがって、CC BY-NC-SAとします。 原文はこちら 左図: 不確実性コーン 右図: マイクロソフトによるストーリーポイント見積りの正確性 ストーリーポイントを使うとより正確な見積りを得られ、計画の時間を劇的に減らすことができ、リリース日をより正確に予測できるようになり、チームのパフォーマンスの改善の助けになる。 時間を使った見積りは、よくない見積りとなり、システムに大量のムダを生み出し、プロダクトオーナーのリリース計画の妨げとなり、どのプロセス改善が本当に役立っているのかチームがわからなくなる。 新たな興味深い調査結果が公開された。 ス
日々の出来事、メンバーの働く様子や声、未来への想いなど、Supershipの“BE SUPER”なストーリーをシェアしています。
ScrumCrazy.com has Moved…
To contact us about our Coaching/Training services, please see the About page. So, our old content engine provider, Wikispaces.com, went out of business, so we are migrating the most important/valuable articles over to this blog, incrementally of course. Some of those are linked below. If you find yourself distraught because an article from ScrumCrazy.com that you really enjoyed is no longer acce
みなさんこんにちは。@ryuzeeです。 Scrum CrazyというサイトでスプリントのタスクについてたくさんのTipsがまとめられているのでご紹介します。 Sprint Tasking Tips ここではTipsのタイトルだけ紹介しておきますので、詳しくは上記サイトを参照してください。 Scrum Crazyでは他にも色々なTipsがあるので是非見ておくと良いと思います。 正直に見積もり、見積りが正確であることに価値をおく環境を作ることタスクを見積もる際は時間で見積もることを強く推奨実時間ではなく理想時間を使うことが望ましいより粒度を小さくしたタスクにすることを強く推奨1日は5〜6理想時間とすること作業量を見積もるのであって期間を見積もるのではないできるだけアトミックな単位にタスクを分ける「作業中」の状態が2日以上にならないようにするタスクはチームで見積もるスプリント途中での再タスキン
![[Agile]スプリントのタスクに関するTips29個 | Ryuzee.com](https://cdn-ak-scissors.b.st-hatena.com/image/square/663b4e4c6d16146fe3b8b8faa19789429caa9a96/height=288;version=1;width=512/https%3A%2F%2Ffanyv88.com%3A443%2Fhttps%2Fwww.ryuzee.com%2Fcontents%2Fblog%2Fimages%2F3959%2Fthumbnail.webp)
スクラムを利用してプロジェクトを進める際に、最初にやっておくべきことをまとめておく。 もちろん全プロジェクトでこれを全部やらなきゃいけないわけではない。そのあたりはコンテキスト依存ということで。 プロダクトゴールや価値の明確化 これから作るもののビジネス価値や製品ビジョンを明確にする プロダクトバックログの作成 もちろん全部が揃っている必要はないが、優先度が高いストーリーは明確に存在するはず。 バックログ項目の優先順位付け バックログ項目の見積もり バックログ項目の詳細化 個々のスプリントの開始前には優先順位の付け直しや見積もりの変更が行われるので、全てを詳細まで行ってはいけない。あくまで初期の1〜2スプリントが実施できる程度にとどめること。アップフロントでの計画を増やしすぎない。要求は必ず変化する。 おおよそのリリースプランニング ロールの明確化 プロダクトオーナーは誰？、スクラムマスタ
![[Agile]Scrumで開発する際に最初にやるべきこと | Ryuzee.com](https://cdn-ak-scissors.b.st-hatena.com/image/square/e28ac0c06090ef4280af681bdbe7af0aed6391ba/height=288;version=1;width=512/https%3A%2F%2Ffanyv88.com%3A443%2Fhttp%2Fwww.ryuzee.com%2Fimages%2Ffb.png)
The document appears to be a log or record containing dates from 2011 and numbers. It references IT, PC, programming, software projects, discovery sessions, product backlogs, releases, estimation, functionality, locations, extreme programming, and project management. Statistical data is presented in a graph. Several names are listed along with notes about discovery flow and XP practices.
アジャイルチームは、技術的負債を扱うタスクのように、純粋に技術的なタスクの計画に難儀する場合がある。このようなタスクは直接的にはシステムを利用する顧客のためにはならないが、問題なく動作するソフトウエアを提供するには避けて通れない。このような技術的なタスクや技術的負債を扱う場合にもユーザストーリーを作るべきだろうか。 "As a Developer…” Is Not a User Storyというブログ記事でBill Wake氏は、顧客の価値にはならないユーザストーリーについて書いている。氏が例示しているのは、"開発者として、私はJenkinsを構成して継続的統合を実現したい"というようなユーザストーリーだ。これをユーザストーリーと呼ぶべきでない理由を氏は説明する。 これらの活動はよいものでもないし重要でもないと主張したいわけではありません。しかし、このような活動をユーザストーリーとして捉え
ユーザーストーリーは文章、またはカードのことだと考えてしまう数行のコードで済んでしまうことまで、全てストーリーを書き起こしてしまう明確な受け入れテストがないストーリーを十分に小さな単位まで分割していない（ビッグストーリー）ストーリーの分割が正しくないプロダクトオーナーの事情を無視するプロダクトオーナーがボトルネックになっている「誰々として、何々する」の雛形にこだわりすぎてしまうタイトルや中身の記述にこだわりすぎてしまう詳細に記述することにこだわりすぎてしまうあいまいさが多すぎる実装方法を特定しすぎている言葉でのコミュニケーションが重要だということを認識していないすぐに言葉でのコミュニケーションでなんとかしようとし過ぎる
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
