書籍「コーチングアジャイルチームス」を買って読んでいます、いろいろとためになることばっかりだ
1章に出てくる「ネイティブワイヤリング」という言葉は初耳だった
8章の「BART分析」も同じく
↓続きはこっちのブログに書く
スクラム関連のチェックリスト
アジャイルやスクラム関連のチェックリストを調べていたので、いくつか並べます
Scrum Checklist by Henrik Kniberg
Henrik Kniberg氏 (書籍「リーン開発の現場」などの著者) によるチェックリスト。色んな国の言葉に翻訳されており、日本語版は川口恭伸さんが公開されています
- https://www.crisp.se/gratis-material-och-guider/scrum-checklist
- https://kawaguti.hateblo.jp/entry/20090819/1250632392
最低限のチェック、として挙げられているのは以下の3つ
- 定期的(4週間以内)に動作する、テスト済みのソフトウェアを提供している
- ビジネスニーズに基づいたものを最優先して提供している
- プロセスは継続的に改善している
スクラムチーム用セルフチェックリスト by ryuzeeさん
ごぞんじ ryuzee さんによるチェックリスト。
10カテゴリ x 10項目 = 全100項目ありますが、こちらのツイートによると
一方で全部が同じ配点なの良くないな。
— Ryutaro YOSHIBA (@ryuzee) 2023年12月5日
「毎スプリントレビューで完成の定義を満たすインクリメントを見せてフィードバックを貰っている」が50点くらいで、残りは全部0.5点でいいくらい。 https://t.co/NHDhLzpq5m
「毎スプリントレビューで完成の定義を満たすインクリメントを見せてフィードバックを貰っている」が50点くらいで、残りは全部0.5点でいいくらい。
とのことです。
Scrum Master Checklist by MJ
MJ こと Michael James氏によるチェックリスト。こちらも各国翻訳多数。
- https://scrummasterchecklist.org/
- https://scrummasterchecklist.org/pdf/Scrum-Master-Checklist-jp.pdf
スクラムチーム向けではなく、スクラムマスターへの問いかけになっているのが特徴。
あなたのスクラムチームの成熟度は？
Ron Eringa さんによる、各ロールごとの成熟度の表、ryuzee さん翻訳。
SCRUM MASTER THE BOOK 自己組織化したチーム
書籍 SCRUM MASTER THE BOOK に出てくる、自己組織化したチームのチェックリスト。
ここでは引用しませんが、P8 のエクササイズ参照。
所感
個人的には Henrik Knibergさんの最低限のチェックと、ryuzeeさんの配点50点な1項目は似たことを言っているなあと。そしてそれと一緒に思い出したのが書籍「ゾンビスクラム サバイバルガイド」に出てきた 4つの症状。
ゾンビスクラム サバイバルガイドの目次より引用
- 症状1：ゾンビスクラムチームはステークホルダーのニーズを知らない
- 症状2：ゾンビスクラムチームは速く出荷しない
- 症状3：ゾンビスクラムチームは（継続的に）改善しない
- 症状4：ゾンビスクラムチームは障害を克服するための自己組織化をしない
- すべては繋がっている
……やはりそこからだなあ、と
2023年 いいねした曲プレイリスト
2023年 Spotify でいいねした曲を雑にプレイリストにしました
曲単位でいくと大賞は beabadoobee の "the way things go" です
git の初期ブランチ名を main に変更する
GitHub デフォルトのブランチ名が main なので、それにあわせる
git config --global init.defaultBranch main
これで、ローカルで git init したときもデフォルトのブランチ名が master ではなく main になる
読んだ「成功する要求仕様 失敗する要求仕様」
「成功する要求仕様 失敗する要求仕様」アラン・M・デービス
読んだ。いわゆる要件定義・要求定義に関する本。帯に「デマルコ絶賛！」とあり、表紙の感じからも「ピープルウェア」など一連のシリーズものの扱いなのかも。2006年初版ということでけっこう古いんだけれども、自分は最近知った。
原題は “Just Enough Requirements Management” ー ちょうど十分な、要求マネジメント。「ちょうど、十分な」というところがミソっぽい。
雑感 (雑な感想)
いや、良くまとまってるなーと思った。この本では、要求を「導き出し」、「トリアージし」、「仕様化」、という流れからの「変更を管理せよ」となっている。
問題解決やビジネス成功のために大事なことは、
- ユーザー視点を理解する
- 時間やリソースに都合のつく問題にのみ、対処する
- 齟齬の無いよう、自分たちが理解した内容を記録する
- ニーズの変化に対応する、柔軟であり続ける
これらがそれぞれ、「要求の導き出し」「トリアージ」「仕様化」「変更管理」にあたるという形。
構成もわかりやすい。第1章が「はじめに」、2〜5章が前述の「導き出し」〜「変更管理」、6章が「まとめ」なんだけど、わずか7ページの「まとめ」が特に簡潔にまとまってる。一部抜粋。
「もし、自分のほうが顧客よりも要求をよく知っていると思い込んでいるのなら、あなたは解決者ではなく、問題の一部なのである。」
「もっと機能を追加しよう！という意見が通った場合、提供は遅れるものである。そんなに多くの機能は実装できない！という意見が通った場合、製品の競争力は低くなるものである。」 「顧客は、自分が抱える問題を解決したがっている。コンピュータの記法を学びたがっているわけではない。」
細かいテクニックよりも、考え方の面について勉強になるのだけど、内容は観念的ではなくデータ・グラフをもとにした具体的な記述も多い。もう少し読み込みたい。
