nDiki : 開発

2017年4月14日 (金)

第23回 エッセンシャル スクラムを読む会 (最終回)

rimage:/nDiki/2017/04/14/2017-04-14-092915-nDiki-800x1200.jpg

社内で「エッセンシャル スクラム」を読みたい人が集まる勉強会の23回目。第23章 未来へ。ついに最後の章です。

スクラムは継続的な改善の一形態なのだからこれが最終形態というものは無いし、どのチームをとっても同じというものは無い。プラクティスはあってもベストプラクティスはチームによって違う。準備ができていないからスクラムを始められないというのはそもそも原則に反するので、まずやって学ぼう。現状を変えるよりもスクラムを無視したりスクラムを変更したりすることの方が簡単だけれど、組織を変するために協力しあいながら確固たる信念をもって立ち向かおう。

そんなメッセージを本章から受け取りました。

第1章の「スクラムは役に立つか?」で出た通り全ての領域でスクラムが適しているわけではないので、盲目的に導入すれば良いというものではなく、領域が変わった場合はスクラムを続けるか続けないかの判断が必要になるのでしょう。もし取り組む領域が「複雑な領域」であるならばスクラムフレームワークはとても強力だということは間違いありません。

「エッセンシャル スクラム」と「エッセンシャル スクラムを読む会」そしてなによりこの半年のスクラム開発経験でスクラムについて多くを学ぶことができました。「エッセンシャル スクラム」は「スクラムガイド」を読んだだけでは得られない広範囲な知識やノウハウが詰まった良い一冊でした。

エッセンシャル スクラムを読む会ふりかえり

エッセンシャル スクラムを読む会を終えたあとは、オフィスのコラボスペースでビールを飲みながらお疲れさま会。参加の皆さんお疲れさまでした。この回を始めてくれたはらかち氏に感謝。休まず毎回参加してディスカッションしたことでいろいろな学びを得ることができました。嬉しい限りなので珍しく私もビールで乾杯しました。いっしょに全回参加した2人のうちの1人である RabbitFake 氏も特にお疲れさまでした。

ふりかえって出てきた話題としては

  • 取り組む領域がクネビンフレームワーク(第1章)のどの領域なのかを見てスクラムを採用するかどうか考えたい。
  • チームメンバでエッセンシャル スクラムを読むことで「PBI」などの同じ理解で使える言葉が増えた。チームの共通言語作りに貢献できた。
  • 原則大事(第3章・第14章など)。
  • WIP を下げる重要性をあらためて学んだ。
  • 準備完了の定義・受け入れ条件が重要。

などが上がりました。

また実際に読む会と並行してスクラムを行ってきた中で

などの話が出ました。

スクラム実践についての「検査と適応」をタイムリーに勉強会をしながら進められて学びの多い半年間でした。

全23回

エッセンシャル スクラム: アジャイル開発に関わるすべての人のための完全攻略ガイド

スポンサード リンク
[ 4月14日全て ]

2017年5月15日 (月)

17新卒エンジニア配属

今年はないんじゃないかなと思っていたチームへの新卒配属ですが、トントン拍子に決まり今日から一緒に働くことになりました。よろしくお願いします!

彼女ですが入社してからの初対面ではなく、実は2013年インターンシップ開発チームにきてくれていたのでした。3年経ってまた一緒のチームになるとはその時は思っていませんでした。嬉しい限りです。最初に好きなプログラミング言語を尋ねた時に「Whitespace (難解プログラミング言語)」と返してきた逸材なので期待しております。

エルダーとしてつくのは気がつけばもう5年の12新卒エンジニア。今までの経験を活かして指導し、また相談にのってくれると期待しています。

過去の新卒配属日記

今日のさえずり: 書籍以外は箱から出して作戦行動可能になった

2017年05月15日

[ 5月15日全て ]

2017年5月29日 (月)

ホテル三日月はいい値段とか【日記】

夏に竜宮城スパホテル三日月で2泊ぐらいどうかなーという話があったのでちょっと調べたのですが、7月下旬とかだと1泊2万円超なんですね。結構しますな。

それから、アプリ開発のチームにも入ることになったので iOS アプリの開発環境を用意した方が良いかなと思ったのですが「コードは書く予定ないですよね? であれば Xcode でソースコードが見られるぐらいでどうですか」となりました。確かに書く余裕は無いですね。

仕事で使っている15インチ MacBook Pro はまだ OS X El Capitan のままなので Xcode を入れるにはまずはそこのアップデートが必要。そこからか。

[ 5月29日全て ]

2017年6月6日 (火)

アイカツ! は BGM ですよ【日記】

アイカツ! は BGM ですよ。」と言いながら新卒エンジニアがアイカツ!観てました。霧矢あおい は確認できました。開発中に動画配信流しておくの、エルダーと一緒だなと思いました。

[ 6月6日全て ]

2017年8月1日 (火)

メンテナンスフェーズに入ってきたプロダクトの保守とスクラム

メンテナンスフェーズに入ってきたプロダクトを保守しているスクラムチームのプロダクトバックログが枯渇してきました。無理に新しいことを絞り出して手を入れ続けるのが得策ではない感じに。

もはやスクラム開発には適さない領域に入ってきたのかもしれません。一段上のレベルに戻ってプランニングするのが良さそう。

[ 8月1日全て ]

2017年8月9日 (水)

何もコミットしないスプリントで各自好きなことをして得られたもの

「プロダクトバックログアイテムについては何もコミットしない」で各自好きなことをして良い1週間スプリントが終わったのでチームでふりかえりました。

何をやらなかったか?

何をやったか?

このチームが自主的に決めたワーキングアグリーメント(記事)に

スプリントゴールが全て達成された場合は、優先する割り込みタスクがあれば対応し、そうでなければ準備完了になっていないプロダクトバックログアイテム(PBI)に関する情報収集・まとめを優先度の高いものからしよう。」

というのがあり、この活動をしていたメンバが多かったです。「スプリントバックログが空 = ただちにスプリントゴールが達成されたので PBI の準備に取り組んだ」わけですね。

環境整備にあてたりとかはあまり多くなかったようです。シェルの設定見直しをしたエンジニアは「失敗したら1日潰れてしまいそうで普段やれなかったことをできた」とやって良かったと言っておりました。

どう感じたか?

開発メンバからは以下のような意見が出ました。

得られた気付きは?

  • タイムボックスの良さにあらためて気付いた(期日から逆算していつまでに何をやるということを考えやすい)。
  • 複数人で作業を見積もることで自信が得られることに気が付いた。

自由になったことで、普段やっているアクティビティの良さを再認識できたようです。チームが取り組んでいるプロダクトの状況から考えるとスクラムではなくカンバンの方が進めやすいのかもしれないのではと私は考えていたのですが、今回の取り組みで開発メンバは「スクラムで続けたい」と改めて思ったとのことです。

スクラムの基本からは外れる取り組みではありましたが、基本通りにやっていたのでは感じ考えることのことができないことを得られたという意味では非常に有意義な1週間でした。

[ 8月9日全て ]

2017年8月16日 (水)

マニャーナの法則に対する周囲の印象【日記】

開発チームのふりかえりで「(個人的に)マニャーナの法則やり始めているんだけれど、どう? (対応が遅いと感じたりする?」とメンバに聞いてみました。特に対応が遅くなったとは感じないとのこと。なるほど良かったです。

[ 8月16日全て ]

2017年9月8日 (金)

スクラムよりカンバンか【日記】

今の開発・保守のバランスだとやはりスクラムよりカンバンの方がいい気がしてきました。

メンバが1人運用当番に入ることになりチームのキャパシティが小さく不安定になるので、1スプリントで完成をコミットできるサイズが小さくなりそうです。スプリント期間を伸ばせば解決するというものでもなく。

今日のさえずり: 夜ご飯食べた。ここから眠気との勝負。

2017年09月08日

  • 08:00 今の開発・保守のバランスだとやはりスクラムよりカンバンの方がいい気がしてきた。
  • 21:49 夜ご飯食べた。ここから眠気との勝負。
  • 24:09 今晩は寝ずに起きれている。宣言したからかな。
[ 9月8日全て ]

2017年9月20日 (水)

早すぎるプロダクトバックログリファインメント

今日はスクラム開発している CS 開発チームのスプリントプランニングだったのですが、プロダクトバックログアイテムの中に見積もりした時のことをあまり覚えてないという事案が発生しました。多分1カ月ぐらい前にプロダクトバックログリファインメント済みのもの。

プロダクトバックログリファインメントであまり先まで検討しても、状況が変わって無断になる場合があるよというのは言われているのですが、それ以外にも単純に忘却してしまうというデメリットがありますね。

[ 9月20日全て ]

2017年10月13日 (金)

ソフトウェアエンジニアのスキルマップ

スキルマップ、誰がどのスキルをもっているかの表です。カスタマーサポートのチームでは普段からよく使っていますが、そういえば開発チームでは使ったことがありませんでした。

メンバがマルチスキル化(あるいはT型スキル化)していくため、あるいは弱い領域を明確にして人材採用していくためにも、スキルマップを作って見える化するのは有効ですね。昨日からざっくりまとめてみています。

[ 10月13日全て ]

About Me

Naney Naney (なにい)です。株式会社ミクシィでマネージャー・プロダクトオーナーをしています。

nDiki1999年1月に始めたコンピュータ日誌を前身とする NaneyWeb 日記(兼パーソナルナレッジベース)です。ちょっとしたノートは nNote にあります。

follow us in feedly

※内容は個人的見解であり所属組織とは関係ありません。

月別インデックス
Process Time: 0.110728s / load averages: 0.42, 0.35, 0.39
nDiki by WATANABE Yoshimasa (Naney, Google profile)
Powered by DiKicker