"スクラム"投稿一覧

北野勝久

エンジニア

スクラムにおけるプロダクトオーナーだと理解して回答をしますが、プロダクトオーナーの役割は「プロダクトの価値を最⼤化」することで、スクラムにおけるイベントは、スクラムが重視する「検査」「適応」「透明性」の3つの価値観を体現する場です。
この2つの視点から考えていくと、私なら、以下のようにプロダクトマネージャーに提案すると思います。

## スプリント内で実施するもので必... 続きを見る

Dai Fujihara

プロジェクトマネジメント

「アジャイルコーチ」と名乗って仕事をしているものです。

厳密に言うと「アジャイルコーチはこうだ」という定義はないと思います。また、コーチとは名乗っていますが、純粋なコーチングを広めているICF（国際コーチング連盟）のコーチングとも関連性はありません。

僕の仕事内容は、ざっくりまとめると「アジャイル開発の支援をする仕事」です。広く言うと「ソフトウェ開発に関... 続きを見る

Dai Fujihara

プロジェクトマネジメント

スクラムガイドに目安の時間が書かれているので、ご自身の状況に合わせてみてはどうでしょうか？

スクラムガイド
続きを見る

北山 淳也

エンジニア

先に回答している松永さんの回答が完璧すぎて追加で書くことが全く思い浮かばないので乗っかりみたいな話になってしまいますが、
アジャイルは意思決定の連続というのは本当にその通りで、例えば
「BとCの機能を作らないとすればAは2週間で終わる」をGoできる意思決定者を置けるか置けないかはとても重要だと感じています。

まずもってソフトウェア開発というのはとても困難で... 続きを見る

北山 淳也

エンジニア

スクラムマスターが必要な組織と
その組織で行われるスクラム開発ではスクラムマスターが必要であり
スクラムマスターが不要だと思う組織と
その組織で行われるスクラム開発ではスクラムマスターが不要です。

インフラエンジニアが必要な組織と
その組織で行われる開発にインフラエンジニアが必要であり
インフラエンジニアが不要な組織と

Dai Fujihara

プロジェクトマネジメント

スクラムに関することはスクラムガイドを読むのが鉄板なのですが、行間が広く解釈が難しい部分があるのも事実だと思います。

参考：スクラムガイド 続きを見る

kentaro haneda（jumbo）

エンジニア

PdMも会社やプロジェクトで持っている役割や職責が違うので、一概には言えませんが一般的には参加してもらったほうが意思決定や連携・関係性は良くなるように思います。
スクラムイベント全ては大変だと思うので、まずはプランニングから出てもらうなどが良いと思います。
またその場をうまく活用してもらい、PdMが持つタスクをバックログアイテムとして分担するというやり方もあると思います。

Dai Fujihara

プロジェクトマネジメント

お客さんに説明するときは、こんな感じで説明しています。

アジャイル開発は「もっと良い開発をするための考え方」です。
考え方だけでは、実現が難しいので、スクラムという「方法」を使います。方法にはXP（エクストリームプログラミング）やかんばんなど、様々な種類があります。

さらにいうと、様々な方法にはプラクティスが用意されていることがあります。プラク... 続きを見る

松永広明

プロジェクトマネジメント

スクラム（アジャイル）でつらいのは、従来型の開発に対して大きく考え方を変えること、いわゆるパラダイムシフトを要求されることだと思います。代表的なのはまさに質問者様がおっしゃったようなことです。
それ以外にも、
・仕事は全部やってはいけない。
・スケジュールは立てない。
・指揮命令はしない、されない。
・量よりも質（価値）が大事。
などなど... 続きを見る

大橋桃太郎

プロジェクトマネジメント

非常に忙しいのは同感なんですが、deliveryと高い共通認識をもつことの優先度は高く(実際にクオリティやスピード、インパクトにも影響が)、またそれがdeliveryを主に担う人がdiscoveryの解像度を高めることにも繋がるので、率先して時間を使うべきテーマだと思います。うまくワークすれば、忙しさの幾分かを解消するものでもあり、「チームでいいものづくりをしよう」なテーマの話し合いからまずはして... 続きを見る

石垣雅人

プロジェクトマネジメント

スクラムというのは型なので、ただ型を入れているだけだとそれに従って動いているロボットみたいになってしまいます。
基本的に型を入れたときに、ちゃんとそのチームに合ってるいかどうか、差分を見つけ出すのが大事です。

例えば、前のチームだと「スプリントレビューっていらないよね」という話だったり、そもそも常にコミュニケーションを取ったり、POがちゃんとスプリントのレビューに入... 続きを見る

石垣雅人

プロジェクトマネジメント

一番の課題は、見積もりをしないと言いつつも、チーム外に出たときには変換コストがかかるので、そこを上手く何か繋げるようにしたいことです。
結局そこで工数を見積もったらかなり時間がかかることは変わらないので「スクラムチームの外に出たときには、どうするべきなんだっけ？」というのは考えていきたいなと思っております。

石垣雅人

プロジェクトマネジメント

チーム再編が起きたら、基本的やり直しになると思います。
タックマンモデルでいうと、最初のほうの形成期に戻ってしまうことになります。よくある話としてはやっぱりチームの過半数が変わってしまった場合、文化もガラッと変わると思うので、1個の目安としては「半分以上変わる」かなと思っています。

例えば、今あるチームに新卒が1人来てとか、そういったことであれば全然問題ないのですが... 続きを見る

石垣雅人

プロジェクトマネジメント

自分たちが自分たちでちゃんとそのチームが信頼できるようになるかが結構大事なところで、やっぱりチーム組成した段階でいきなり見積もらないのは結構むずかしいところはあると思うので、ちゃんとフェーズを踏むのが大事かなと思っています。

まずは一回、ストーリーポイントや時間見積もりとかをやってみて、やっていく中で「自分たちってこんなことしなくていいんじゃないか？」という、自分たちが自分た... 続きを見る

石垣雅人

プロジェクトマネジメント

大事な観点としてスクラムは型であり銀の弾丸ではありません。なので、今のチームに導入しながら差分をパターン・ランゲージとして表出化→形式化してチーム独自のやり方を構築していく意識が大事です。

型を鵜呑みにしてたくさん時間をかける、かけても大丈夫なんだというのは、結構現場がしんどくなる一因でもありますので、やっぱり気をつけるべきところに関しては「トレードオフが何なのか」というとこ... 続きを見る

Dai Fujihara

プロジェクトマネジメント

アジャイルコーチとして現場支援をするときに、立ち上がり始めたチームや、まだスクラムが安定していないチームの場合は、まずはベロシティを扱うことが多いです。その場合は、以下のようにしています。

・スプリントごとにベロシティを出すアクションを行う。とりえあず出そうぜ！です。
・次に、ベロシティをグラフにしてトレンドを出し、トレンドをスクラムマスターに解説してもらう。ベロシ... 続きを見る

Takuo Doi

エンジニア

ちょっと語弊のある言い方かもしれませんが、管理する、予測することに価値を置いている開発においては、No Estimateは適さないのではないかと思います。

ストーリーポイントを見積ることにより、スプリントゴールの設定に根拠を持つことができます。
ストーリーポイントを見積り、ベロシティを計測することで、リリースの目安を算出することができるようになります。
<... 続きを見る

大橋桃太郎

プロジェクトマネジメント

最近スクラムを導入しはじめました！現在はチームで試行錯誤している状況ですが、スクラムマスター経験のある方にスクラムマスターの役割をお願いしています。

理由としては導入プロセスだから、というのが大きいですが、いる/いないでは大きく生産性に関わっていると感じています。

職種を超えたチームワークであるプロダクトづくり、さらに不確実性の高いスタートアップ事業とな... 続きを見る

森健太郎

エンジニア

チームのスキルや経験に影響があると考えます。
見積もらないアプローチでは、チームのスキルや経験がプロジェクトの進行に影響を与えることがあります。
スキルの不足や経験の乏しさが、タスクの遂行や進捗に影響を及ぼす可能性があるかと考えます。

Dai Fujihara

プロジェクトマネジメント

取り組み素晴らしいですね。

あえて、追加するなら、環境問題の対応でしょうか。

品質改善の依頼をうけたときによく直面するのが、環境の問題です。本番だとおきちゃうバグとかがだいたいあるので、「本番に近い環境を用意しよう」や「本番で安全にテストしよう」というアクションを取られるケースが多いです。

データを引っこ抜いてマスクして・・・が面倒...