#DevKan「SCRUM BOOT CAMP THE BOOK」片手にアジャイル開発を考えてみよう！に参加しました。
DevKan 1分遅刻してしまった。。
http://devlove-kansai.doorkeeper.jp/events/7585 ジュンク堂でさっそく購入
- 作者: 西村直人,永瀬美穂,吉羽龍太郎
- 出版社/メーカー: 翔泳社
- 発売日: 2013/02/13
- メディア: 単行本（ソフトカバー）
- 購入: 5人 クリック: 13回
- この商品を含むブログ (28件) を見る
ハッシュタグまとめ。
※注意：散らかすだけ散らかしてます。
はてなブログに投稿しました
#DevKan「SCRUM BOOT CAMP THE BOOK」片手にアジャイル開発を考えてみよう！に参加開始 - developer's diary
http://t.co/L0t5trCWMk
— 堤 庸(mitsugi) (@mitsugeek) 2014, 2月 1#DevKan アジャイルな開発やってる人？ ５人くらい手を挙げてる。 「その人たちに聞くと良いかもしれません」w
— 堤 庸(mitsugi) (@mitsugeek) 2014, 2月 1今回のdevlove関西勉強会はスクラム道 関西と共催でした。
#DevKan アジャイルサムライが出てから、アジャイルに関する書籍が増えている。
— 堤 庸(mitsugi) (@mitsugeek) 2014, 2月 1| タイトル | 出版年月 |
|---|---|
| アジャイルソフトウェア開発 (The Agile Software Development Series) | 2002/08 |
| アジャイルソフトウェア開発スクラム (アジャイルソフトウェア開発シリーズ) | 2003/09 |
| アジャイルレトロスペクティブズ 強いチームを育てる「ふりかえり」の手引き | 2007/09 |
| アジャイルプラクティス 達人プログラマに学ぶ現場開発者の習慣 | 2007/12/22 |
| リーン開発の本質 | 2008/2/7 |
| アジャイルな見積りと計画づくり ~価値あるソフトウェアを育てる概念と技法~ | 2009/1/29 |
| アジャイルサムライ−達人開発者への道− | 2011/7/16 |
| 実践 反復型ソフトウェア開発 | 2012/12/1 |
| SCRUM BOOT CAMP THE BOOK | 2013/2/13 |
| わかりやすいアジャイル開発の教科書 | 2013/3/28 |
| アジャイル開発とスクラム 顧客・技術・経営をつなぐ協調的ソフトウェア開発マネジメント | 2013/6/20 |
| リーン開発の現場 カンバンによる大規模プロジェクトの運営 | 2013/10/26 |
駄目だ・・いっぱいありすぎる。。
http://honto.jp/ ってところでアジャイルで検索すると、８５件見つかって、アジャイルサムライは50番目。amazonは一覧表示が酷すぎたので別のサイトで調べました。
出版年で冊数を出してみると下のグラフに。
#DevKan アジャイルサムライでのスクラムの位置づけはスクラムはアイスクリームのフレーバーのような・・・
— 堤 庸(mitsugi) (@mitsugeek) 2014, 2月 1#DevKan アジャイルサムライの副読本、もう少し実践的な書籍が、を、なら書きたいという流れで「SCRUM BOOT CAMP THE BOOK」が生まれた。絵が沢山->漫画書いたらいいんじゃないのか？
— 堤 庸(mitsugi) (@mitsugeek) 2014, 2月 1#DevKan 「量は質に」変わる。絵を描くのに１時間くらい掛かっていた->５分くらいでかけるように。最初と最後でクォリティとスピードが段違い。量が質に変わる瞬間を体験
— 堤 庸(mitsugi) (@mitsugeek) 2014, 2月 1量が質に変わる
#DevKan アジャイルサムライは出版する予定がなかった。（ジョナサンさん）企画を持っていったけど反応無し。2年間毎朝スターバックスで書かれた本。 -> 本書いた方が良いよマジデマジデ。
— 堤 庸(mitsugi) (@mitsugeek) February 1, 2014#DevKan 本を書いた方が良い理由：頭の中で分かっているつもりでも、文字に起こすと「あやふや」な所が多い事に気づく。人に伝えようとしたときに整理できていないことに気づく。本を書く事でぶれない軸ができた。
— 堤 庸(mitsugi) (@mitsugeek) February 1, 2014皆さんも本を書きましょう。
#DevKan 相対見積もりがなぜ必要なのか？ マイクオンが言ってたはず。でも書籍をみても答えがない。なんでなんだろう？ マイクオンって誰！？
— 堤 庸(mitsugi) (@mitsugeek) 2014, 2月 1@mitsugeek Mike Cohnですねー。http://t.co/mZMc1h0e0N
— ながせ☆みほ Miho Nagase (@miholovesq) 2014, 2月 1Mike Cohn -> wikipedia
#DevKan あった、相対見積もりを推奨している書籍「Agile Estimating And Planning」（Mike Cohn著、Prentice Hall発行） http://t.co/wykCYLsVaD
— 堤 庸(mitsugi) (@mitsugeek) 2014, 2月 1#DevKan 「Scrum Boot Camp The Book 」を書いたワケ(西村さん) が終わりました。
— 堤 庸(mitsugi) (@mitsugeek) 2014, 2月 1#DevKan テーマトーク始まります！ガヤガヤガヤ。
アジャイル開発やったことある人？？
— 堤 庸(mitsugi) (@mitsugeek) 2014, 2月 1#DevKan テーマを募集。参加者が付箋１枚に１テーマを記述して前に集める ＞ かんばんっぽいものがホワイトボードに出来上がった。
— 堤 庸(mitsugi) (@mitsugeek) 2014, 2月 1#DevKan アジャイル開発やった事あるひとが前に立っております。結構無茶ぶり。でも少しホットになってきてる感じが。
— 堤 庸(mitsugi) (@mitsugeek) 2014, 2月 1#DevKan http://t.co/8jGwXCo4J8 スクラム道関西の方立ちとのテーマトーク
— 堤 庸(mitsugi) (@mitsugeek) 2014, 2月 1#DevKan スクラムマスターはスクラム開発のロールの一つで、スクラムが上手く回るように立ち回る人の事。
— 堤 庸(mitsugi) (@mitsugeek) 2014, 2月 1#DevKan マインドシフトの方法・手段。周りの人を「かんか」する方法
— 堤 庸(mitsugi) (@mitsugeek) 2014, 2月 1#DevKan 社会人のチームが３チームと大学院生のチームが１チーム。一番良いプロダクトを作ったチームは大学院生のチーム。大学院生のチームが適用能力が高くどんどん進んでいった。社会人経験がある人は普段の開発手法なんかが邪魔してしまっていたのではないか。
— 堤 庸(mitsugi) (@mitsugeek) February 1, 2014#DevKan マインドシフトなんて無理なんじゃないのか？ マインドシフトがそもそも必要ない状態だから大学院生のチームが優秀だったのではないか？
— 堤 庸(mitsugi) (@mitsugeek) 2014, 2月 1#DevKan 組織の評価基準が変わらないとマインドシフトしないのではないか？
給与体系が業績であれば、マインドシフトしないのではないか？
— 堤 庸(mitsugi) (@mitsugeek) 2014, 2月 1#DevKan やらされてる感を無くす環境を構築する事がマインドシフトに繋がるのではないか？
— 堤 庸(mitsugi) (@mitsugeek) 2014, 2月 1#DevKan 人のマインドを替えるのは難しい。環境を替える事が大事なのか。プロジェクトチームが立ち上がったら自らタスクボート書き出して働きかける。アジャイル導入しましょうではなく、自らアジャイルな動きをしていく。草の根レベルでアジャイルを導入していく。
— 堤 庸(mitsugi) (@mitsugeek) February 1, 2014#DevKan いままでやってきたことを替えるのはとてつもないエネルギーが必要。成功の方程式が身に付いている状態に別の成功方程式を当てはめるのは大変。根性論で成功してきた人に分析が大事っていっても肌感覚で伝わらない。
— 堤 庸(mitsugi) (@mitsugeek) February 1, 2014#DevKan マインド・シフトは、振り返ってみたらシフトしてたってこと。ある意味結果論。でも草の根レベルで変えていってる人たちが居たからこそ変わる事なんだと思う。
— 堤 庸(mitsugi) (@mitsugeek) 2014, 2月 1#DevKan お客さんの若い人がチームに入って１年くらい開発していたら、いつの間にか自分の会社に入社した。あの感覚が忘れられなくて。凄く楽しい開発なのかなぁ。
— 堤 庸(mitsugi) (@mitsugeek) 2014, 2月 1#DevKan スクラムで開発効率があがるってことはない。 開発効率を上げるプラクティスは席替え。生産性が上がったのはどうやって測るのか。
— 堤 庸(mitsugi) (@mitsugeek) 2014, 2月 1#DevKan 席替えは洲じゃなくて谷が良い。背を向ける状態。何かあれば振り向いて確認。
— 堤 庸(mitsugi) (@mitsugeek) 2014, 2月 1#DevKan ふりかえりのベストプラクティス 「アジャイルレトロスペクティブズ」 http://t.co/tNo7SYVeXM
— 堤 庸(mitsugi) (@mitsugeek) 2014, 2月 1#DevKan スクラムは体育会系？
— 堤 庸(mitsugi) (@mitsugeek) 2014, 2月 1#DevKan 自分が環境を理解できる事。自分が関わる事で環境が変わる事を知る事。
この二つがそろうと幸せに感じやすい？
— 堤 庸(mitsugi) (@mitsugeek) 2014, 2月 1#DevKan 自然なやり方だからスクラムに価値がある。でも価値なんてない。
変化が見えてくるからスクラムに価値がある。
— 堤 庸(mitsugi) (@mitsugeek) 2014, 2月 1#DevKan 変化に対応する可視化ツール。プロダクトバックログ。いわゆるゆるくする？
— 堤 庸(mitsugi) (@mitsugeek) 2014, 2月 1#DevKan WBSはスケジュール方法ではない。パートがスケジュールの方法？
— 堤 庸(mitsugi) (@mitsugeek) February 1, 2014２．プロジェクトスケジューリング（PERT/CPM） (静岡理工科大学)
#DevKan 定期的な振り返りに価値がなければやめればいい。問題が発生したときにどう対応するか。
— 堤 庸(mitsugi) (@mitsugeek) 2014, 2月 1どう対応するか。自分で考える事。
#DevKan スクラムが合わなければやめればいいし、考えれば良い。
— 堤 庸(mitsugi) (@mitsugeek) 2014, 2月 1#DevKan デイリースクラム。 タイムボックス。改善を重ねる、自己組織的に振る舞う。定期的に小さく作る事に慣れてからチームワークのあり方に触れていく。スクラムマスター（ロール）。会議体、タイムボックス、スクラムマスター（ロール）
— 堤 庸(mitsugi) (@mitsugeek) 2014, 2月 1
Scrum概論 from Ryuzee YOSHIBA
Scrum"再"入門 from Ｙｏｕ＆Ｉ
#DevKan Quality, Cost, Delivery（品質、価格、納期）スコープ。どれがこのプロジェクトで大事かをインセプションデッキで決める。そもそもそれって必要なの？
— 堤 庸(mitsugi) (@mitsugeek) 2014, 2月 1
インセプションデッキ紹介 from Ｙｏｕ＆Ｉ
#DevKan お客さんを巻き込まない方がいい。巻き込む方が良い。お客さんを甘やかさない。プロジェクト管理出来ない人が発注したらだめ。うーん。って考えるとプロなんだから巻き込まないってのも正論かもしれない。
— 堤 庸(mitsugi) (@mitsugeek) 2014, 2月 1なるべく人がやらなくて良いようにする->やることを減らす事によって質があがる。過度な期待を背負い込んでよけいな物を作らない。
— 堤 庸(mitsugi) (@mitsugeek) 2014, 2月 1#DevKan 燃えてるプロジェクトのたたみ方->徹夜。燃えてるプロジェクトに対するテンションは凄い。でもそのあと振り返りがないことが問題。
— 堤 庸(mitsugi) (@mitsugeek) 2014, 2月 1#DevKan 質を上げる事で検査をさぼる。これが質と量を上げること。日本の製造業がアメリカの製造業を追い越した理由。
— 堤 庸(mitsugi) (@mitsugeek) 2014, 2月 1