西村直人のレビュー一覧
-
-
-
-
-
Posted by ブクログ
「毎週、価値ある成果を届けられているか？」何度も繰り返されているが、アジャイルかどうかはこれに尽きると思う。
インセプションデッキ、イテレーションが〜のような難しそうなワードを聞くたびにアジャイルから避けて来てたが、これらはあくまで手段。チームによって必要なものを取り入れていけばいい。
開発者であれば12章〜の内容は基本スキル。
以下は引用
P22 これから2週間で課題を解決すると宣言。
P25 お客さんを目の前にしてデモをする。
P64 今回は気にしない。→今回がプロジェクトを指してるのか、スプリントなのか不明。
P68 助けを求めたくなる前から知り合いになっておくんだ。
P106 しかる時が来たら詳細を検討するが、それは本当に必要だと確信をもてるようになってからの話だ。
P191 ペルソナがいるとシステムに人間味を持たせることができる。
P214 デイリースタンドアップでの報告の仕方をこんなふうにしてみたら〜。
P216 ストーリは完了したか、してないか。そのどちらかだ。
P226 チームの意思を明確にする -
Posted by ブクログ
ネタバレ仕事での実践にそのまま活用できる。
業務自身が難しく、また一人、一企業などだけでは解決できないような業際的な課題も多く出てくる中、仕事をしていくための良いフレームワーク。
こういったやり方をすれば、リスクを少しでも減らし、前向きに取り組むことができるようになるはず。わからないことにコミットさせられて進めることほど、ストレスフルな環境はない。
こういったチームを複数抱えている企業、そうでない企業は、たとえ一人のカリスマで引っ張られていても、そうでなくなった際にも非常に強い組織であることが容易に想定できる。
うまく業務に活用していきたい -
Posted by ブクログ
陽気な達人プログラマーに教えてもらった気分だった。
めっちゃいいです！
いきなりページを開くと(厳密には数ページだけど)
1. 君は学ぶことが心から好きだ。
2. 君はソフトウェアのことを大切に思っている
めちゃくちゃ歓迎ムードである笑
いろいろ面白い内容が盛り沢山だったけど印象的なところだけ上げておく(なるべくソフトウェア開発以外にも通ずるような部分を、、、)
1. チームメンバーを探すコツ
・ゼネラリスト
→なんでもそつなくこなせる人。器用貧乏⁈)
・曖昧な状況に抵抗がない人
→どっしりと構えてくれる、臨機応変
・我をはらないチームプレイヤー
→ありのままの姿で、調和できるように
2. エレベーターピッチ
エレベーターで一緒に乗った友達に自分の仕事を30秒で説明してみよう
3. どのリスクには取り組む価値があって、そうじゃないのらどれなのかを決める
→願わくばわたしに、変えることのできない物事を受け入れる落ち着きと、変えることのできる物事を変える勇気と、その違いを常に見分ける知恵とをさずけたまえ -ニーバーの祈り-
4. 計画の立て方
・顧客にとって価値ある成果を届けられる計画
・わかりやすく、ありのままを伝える、誠実な計画
・約束したことを守り続けられる計画
・必要に応じて変更できる計画
5. 本当に重要なものだけをまずは実装
ここまで読んでいただきありがとうございます。
でもアジャイルって一体なんやねん！と思った方は是非読んでみてください。
読んだその日からあなたも私もアジャイルです。 -
-
-
-
Posted by ブクログ
【一口感想】
「Scrum導入本の決定版！これ一冊でスクラムのエッセンスの全てがわかる」
【３行要約】
・あるプロジェクトにScrumを導入してみるという実験をストーリー仕立てで解説
・スクラムマスターに抜擢された主人公もPOもチームもスクラム初体験のなか徐々に成長していく姿がまぶしい
・重要な用語やマインドセットなどももちろん網羅
【所感】
打ち合わせでスクラムの話をしたばっかりに、新しいプロジェクトにスクラムの導入を命ぜられ、
そして自身もスクラムマスターとして任命されてしまった主人公「ボク」。
「スクラムとは何か？」
を常に自問自答しながら、迫り来る数々の問題をクリアしていき、最後にプロジェクトはいろんな
意味での「成功」に導かれていく。
ストーリーの展開はマンガ＋文章という２段構成で進められ、リズムも良いのですぐに読み切れてしまう。
遅読の私でも２時間もかからなかった。個人的には面白くて２度通し読みしてしまった。
この本のすごいところは、最初に全てをまとめて説明するのではなく、ストーリーが進んで行く
なかで必要な事実としてスクラムを解説しているところだ。ストーリーをマンガに乗せて展開
していくというスタイルは最近のハウツー本では流行りなのかもしれないが、私が読んだことのある
いくつかの本の中でもリズム感というか、マンガと文章の組み合わせの長さなどがちょうどよく、
それこそ「今必要な最低限のものを短いタームで作ってイテレーティブにリリースする」という、
スクラムのスタイルそのものに近いリズムで展開されていくところがとても読みやすかった。
また、個人的にものすごく心に響いた点は２つ。
ひとつは、このストーリーはスクラムマスターであるボクくんの成長ストーリーと捉われがちだが、
実は彼だけでなくPOのキミちゃんも、ボクくんの上司であるブチョーさんも、そしてチームの
メンバーそのものも、スクラムというプロセスの導入をきっかけにみんなが成長していくストーリーだ
という点だ。
チームは自分たちの活動内容がつまびらかになっていくことで不安もあったろうが、最後の方では
どうやればものごとを正しく、そして最短距離で解決に向かわせることができるのかわかるようになり、
そしてそれを自律的に行えるようになっていく。
スクラムは個人の能力もそうだがチームとして人が強くなり、リーダーを持たなくても自発的・自律的
に行動がとれるようになるというのは、まさにこういうことなんじゃないかと感じた。
もう１点は、プロジェクトの途中で起きるシステム的ではなく人為的な「障害」が、あまりにも自分の
過去に経験してきたことと重複してした点だ。
「人を投入すればベロシティ（開発速度）上げられるだろ。だから期間短くしろ」と上司が言ってくるとか
プロジェクトのステークホルダではない部署の人間がプロジェクトルームに来て、無意味な正義感を振り
かざして、仕様書を見せろ！こんな仕様は間違っている！と「口」も「手」も出してくる、とかいったやつだ。
スクラムにおいては、ステークホルダとチームメンバー以外の人間の意見はただの参考であり、基本的に
意思決定を左右するものにならない。彼らは自分たちのやり方が絶対で、それが正しいと信じ込んでいる
ので、そうでないやりかたをしているのが気に入らないのだろうが、そもそもプロセスも価値観もゴールも
まったく違う世界で、ひとつのやり方が絶対正しいなどという保証はない。
というかほぼ100％、間違っている。
私は、過去経験してきた数多くの開発の現場で何度もこの場面に遭遇してきた。
立場がメンバーだったこともあるしリーダーだったこともあるが、そのいずれの場合も、
チームは最終的にこの「部外者」からの意見に屈服してしまった。
しかし、それではダメだったのだ。
私はこの本を読んで確信した。
「プロジェクトのステークホルダでないやつの発言は、聞くだけ聞いて無視しろ」
この一言につきる。もしそれがステークホルダではない上司だったら、POやSMは意地でも説得する
必要があるだろうし、そうでなければチームメンバーのみんなに迷惑がかかるし、そもそもチームの
存在意義である「ユーザーに価値のある動くサービスを提供する」という目的を達成できなくなって
しまう。発言してくる人には悪意はないと思うし、上司だと言いにくい局面もあるかもしれないが、
ここは絶対に折れてはダメだ。粘り強く交渉・説得する必要がある。
スクラムとは、チームを強くするということと同時に、リーダーとなる人間がどうやって
チームを支えていくのか？ということの１つの答えであるような気がしてならない。
どうやったら部下が自律的に行動してくれる人間になるのか？
スクラムを導入することでおそらくリーダーの負荷は一時的には高くなるだろうし、これまでの
進め方では必要なかったタスクも多くなるだろう。
でもチーム全体としての生産性はきっと、それまでの何倍も高くなるはずだ。
本書では、そのきっかけとなる何かに気づかせてくれる気がする。
スクラムに限らず、リーダーとしてどう振舞うべきか？と悩んでいる人に向けても、とても良い
参考資料になるのではないかと思う。
チームのメンバーに限らず、この業種に関わる全ての人に読んでもらいたい「逸冊」だ。 -
-
-
-
-
-
-
-
-