1章から8章までふりかえり
ここに感想とか引用とか書いていくぞー!
アジャイル開発の恩恵は「アジャイル」という魔法aleの呪文を唱えることでどこからともなく湧き出るものではない
何回見ても好きな一文
第3章
煩雑系よりも複雑系にアジャイルは向いているというのはわかるけど、最近だとDXの文脈だったり、アジャイル開発の部分であるデジタルや人を大切にする働き方に着目されているのもあって、そういったことは煩雑系でも必要とされているというか、どこでも必要とされている。。。これがUncle Bobがいうそれをアジャイルというのかは知らないけど、非常に役に立つようだっていうやつなんだよな。。。個人的にはアジャイルでいいじゃんって思うけど。
そこまで分断を感じていないというのが大きいんだろうけど。。。北米の惨状っていうやつかな。。。
スクラムからガントチャートみないなステークホルダーを安心させる図をつくることに四苦八苦していてカテゴリをまちがっているのかと思った。
筆者が思うに、「検査と適応」はOODAの省略表現としてうってつけである。この表現はアジャイル開発の実質的な焦点でもある。(p28下部)
「アジャイル開発とは何か」という問いに答える時のヒントになりそう。「アジャイル開発は、検査と適応に焦点を当てた開発手法です」とか。
アジャイルチームは *すべてのものを* 定期的に検査し、適応させる必要がある。(p28下部)
プロダクトだけじゃなくてチームも、みたいなところを再確認
アジャイルマニフェストに「チーム」という言葉は出てこない、スクラムならでは。
第4章
各スプリントは *スプリントプランニングミーティング* で始まる。このミーティングでは、スクラムチームがプロダクトバックログを見直し…(p35下部)
バックログリファインメントをスプリントプランニングでも行っていい、というか行うべき、という話?であれば認識違かったなあ…
バックログリファインメントはいつでもやってもいいという感じ
それをイベントと捉えるか、そうでないか
デイリースクラム(中略)。この15分間のミーティングは、スプリントゴールへの進捗の検査を目的としており、通常は次の「3つの質問」に答えるだけとなっている。(p37上部)
■昨日は何をしたか
■今日は何をするか
■進行を阻んでいるのは何か
スタンドアップミーティングのこと?質問が決まってるとはこれまたびっくり。「通常は」とあるからある程度自由ではありそう、最終的に目的である進捗の検査ができれば。
この「3つの質問」は廃止される予定(p37中部)
そういうことだったのか…というお気持ち。なんで廃止されることになったんだろう?
今では、オプショナルになっている。例として3つの質問がある
文字列は変わった
このスプリントゴールのために貢献したことは何か
このスプリントゴールのために貢献することは何か
スプリントゴールを阻むものは何か
「スクラムを検討してみたが、そのプラクティスのほとんどは私たちの組織でうまくいかないようだった。わたしたちはスクラムを実践しているが、主に導入しているのはデイリースタンドアップで、毎週金曜日におこなっている」(p41下部)
思わず笑ってしまった、バイト先がこれに近いかもしれない…。スプリントという名の定例ミーティング間の1週間や2週間しか存在しかない。
既に最小限であるため、スクラムではいかなる部分も省くことはできない。
そうだったのか…しらなかった…。
高度なスクラムの実践では(中略)スクラムの特定の部分を省くことになるかもしれない。(p42上部)
ということらしい。「未経験者が行うことではない」ともあったので慎重にならないとと思った。
学生のプロジェクト、デイリースクラムを設けるのが非常に難しくて、それぞれ作業できる時間も違う…というのがあって、どうすればいいんだろうとなった。
うちのチームはアジャイル開発を行ってはいるけど、スクラムではない。ただ、スクラムよりも効果的な活動を行えているわけではないと思うので、一度きっちりとスクラムをやってみたいと思った。
ただ、スクラムをやるにはかなりエネルギーが必要そうで、みんなを巻き込んで本気を出してもらうことができるかどうか、あまり自信がない。
スプリントプランニング 2時間(p50上部表)
そんなにかけていいの!?となった。enPiT夏合宿では20分だったので
自己管理できる機能横断的チームでは、通常は少なくとも次の専門性が求められる。
■アプリケーションのさまざまなレイヤー(フロントエンド、バックエンドなど)を経験していて、異なる専門知識(アーキテクチャ、ユーザーエクスペリエンス、セキュリティなど)を持つ開発者
■アプリケーションのさまざまなレイヤーのテスト技術者
■テクニカルライター
■実践している開発プロセスのエキスパート(スクラムマスター)
■特定分野のエキスパート
■ビジネス理解、ビジョン、ROIをチームにもたらすビジネスエキスパート(プロダクトオーナー)
今更だが、テクニカルライターとはどんな仕事をするんだろうか?
アジャイルの実践の成否は、意思決定のほとんどを自分たちだけで下すのに必要な人材をアジャイルチームに積極的に配属するかどうかにかかっている。
アジャイルかどうかは関係なく、人数規模の大きなプロジェクトだと意思決定の長さで時間が過ぎていくのがよくわかる。
5.4 プロダクションサポートの組織化
プロダクションサポートがカスタマーサポートを含むとすると、組織されたサポートチームからカスタマーサポートの生々しい情報をどう開発チームに取り組むか難しいと思った。(最近の個人的感想
カスタマーサポートからヒアリングするとき、複数ペルソナを定義すると意見の分類をするときに役に立つ
第6章
動くソフトウェアを作ることはもちろんプロジェクトの目的の1つだが、そのソフトウェアを作るチームの能力を向上させることも目的の1つである
良い言葉だな〜心に染み入る。この言葉を胸に活動していきたいと思います。
第8章
技術職が相手に合わせてコミュニケーションスタイルを調整するには、明確な指導や励ましがしばしば必要になる
ちょうどこれが自チーム内でも問題に…相手の理解度や会話する上での内容の粒度の調整をどう伝えたら苦手な人ができるようになるのか…
https://scrapbox.io/files/61ae034b116c30001fe7a759.png
ここの認識はとてもだいじだなーって最近いろんな場面でおもう。コーチ先とか、部署内とか、オンボーディングとか、チームビルディングとか。
■それは事実か
■それはみんなにとって公平か
■それは好意と友情を深めるか
■それはみんなのためになるか
4つのテストにパスする決定や対話はどれもチーム全体の強化につながる可能性がある。
これ見逃していたな。めっちゃよさそう。明日から使おうと思った。
Rotary International は国際ボランティア団体?らしい。
個人の能力を最大化するための組織のアプローチについてじっくり検討する。そのアプローチには採用後の継続的な人材育成が含まれているだろうか。
基本は仕事してスキルアップしようというスタイルで、書籍や勉強会の補助はなく、社外での勉強や副業は非推奨(ただし風向きは変わりつつある)。採用後の研修も新人(プログラミング未経験が大多数)向けのプログラミング研修しかない。ただ、個人がどういう力を伸ばしたいか?その力を伸ばすためにどのようなアサインがいいか?というのは4Qに一度位の頻度+望めば更に高頻度で考えてくれる。
風向きが変わって人材育成支援のプログラムが急に充実し出した。
おめでとう!!!!
8888888888888