スクラム開発の現場にJoinして失敗した俺が悪い話 - Qiita
ほぼノー知識でスクラム開発の現場に乗り込んで失敗した話を書き記します。 「なぜスクラムは上手くいかないのか」「スクラム開発のアンチパターン」などチームにフォーカスした記事はあれど、個人にフォーカスした失敗談が見当たらなかったので書こうと思いました。 はじめに 大前提として、その現場が悪かったとかスクラム開発が悪いとかそういったネガティブキャンペーンをするつもりではありません。 ウォーターフォールと比較して、継続的にプロダクトを作って完成に近づけていくスクラムのメリットは十分理解しているつもりです。 その中で自分が「あ、無理かも」と感じてしまった理由を記して同じ立場に立ってしまった人の救いになれればいいなと思い記します。 概要 AWSを基盤とするインフラ開発の現場Joinし、スクラムメンバーとしてプロダクトを開発する役目を受けました。 結論から言うと2週間のスプリントでベロシティを上げること
スプリントの属人性を減らしたらベロシティが安定した話 - Commune Engineer Blog
【2022/07/04追記】 この記事の結果に至るまでを示した補足記事を書きましたので、良ければ見て頂けると嬉しいです。 tech.commmune.jp はじめに これは何？ 誰向けの記事？ 自己紹介 前提：「ベロシティの安定」とは 取り組み導入の背景 属人性を減らす取り組みの一覧 ① WIP制限 どうやったか 得られた成果 補足 ② タスクサイズの制限 どうやったか 得られた成果 ③ 死亡前死因分析（プレモーテム） 死亡前死因分析とは？ どうやったか 得られた成果 全ての取り組みの結果 得られた成果 何故この成果を得られたか？ 注意点 まとめ 最後に はじめに これは何？ スプリントの属人性を回避しようと取り組んだらベロシティが安定したので、実際に行った以下の取り組みを紹介する記事 WIP制限 タスクサイズの制限 死亡前死因分析 誰向けの記事？ スクラム最初の壁であるベロシティの安定化
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
