スクラムを組織全体へスケールさせていくフレームワーク「Scrum@Scale」入門（前編）。Developers Summit 2019
スクラムを組織全体へスケールさせていくフレームワーク「Scrum@Scale」入門（前編）。Developers Summit 2019 アジャイル開発手法を実現する方法として、もっとも普及しているのが「スクラム」でしょう。 スクラムを開発チームの単位で導入している企業は増えてきましたが、これをスケールさせる、つまりスクラムの手法を使って組織全体をより早く動かし、より早く価値を届けていくにはどうすればいいのでしょうか。 そのために開発されたのが「Scrum@Scale」フレームワークです。スクラムをスケールさせる仕組みの背後にあるスケールフリーネットワークや、大きな組織でも迅速に情報を共有する手法が組み込まれた「Scrum@Scale」について、2019年2月に行われたイベント「Developers Summit 2019」で株式会社アトラクタの代表取締役 原田騎郎氏が説明しています。 本
スクラムで失敗する5大理由とその対策としてできること | POSTD
スクラム とは、最近、特にソフトウェア開発の分野でよく使われているバズワードです。この概念は、1995年のOOPSLAでJeff SutherlandとKen Schwaberにより提唱されました。自己組織的なチーム構成と短いスパンの持続可能な繰り返し作業に重点を置くもので、複雑なソフトウェア製品やプロジェクトを扱うためのすっきりとした軽量なフレームワークです。 シンプルで軽量な性質を強みとするスクラムですが、これを導入している企業の約半数が正しく実践できていないと思われます。では、一見すぐに使えそうな手法なのに、実践するのが非常に難しいのはなぜなのでしょうか。その理由と、これを確実に成功させるために講じるべき対策を見ていきましょう。 1. 組織の賛同が得られていない どういう タイプの企業であろうと、何かを変えようとすれば必ず直面する最大の課題であると言えるのが、これです。スクラムも例外
スクラム向けプロジェクトマネジメントツールを比較した結果 Zube.io を推してみる - Witch on the Other Shore
Agile なみなさんこんにちは。みなさんは Scrum プロセスを実施するにあたり、プロジェクトマネージメントツールとして何をお使いでしょうか。 最近当社で使い始めている Zube.io を推してみるというエントリです。 Zube.io の話に入る前に、Agile/KANBAN/Scrum なプロジェクトマネジメントツール（SaaS型）についておさらいします。 我々に与えられたおもな選択肢（おさらい） 比較表というほどのものではないですが、使用したことのある主だったサービスを列挙します。SaaS で提供されていないものや、KANBAN でないものは今回選外です。 サービス 特徴 Jira やりたいことは（設定がうまくいけば）なんでもできる。 ただ設定がうまくいかない Asana 優れた KANBAN ツールとして使えるが Scrum 向きではない Trello 人気の KANBAN ツー
たまに「スクラムが難しい」って相談があって見に行ったりする。 - Mitsuyuki.Shiiba
「プロダクトオーナーとしてやることはしっかりやってるんです」 「もちろんバックログがあります。そして、ストーリーが優先順にならべられています」 「MVP(Minimum Viable Product)も考えていて、ここまでが必須だと考えています」 「そしてこのMVPをこの日までにリリースしたいと考えているんです」 いいですね。 でも、ストーリーポイントを見たところ難しそうですね。 「そうなんです。もうプロダクトオーナーとして自分ができることは全てやりましたから、あとは開発チームに、この日までにリリースできるようになんとか頑張ってもらうしかないと思っています。スクラムではこういうときどうしますか？」 そうですね・・・。まずは、実現できないということを受け止めましょう。 「え？」 そして、ここで頑張るのは開発チームではなくてプロダクトオーナーですね。 「もう自分のできることは全てやっていますよ
現役スクラムマスターが考える「こんなプロダクトオーナーは嫌だ」
1. The document discusses trends in information and communication technology (ICT) from 1995 to 2020, noting the rise of personal computers in 1995 and predicting 7 billion internet users by 2020. 2. It also covers the growth of ICT-related fields like smartphones, social media platforms, and 3D printing. Various ICT education programs are introduced, including a one-day project camp and a summer
スクラムにおける技術的スパイクの進め方
みなさんこんにちは。@ryuzeeです。 スクラムでは、スプリントに投入するプロダクトバックログアイテムはReady（準備ができている）である必要があります （Readyとはどんな状態なのかについては以前に詳しく説明したので、そちらを参照してください）。 Readyにしておくことによって、成果の量が安定しプロダクトオーナーやステークホルダーにとっては予測精度が向上していきます。 Readyにする活動は単に受け入れ基準を用意したり、プロダクトバックログの内容を精緻化したり、並べ替えたりするだけではありません。 スプリント内でプロダクトバックログアイテムが完成する可能性を上げるために必要な活動すべてが含まれます。 そしてその中の1つが技術的な調査です。 スプリントでプロダクトバックログアイテムに着手してから実現方法を調べたり、技術的な制約によって大幅な方針転換したりするのでは遅い上に予測性が低
エンジニアのためのTrello徹底活用術！ Pairsのエウレカが、プロジェクトの透明性を確立できた理由 - エンジニアHub｜若手Webエンジニアのキャリアを考える！
エンジニアのためのTrello徹底活用術！ Pairsのエウレカが、プロジェクトの透明性を確立できた理由 ソフトウェア開発では、手法やフェーズに応じて適切にツールを使い分けることが重要です。株式会社エウレカが、主力サービスのPairs開発チームで実践しているTrelloを活用したタスク管理のノウハウや考え方を紹介します。 初めまして。株式会社エウレカのCTO Office責任者、梶原成親（@kajinari）です。 エウレカが目指すのは自立・自律した組織。全社でスクラム（Scrum）開発を推進し、強いチーム作りをするのが私のミッションです。 管理ツールもさまざまに使い分けていますが、スクラムに合っていると感じるのは、タスク管理ツールのTrelloです。私はもともとアトラシアンのユーザーグループで、東京代表のオーガナイザーを務めていました。Trelloは、アトラシアンが買収したのを機に使いは
スクラムで開発チームが自由な取り組みをするには？
みなさんこんにちは。@ryuzeeです。 スプリントをずっと回していると、「いつもスプリントに追われている気がする」「一回立ち止まってゆっくり考えたい」「情報共有ができていない気がするので整理したい」「技術検証をもっとやりたい」「勉強時間をとりたい」といった話を聞くことがあります。 それに対して、どのように対処していくべきか考えてみましょう。 考えられる対応策はいくつもあるので、まずはそれを列挙します（ダメなものも混ざっています） 複数回スプリントを実施したら、1回分のスプリントでは開発チームは好きに活動する（✕）スプリントとスプリントの間に休憩を入れる（✕）フィーチャー開発以外の取り組みを行うスプリントを必要に応じて用意する（△）スプリントのキャパシティを見直して、開発チームが持続可能なペースで働けるようにする（◎）それぞれを順番に見ていきましょう。 複数回スプリントを実施したら、1回分
「開発をアジャイルで」「でも契約は一括で」と言ってくる顧客がいたらどうすべきか？ - ミッションたぶんPossible
はじめに このブログでは言及してませんでしたが、宣言どおり無事転職して、今年の1月から新宿のSIerで働いています。まぁその辺の話は来月あたりの暇な時にでも書くとして*1、今回は別の話。 ついこの間、その新会社で、PM的役割をこなす社員を対象に開かれた「法務研修」という名のついた社内セミナーに参加しました。内容は、SIerの立場で契約に携わる時にどうすべきか、というもの。SIerあるあるの契約にまつわる揉め事を事例に、それを回避するために何に気をつけるべきか、といったことが扱われました。まぁこれ自体は目新しい内容ではなく、SIerに所属する者なら当然知っておく・気をつけるべきことばかり。再確認という意味では非常に有意義でしたが、それ以上でもそれ以下でも無かったなぁ、というのがオレの率直な意見でした。……研修本編終了までは。 ちょっとこれ大丈夫か、と思ったのは、Q&Aに入ってから。社員の誰か
【資料公開】トヨタ生産方式の基本と考え方
いまは時間があるので呼ばれればお伺いして相談にのったり、社内勉強会で喋ったりしているのですが、珍しく毛色の違う話をしてきたので資料を公開しておきます(内容は非常に基礎的な話です)。 呼ばれた先でよく言われるのが「スクラムがうまくいっていない」「スクラム的に正しいかどうか分からない」「DevOpsになかなか切り替わらない」といった話なのですが、 そういうのを聞くたびに危ないなぁという感覚を持ちます。スクラムをやるのも、DevOpsな方向に進めるのもビジネス上の目的や課題があるからそうするはず(すなわちスクラムをやるのは目的じゃない。クラウドも同様)なのですが、どうも話が手法やツールに関連する話に閉じてしまう。もしくは本当に開発部門が全体の中での一番の問題なのかも分からないうちに、「開発」側だけの観点でみて全体のプロセスを大きくいじくろうとしてしまうケースもあるようです。(仏作って魂入れず、み
最近の開発フローの改善と、「スプリントおじさん」という取り組み - しるろぐ
ここ最近、自分が見ているプロジェクトの1つで、うまくスケジュール通りに作業が進んでいなかったので、その対策をした。 その中でも特に効果があった2つを紹介する。 背景 簡単にプロジェクトの背景を説明する。 スクラムっぽい開発をしている スプリントの期間は2週間 スクラムマスターはいるが専任ではない すでにリリース済みで運用中のWebサービスである 基本的によくあるスクラムっぽい感じで、2週間というタイムボックスの中にチームが作業可能なストーリーを突っ込んで、ひたすら消化する。 スプリントの最後には、レビューをして、次のスプリントの計画を立てる。 スクラムマスターは、一応自分が担当しているが、専任ではないし、他のプロジェクトも見ているので、注意深くチームを見れていない。 課題 以下のような課題があった。 バグの修正や問い合わせ対応など、計画時に含まれていなかったタスクがスプリント中に増えてしま
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
スクラムチームをやめて、20人でカンバン運用してきた半年間の軌跡 / Stop Scrum Start Kanban
スクラムの取り組みと「全員同席」の真価