CS 開発(CS 部門で CS 関連のシステム開発を専門に行うチーム)ではチケット駆動開発を採用していました。
CS 開発の業務は開発・保守・CS 調査依頼対応が混在しており、割り込みの頻度が非常に高いです。また開発規模やリリースのサイクルが様々なので、タイムボックスに縛られない方が効率的でメンバの精神的ストレスも低くなります。(cf. アジャイルサムライ pp.198-201)
ですので CS 開発ではシンプルなチケット駆動開発が適していました。
(「CS 開発ではイテレーションではなくカンバンを採用していました。」と Tweet しましたが、複数工程間でプルしていくまではしていないのでカンバン(Kanban)ではないですね。)
社内で「エッセンシャル スクラム」を読みたい人が集まって勉強会をすることにしました。今日が第1回。毎週1章ずつ進めていく予定です。
事前に読んで興味を抱いた場所を意見交換するぐらいかなぁと勝手に思っていたのですが、当番の人がサマリーやプラスαの考察・勉強会での議題などをまとめたスライドを用意してきていていてビビリました。輪講っぽい。
第1章では
「ワリコミ駆動の作業」「スクラムは、割り込みが多すぎる作業にもうまく合わない。」「割り込み駆動の環境では、カンバンと呼ばれるアジャイルアプローチを採用することを検討するとよい だろう。」「カンバンが適しているのは、ソフトウェアの保守とサポートの領域だ。」
と書かれているのが興味を抱いた箇所。
昨年度まではCS 開発チームとして割り込みを意識した開発プロセスで進めてきました。全部が割り込みではなく、主体的な開発もあったのでもしかしたらスクラムとハイブリッドでやってみるという選択肢もあったのかもしれないなと感じました。
来週当番です。
「プロダクトバックログアイテムについては何もコミットしない」で各自好きなことをして良い1週間スプリントが終わったのでチームでふりかえりました。
このチームが自主的に決めたワーキングアグリーメント(記事)に
スプリントゴールが全て達成された場合は、優先する割り込みタスクがあれば対応し、そうでなければ準備完了になっていないプロダクトバックログアイテム(PBI)に関する情報収集・まとめを優先度の高いものからしよう。」
というのがあり、この活動をしていたメンバが多かったです。「スプリントバックログが空 = ただちにスプリントゴールが達成されたので PBI の準備に取り組んだ」わけですね。
環境整備にあてたりとかはあまり多くなかったようです。シェルの設定見直しをしたエンジニアは「失敗したら1日潰れてしまいそうで普段やれなかったことをできた」とやって良かったと言っておりました。
開発メンバからは以下のような意見が出ました。
自由になったことで、普段やっているアクティビティの良さを再認識できたようです。チームが取り組んでいるプロダクトの状況から考えるとスクラムではなくカンバンの方が進めやすいのかもしれないのではと私は考えていたのですが、今回の取り組みで開発メンバは「スクラムで続けたい」と改めて思ったとのことです。
スクラムの基本からは外れる取り組みではありましたが、基本通りにやっていたのでは感じ考えることのことができないことを得られたという意味では非常に有意義な1週間でした。
今日のおやつは妻おすすめの濃密カヌレにした。ペロペロッと食べてしまった。 pic.twitter.com/mGSH9CNPvl
— Naney (@Naney) October 14, 2022
Naney (なにい) です。株式会社MIXIで SNS 事業の部長をしています。
※本サイトの内容は個人的見解であり所属組織とは関係ありません。