Funny Walking

他人の人生を掘り下げる

【スプリントプランニングのインプットには、最新のプロダクトインクリメントが含まれるんだと分かって嬉しい】「スクラムガイドを読み解いてみよう」第7回 に参加してきました #ふりかえり実践会

今回は、スクラムイベントのスプリントプランニングに関しての話です。

retrospective.connpass.com

スクラムガイドのp.9 ですね。

プランニングの材料について

スプリントプランニングのインプットは、プロダクトバックログ、最新のプロダクトインクリメント、開発チ ームが予想するキャパシティと過去の実績である。プロダクトバックログから選択するアイテム数に ついては、開発チームが責任を持つ。スプリントで何を達成するかを評価できるのは、開発チーム だけである。



インプットとして最新のプロダクトインクリメントとあります。どういう意味でしょうか?

これは、たとえば、スプリントレビューで発見した新しい業務パターンへの対応をストーリーに含めるとか、要件定義中の新機能に追加要望を入れることなどが該当するようです。

スプリントゴールへの言及

スプリントゴールはスプリントの目的の集合であり、プロダクトバックログの実装によって実現するも のである。これは開発チームがインクリメントを構築する理由を知る指針となる。スプリントゴールは スプリントプランニングで作成する。スプリントゴールを設定することで、開発チームがスプリント終 了までに実装する機能を柔軟にできる。選択したプロダクトバックログアイテムは、一貫性のある機 能として届けられる。それがスプリントゴールになることもある。スプリントゴールがあれば、開発チ ームは一致団結して作業ができる。



スプリントゴールって解釈が広い概念だと思います。インクリメントとして届けられる時もあると思いますし、「新機能の実装にどれくらい現状のコードを改修しなければならないか」といったボリューム調査になる時もあるでしょう。

スプリントゴールを設定することで、ストーリーのフィーチャが現状の実装と合ってなかったら調整することも出来るのかなと思いました。

たとえば、業務フローを3パターン新しく追加したい場合、うまくいかない可能性を考慮して、最小限の実装でスプリントレビューできる業務フローを作成するとしても良いですね。最低1パターンできればOKですね。実装がめちゃくちゃ大変そうだと分かったときは、TDD前のスパイクへ方針転換することもできますね。

スプリントゴールは、抽象的な表現になってもいいと思います。柔軟にするということは、解釈の幅を広げるということですし。1%でも改善が出来ればそれで良いと思います。

スクラムに馴れてないチームがプランニングをするときの注意点

できるだけ小さいゴールを設定して、達成感を得られるようにすることが大切だという話が出てました。ただ、最小限のゴールさえ達成できなかったら無力感がすごいらしいです。。自分も経験ありますが、初めてスクラム開発を行う場合、ベロシティの計測も出来ていない状態なので、ストレッチゴールを設定しがちです。ベロシティが安定するまでは、自分たちができると思っていることよりも、1つ少ないことをやるようにすると良いと思いました。

セルフコンパッションと、千日回峰行を見ての感想

千日回峰行の動画をYouTubeで観て、感動した。


千日回峰行

一日に山道を30km歩き、寺の務めも果たす。だから睡眠は一日3時間。

1年に100日修行して、それを10年だったかな?それくらいやる。

マジか、すげぇな。信じられない。

自分は、セルフコンパッションで、自分がつらい気持ちになったときに優しい気持ちを自分に掛けることで、人生の辛さを解消しようと思っているけれど。

生活を修行の一つと捉えて、徹底して自分に厳しくする。ルールを課して、身体と心を整える。そんな状況に感動した。

最近、つらい事が続いて鬱々とした気持ちになっている。そんな中、勇気を頂いた。他人と自分を比べる必要はないが、心から湧き上がる感動の心を確かに感じることができた。

これが人生に必要なものだ。本当に人生に必要な感情だ。自分の常識の範疇を超えたものに出逢って、畏敬の念を抱かずにいられない。これが人間だ。ほんの少しだけでも、あやかりたい。自分も、ひたむきにひたすらに、目の前の事に没頭することで救いを得られるかもしれない。

ぼんやりと、しかし確実に、心の底に炎が湧き起こるのを感じ取ることができた。

吉祥寺.pm24【オンライン】参加ふりかえり #kichijojipm

いつもの通り、ふりかえりと感想を書いていこうと思います。

公式リンク

イベント全体

kichijojipm.connpass.com

発表内容のスライド

kichijojipm.connpass.com

発表内容ふりかえり

さて、みなさんの発表を振り返ります。

エンタープライズなうちでも簡単に触れるコンテナ環境をクラウド上にサクッと作るための技術

speakerdeck.com

自社内の、アーキテクトやエンジニア、セールスの方向けに、k8sの基礎、内部実装をトレーニングしたお話です。

用語が沢山出てきて勉強になったのは勿論ですが、トレーニングする人のコンテキストに合わせてトレーニングすることを意識されているのが印象的でした。説明って大事だなぁ、と思いました。

ハードウェアエンジニアにk8sを理解してもらうのって、なんとなくハードル高そうだなと思いました(自分もよく分かってないですけど。。)

ドメインモデラーにとって受託開発であることは制約なのか?

自社の開発リソースが足りなくて、受諾会社さんにお願いするケースは結構あります。自分の携わってる社内の新プロジェクトが正にそれで、会社の選定に結構苦労してるところです。

受諾開発だから、顧客のいったことだけを守るというマインドでは、確かに詰まらないですよね。発注する側としても、「こんな事言ったら面倒くさがられるのかな。。。」と、遠慮しがちになって、お互いにプラスにならない気がします。

であれば、受諾会社さんが持つ特定のビジネス領域の知見をモデリングいただいて、こちらの言ってる事とすり合わせしたほうが、より価値の高いソフトウェアが出来そうですよね。

受諾開発というドメインを突き詰めると、SaaS/パッケージ製品に似た性質を持つようになるという表現が印象に残りました。

本番障害に至る病

とても勉強になりました。特に、効率化のプレッシャーと最小限の効率で仕事を済ませたい欲求が、安全性の境界を押し下げてシステムが許容できない臨界点まで到達することを表現したラスムッセンモデルという言葉を初めて知れてよかった。

取返しのつかない失敗をする前に、故意に事故を起こす。カオスアーキテクチャという考え方も知れてよかった。

『More Effective Agile』 でも言及されていたような気がするが、アジャイル開発という文脈だと、「早い段階で検査と適応を実施せよ」という考え方に分類されるのかも知れない。

www.infoq.com

小さな家族を見守る

突然入院されることになり、家族である爬虫類の温度管理をやったお話です。Bot開発にSlack公式のフレームワークであるBoltを使われていました。

github.com

Botを作ると、色々なことがシンプルに出来るようになるのが嬉しいですよね。

Perlの依存ライブラリアップデートの話

依存ライブラリの更新ツールがPerlに非対応だったので、実装を調査してPerlで更新ツールを作成し、GitHub Actionsと組み合わせて自動でPRを出すところまで作ったお話。

Perl愛に溢れているなぁ。さすがはてなさんだなぁ。と、関心しました!

開発者が楽をするためのツールを、中身を調査して自分で作ってしまうという考え方が、好きです。

良かったこと

登壇できたことです。はじめてきちぴーで登壇できたのが嬉しい(オンラインだから皆の反応が見えないので、すこし寂しかったですが。。)

なので、下記のようなリアクションやフィードバックがとても嬉しいです。

自分を客観視できますし、今後の仕事に活かせる発見を頂けて、ありがとうございました!

課題に感じたこと

登壇で課題に感じたのは、参加者の顔も見えないし声も聞こえないしで、反応が無いのが辛かったことです。喋る内容についても、ごちゃごちゃと脱線せずに、一番言いたいことを熱量を持って伝えられればと思いました。

次こうしたい

5分のLTとはいえ、もっと具体的な事例を盛り込むべきだったなと。レトロスペクティブはチーム全体でやってましたが、内容を吟味するというよりも、周りの雰囲気を伺いながらやってた所があって、もっと濃密な時間を過ごしたいなぁ、と思いました。

ただ、人間同士の付き合いが仕事のすべてである以上、距離感を測りながら会話するのも仕事の一環なのでしょう。弊社でもリモートが増えて、週一でしかメンバーと合えないです。その範囲内で、効果的にコミュニケーション出来たなと思います。

おわりに

次は何を喋ろうかな。。と思いますが、認定スクラムマスターの取得を目標にしているので、やっぱりスクラム開発やアジャイルの文脈で話そうかと思います。Web APIについて勉強を始めたので、そのことも話したいのですが。

とりあえず、終わっておめでとうございます。参加できて嬉しかったです。ありがとうございました!

【スプリントゴールって、定義が難しいよねという話】「スクラムガイドを読み解いてみよう」第6回 に参加してきました #ふりかえり実践会

今回は、スクラムイベントに関しての話です。

retrospective.connpass.com

スクラムガイドのp.8 ですね。

スプリントの期間が1か月に制限されるのは、それ以上長すぎると予測可能性が低くなるからなんだそうです。

参加者にアンケートを取ったら、1週間が一番多かったです。自分も1週間でした。

アジャイルな見積もりと計画づくり』では、ストーリーポイントによる見積もりは規模の見積もりだと書かれています。なので、「一週間で終わらせるぞ!」と思って頑張って見積もるというより、「チームのベロシティ(生産性)がこれくらいだから、一週間ではこれくらい終わるよね」みたいな、「ベロシティを測ること」が目的なのかなーと、今のところ思ってます。

そもそも、最初はベロシティがない状態でスタートするわけだから、当然なのかもしれません。

スプリントゴールって、具体的に何ですか?

ガイドには、「スプリントプランニングで作成する。プロダクトバックログの実装によって実現する」と書いてあります。

定義が曖昧だなーという印象を受けました。不親切というか。

スクラムは、「検査と適応」を実現するためのフレームワークだと理解してます。そうすると、ベロシティを測ることは「検査」に当たりますよね。

では、「適応」はどのタイミングでするのか?デイリースクラムですかね?

スプリントゴールに、「ベロシティを測ること」を含めるのは、アリかナシか、気になりました。

スプリントプランニングは、メンバー全員の暗黙の了解を、明示的なものにしてあげること(言語化?)が目的のように思いました。これが、適応ということでしょうか?

まとまりの無い文章になりましたが、一番気になったことは、スプリントゴールにベロシティを測ること、つまり、チーム全体のメタ認知を獲得することを設定して良いか?ということです。

レビューできるインクリメントを作成することだけが、スプリントゴールではないと思いました。スプリントゴールは、曖昧というより、柔軟な解釈を許しているという表現が適切ですね。

【スクラムマスターはサーバントリーダーである】「スクラムガイドを読み解いてみよう」第5回 に参加してきました #ふりかえり実践会

8/29(土)に開催された下記イベントに参加してきました。感想をまとめてみます。

retrospective.connpass.com

スクラムガイド(2017年10月 Japanese版をダウンロードして確認してみました) www.scrumguides.org

スクラムガイドを読んだことがなかったので、いいキッカケになったというか、ちょうど自分に合っていた勉強会だったなという印象です。ありがとうございます。

会社でスクラムを取り入れて1か月くらいなので、他の人の知見が聴けるのは嬉しいですね。

スクラムマスターについて、スクラムガイドに「サーバントリーダーである」という項目があり、これは以前のスクラムガイドが更新されたときに追加された項目だそうです。

サーバントリーダーというのは、メンバーを引っ張る存在というよりも、メンバーがリーダーの役割を担えるようにコーチする役割がメインなのだと解釈しました。



チームジャーニーには、「リーダーではなく、リード」という一節がありました。何となくですが、「リード」という言葉からは、人に役割を強く結びつけないという印象を受けます。



サーバントリーダーが、リーダーではなくコーチなのだとしたら、スクラムマスターは、伝道師、または、スクラムコーチと呼べるのかもしれません。


良い学びでした。ありがとうございました。


スクラムマスターチェックリストというのもあるそうです。こちらも、面白い資料ですね。

https://scrummasterchecklist.org/pdf/Scrum-Master-Checklist-jp.pdf

経験から学ぶための、ウイークリーレトロスペクティブ 2020-08-w3

一週間のふりかえり

集中度グラフ(集中度:1-10)

スプリントの進捗が良くない。テンションが上がらない。

土日の値が高いのは、登壇用のスライドを作ってリハーサルしてたからか。

f:id:omokawa765:20200824222207p:plain
20-08-03w performance

満足度グラフ(満足度:1-10)

MBOの進行のため、調整中

1週間の主要なトピック

  • 非エンジニアの方にエンジニアリング研修を実施
  • スクラム開発5週目
  • 会社の新規プロジェクトに大きな動きがあった。新しいツールを調査

得た学び

  • 仕事が進捗しないと、精神的につらい。
  • 結果とカイゼンを混同しない

得た学び(スクラム編)

  • ふりかえりは、ガッツリやったほうがいい。たとえ8hだろうと、やったほうが学びは多い
  • 失敗しても、登壇のネタになるのでどんどん挑戦して失敗しよう

外部の勉強会で登壇

下記の勉強会でスクラム開発について、失敗とカイゼンについてお話した。

gaiax.connpass.com

Youtube Liveも実施された。

https://www.youtube.com/watch?v=PlFqb3z3MG8

いくつかフィードバック頂いたので、カイゼンの参考にする。ありがとうございました!!

以上

経験から学ぶための、ウイークリーレトロスペクティブ

経験学習を促進するため、個人的に一週間のふりかえりを行う。

集中度グラフ(集中度:1-10)

平均が5で、6を超えられた日が水曜以外にない。水曜は新しい運動習慣(マイクロバースト)を試したり、読書や勉強がうまくいったからだと思っている。OURA RingのREADINESS とSleepのスコアがそれぞれ50と63で、週としては高いスコア。

なので、睡眠の質の良さと集中度は、そこそこ一致したと思う。

f:id:omokawa765:20200808192446p:plain
20-08-w1 performance

満足度グラフ(満足度:1-10)

レーンを右に移動できた日は、やっぱり満足感が高い

f:id:omokawa765:20200809100146p:plain
20-08-w1 satisfaction

1週間の主要なトピック

  • 非エンジニアの方にエンジニアリング研修を実施
  • 新入社員の方の全社歓迎ランチ会
  • 新規プロジェクトのための調査と打ち合わせ
  • スクラム開発3週目

得た学び

  • 仲間を褒めまくると自分自身が嬉しい
    • 一日最低8個は仲間の良いところを見つける
  • やることが切り替わると、スイッチングコストが高くて消耗する。切り替えの前後に瞑想か運動を行う
  • 商談に臨む前には、相手のことを1hは調べたほうが楽しい。SNSやWebの公開情報などを調査する。もしくは、社内に知ってる人がいるか聞く
  • たとえ品質の悪いプログラムであっても、学びにすることでメンタルを安定させることができる。
    • 「こんな品質の悪いプログラムを知れたから、逆に自社サービスのプログラムの品質の高さがわかったし、コミュニケーションロスが発生してしまうと、簡単にプログラムの品質は落ちると学んだ」という具合
  • 雑談のときは、雑談をひたすら楽しむ。
    • 仲間の知らない一面が分かる。楽しい。円周率50桁暗唱できるとか、手がとても柔軟だとか、すごい長い名前を覚えるとか

得た学び(スクラム編)

不確実性の高い案件に臨むときは、メンバーに短い時間で相談する。

15分きっかりで終わらせる。これを、インスタント・モブ・相談。略して「インスタ」と呼んで重宝して使っている。15分にしたのは、デイリースクラムが15分なので、最もタイムボックスを意識しやすい時間だから。

15分で終わらなかったら、1分ふりかえりしてまた15分やる。15分を1サイクルとして、何サイクル掛かったかを計測してチームのパフォーマンスの参考にする。

プランニングポーカーの見積もり基準が定まってきた

これまでの実績から、どれくらいの修正ならこのポイント、というのが分かってきた。たとえば、下記の感じである

  • 1 .. 文言修正や、ランディングページの修正
  • 2 .. ホームページに動画やタグを埋め込む修正
  • 3 .. コントローラやモデルのロジックを修正
  • 5 .. それ以上の修正
  • 8 .. 原因がわからないバグの修正

とにかく、少しでも楽しくする

自社サービスのWikiに、スクラムチームのことを書いているのだが、構成メンバーにキャッチフレーズとイメージとなる絵文字を付けた。

お遊び的な要素が強いが、新しいことを楽しむことで積極的になれる。良いじゃないかと思う。

たとえば、自分はバナナが好きなので「バナナ面川🍌」といった感じにした。

そのほか、ラバーダッキング用のぬいぐるみをゲーセンで獲ったり、デイリースクラムを大きな声で元気よくやってみたり、意識的に雑談を多くしてみたりと、やれることは沢山やった。

普段は在宅で、zoomに常時接続して開発メンバーとやりとりするので、スクラム開発がきっかけで、コミュニケーションを活性化したいという想いが強くなってきた

開発チームの結束が高まった

スプリントレビューでメンバーの一人が欠席したのだが、1人欠けただけでも、とても心細くなったことに気が付いた。

つまり、それだけスクラムが機能しているということだ。

「達成しきる」という強い気持ちを持つことの大事さを学んだ

実は予定したベロシティの60%程度しか達成できなかったため、「やりきる」という意識が欠けていたことを学ぶことができた。

欠けていたのは何故か。いくつか理由を考えた。

進捗を測るという意識がなかった

マイルストーンを使い、全体の進捗状況を測ることはできているのだが、日々の進捗を測ることができなかった。

だから、マイルストーンが完全達成されないことに危機感を持てなかった。その証拠として、スプリントの中盤に、マイルストーンが終わっていないにも関わらず、プランニングポーカーを行った。

まずは、プランニングしたチケットをすべてやりきるという強い目的意識をもつことから始めよう。

全員で達成するのだという意識がなかった

個々人のタスクをやりきることに注力していたため、マイルストーン全体の進捗をデイリースクラムで意識することができなかった。

自身のタスクが終わっても、全員のタスクが終わらなければ完了ではない。

日々、進捗を確認し、ヤバそうなら一気呵成にインスタして、その日のうちに解決してしまうくらいの強い気持ちを持つ。

なので、あえて「進捗どうですか?」という言い方をするようにしてみよう。自分にもプレッシャーを与えるためだ。

以上