GGG

プログラミング言語やソフトウェア開発について思ったことを書いてます

スクラムを知る

最近、スクラムという開発プロセス?をよく記事などで見るようになった。

ちょっと気になったのでどんなものか興味があったので読んでみた。

 

〇タイトル

スクラム実践入門

 

スクラム実践入門 ── 成果を生み出すアジャイルな開発プロセス (WEB+DB PRESS plus)

 

3-8人程度の人数を1チームとして想定しているメソッド

実際のやり方はおいていて思ったことを書く。

 

PDCAサイクル

チームで問題点の共有やスプリントと呼ばれる数週間単位で振り返ることで

改善しやすい環境が生まれる。PDCAサイクルを自然に取り組めるようになる。

チームのメンバに自主性を持たせることによる。

コミュニケーションもよくとれるようになりそうだ。

 

〇開発スピードアップ/属人化を排除/チーム力向上

タスクを洗い出し可視化することで個人が抱えてるタスクを見えるようにする。

取捨選択、優先順位の設定やチームでの作業分散により個人への負担集中を軽減し属人化を減らせる。作業分散をすることで、各メンバも本人にとって新しいことにトライできる環境が整いレベルアップも自然とできそう。

 

>今の職場で考えると

類似していることは少しやってる。しかしスクラムアジャイルをやっているという意識はなく、どこかでやっていることの真似事。振り返りはあまりやってない印象。

 

・デイリースクラムに相当する朝会的なもの。

 → 意識的かは不明だが、話が長くなりそうなら自然と二次会的なこともやってる。

・スプリントバックログに相当するタスクボードによる可視化

 → 形骸化してる。

   事前にタスクを洗い出すということはしていない。

   個人が今やってること、これからやること。終わったことを上司が把握するためのツールとしてタスクボードで可視化してる。

   タスクの粒度(期間など)は個人に依存している。

   タスクボードに貼らずに口頭で話して終わりの人もいる。

   上司があとでタスクボードに書いてる(泣

   

いきなりスクラムやりましょうと提案すると絶されそう。

トップダウンだとみんなやるんだけどな・・・。

類似していることは少しやっているので、改善活動としてひとつひとつスクラムに近づけていくことが良いのかもしれない。時間だけはかかりますな。

 

ブラウザで見れるようなデジタルなツールよる可視化もいいけど

ホワイトボードなどを使ったタスクボードは自然と目に入るので

アナログの方がいいかもしれない。