スクラムじゃなくても良かったのだ - ちなみに
この記事は クラスター Advent Calendar 2022 (2枚目) 2日目の記事です。 クラスターではサーバーエンジニアをしている id:Sixeight です。 まだ入社エントリも書いていないのですが、アドベントカレンダーの空き枠があったので慌てて筆を執りました。 1枚目のカレンダーにもエントリーしているので、そちらで入社エントリを書く所存です。 さて表題ではあえて強めの言葉を使いました。 これまで所属していた会社ではスクラムを採用していることが多く、それどころか私自身がスクラム推進派でした。 しかしながら転職してからスクラムのスの字も出てこない環境で働いているのですが、これまでよりも調子良く働いているうえに組織の生産性は高く感じています。 この記事ではなぜそう感じるのかということをさらっとまとめたいと思います。なぜなら突然思いついて時間がないからです。 スクラムとは スクラム
新米スクラムマスターがスクラムを導入してみた
先日、会社で初めてスクラムを導入してみた。 以前から開発プロセスをもっと改善できないかなーと思っていて、前々から気になっていたスクラムを取り入れたいと思って提案したら、なんかめちゃでかいプロジェクトのスクラムマスターになってしまった…😇 なんとか無事にスタートを切れたので今後の改善のために現時点での状況や気持ちを書いておこうと思う。 前提条件スクラムチームの規模開発チームが9名。スクラムではギリギリな大所帯。かつ、1名リモートワークがいる。 プロダクトオーナーは元々プロダクトを管理していた方にやってもらった。決定権限も持つような形にできたので良かった。 スクラムマスターの俺は対象プロジェクトの開発はやっていなかったので逆に第3者的な目線で入れてやりやすかったかもしれない。 対象プロジェクトの状況機能開発をガツガツやっていくようなフェーズで、関係者やユーザさんから改善要望がひたすら上がって
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
