はてなブックマーク

This is a translated article. You can access the original here: Mob Programming – A Whole Team Approach by Woody Zuill モブプログラミング-チーム全体のアプローチ by Woody Zuill Translated by Yasunobu Kawaguchi, Ikuo Suyama and Ken Matsumoto 1. はじめに モブプログラミングとは、チーム全体が同じものを、同じ時間に、同じ空間で、同じコンピュータで作業するソフトウェア開発のアプローチです。これはペアプログラミング[PAIR]に似ています。ペアプログラミングは、2人の人が同じコンピュータの前に座り、同時に同じコードを共同作業するというものです。モブプログラミングでは、1台のコンピュータを使ってコード

コロナ前からですが、リモートでモブ作業をすることがすっかり当たり前になりました。会議を含むリモート作業がうまくいくための条件はいくつか思い当たるのですが、こちらのサイトでシンプルにまとまっていたので、紹介したいと思います。 Remote Mob Programming | How we do Remote Mob Programming. 紹介されている原則は以下の15個です。 Remote Everybody (全員リモート) Camera Always On (カメラは常時オン) Regular On-Site Meetings (定期的に対面で会う) Small Team (小さなチーム) Same Time (同じ時間) Typist and the Rest of the Mob (一人は入力者、残りはモブ) Screen Sharing (画面共有) 10 Minute Int

リサとジャネットの Agile Testing Condensed という短い書籍があるんですけど、これの翻訳をお手伝いしました。権利周りの調整のお手伝いと、翻訳レビューです。 leanpub.com アジャイルテスティングという、日本ではそんなに盛り上がっていない分野がありまして。アジャイル時代にどのように品質を担保するのか、QAやテスターはどのように関わっていくのか、非常に大事なんですけど、なぜか日本ではTDD(テスト駆動開発)やテスト自動化についての注目に比べても、今ひとつ盛り上がっていない感じがします。惜しいことです。 Agile testing is a software testing practice that follows the principles of agile software development. Agile testing involves all me

先週末はオープンセミナー広島さんにお邪魔してお話させていただきました。資料は下のものです。資料冒頭で「西島カーブ」の話をしました。 osh-web.github.io speakerdeck.com 前日に観光に行った呉市の大和ミュージアムで、呉の海軍工廠の成り立ちから戦闘艦を国内生産する話を勉強しまして。そこで科学的管理法が連呼されてて、なんだろうと思って調べたわけです。 yamato-museum.com そうしたら、西島技術大佐の「西島カーブ」というのにたどり着きまして。 http://hesaka.sakura.ne.jp/nishizima.html もう10数年前に前間孝則の「戦艦大和誕生」を読んでいた時、主人公であるところの西島亮二が呉工廠で工程管理を行うために生み出された「西島カーブ」なるものが出てきた。しかしこの工程管理手法についての説明は概略のみであり、また造船所勤めと

RSGT2020今年もつつがなく開催できました。お陰さまですごく楽しかったという声を多くお聞きしてほっとしてます。スタッフのみなさんおつかれさまでした。スピーカーの皆さんも高いプレッシャーの中、出来る限りのものをぶつけていただいて、本当に感謝していますし、すごいなーと思います。尊敬します。 すごく雰囲気が良かったというご評価をいただくことが多くて、大変ありがたく感じております。雰囲気作りについて、ちょっと思ったことをFacebookに書いたら長くなったのでブログに転記しました。 カンファレンス会場の雰囲気なんて参加者の人たちが作ってるものなので実行委員はなにもしてません。なるべく会話を邪魔しないで済むように空間を考えたり、大きく声を出して指示しなくても自然と必要な場所に流れるのがベスト。そのために例えば受付では変な人が入ってこないようにリスクを摘み取ってたり、場を壊してしまいそうなリスクを

プロダクトオーナーが忙しい、プロダクトバックログ書いてくれないって話をよく聞くんですけど、そのあと話を聞いていくと実はプロダクトオーナーは同じ会社じゃないんです、お客さんなんですっていうパターンがちょくちょくあります。 プロダクトオーナーがやる仕事は結構あります。 ビジョンを持ち、いつ誰に何を届けるかを考え、プロダクトバックログに落とし込む なるべくROIを高められるようにプロダクトバックログを優先順位付けする。 直近の数スプリント分は準備完了(チームが着手可能)にする チームと定期的に話し合ってバックログを見直す(リファインメント) すべてのステークホルダーと話す 予算を取る バックログの内容についてチームからの質問を受けつけ、明確化する チームが完成としたバックログ項目の成果物(出荷判断可能なプロダクトインクリメント)の受け入れ判断をする 受け入れた成果物をリリースすべきときにリリース

RSGT2020の基調講演をやっていただく Jim Coplien さんによる、大規模組織のお話がありました。 この話を聞くのは実は三回目(飲み屋、ウィーンでのScrum Gathering、今回)ですし、ありがたいことに、色んな人に日本語で説明することもあるので、周りの人とも話しながら自分なりの認識がまとまってきました。 いや、お前のまとめなんていらないんだよ、とは思いますが、全体をちゃんと書くのは難しいので(ビデオとっとくべきでした)、ざざっと書いておきます。 人々は組織をツリー構造*1で考えがちで、実際に公式な組織アサインはそのように運営されがちだが、末端のノード間やたすき掛けのようなつながりは自然に起きていて、それによって情報流通の効率性が維持されている。これは、兼務をつけて複数部署にマネージャーを頭出しさせるのとも違うし、マトリックス型組織でプロジェクト運営するのともちょっと違う

実践アジャイルテストの続編である、More Agile Testing の第一章が、アジャイルテストの歴史を端的に書いてていいな、と思ったのでその部分だけ訳してみました。 More Agile Testing: Learning Journeys for the Whole Team (Addison-Wesley Signature Series (Cohn)) (English Edition) 作者: Janet Gregory,Lisa Crispin 出版社/メーカー: Addison-Wesley Professional 発売日: 2014/09/30 メディア: Kindle版 この商品を含むブログを見る 第一章 アジャイルテスティングはどのように進化してきたのか 私たちは、それぞれ、エクストリームプログラミング（XP）チームの中のソロのテスターとして「アジャイル」なキャリ

大きめの企業でスクラムで回し始めて、ビジネスもうまくいくようになってきたところで、急に訪れがちなのが「体制変更」です。これまで陰に日向に支援してくれた上司や役員の方がいなくなって、新しい方がいらっしゃるという。ここで苦労したり、諦めてしまう例が多いと感じます。 答えはないのですが、雑多な考えをここに記録しておこうと思います。まとまってもいないので、無駄に長くてごめんなさい。 うまくいく確率は論理的に50%を下回る 「新しい人とうまくいく可能性もあるので、50:50じゃないの」という意見もあるかもしれません。しかし、なにかを始めるときはだいたいうまくいきそうな上司や役員を選んで相談するわけです。しかし、人事異動で次に来る人は選べません。ですから、うまくいっていたことがうまく行かなくなったり、説明を求められたり、基本、いままでよりは手間が増えることは確実ですし、その結果、フラストレーションが溜

スクラムギャザリングというカンファレンスの実行委員会がありました。実行委員会といっても、会議をやってるというより、淡々と決めて作業を進める会です。このカンファレンスは2011年からやっていて、来年でちょうど10年になります。紆余曲折ありながらも、ここ数年は実行委員業も枯れてきて、ああうまくいくアジャイルチームってこういう特性あるのかもな、と気づくところもありまして。今日はそのあたりを記してみます。 今日は趣意書の公開まで 今日は 4-5時間ほどで、趣意書(スポンサー向け資料含む)と、スポンサー受付のサイト作成までが終わりました。ちなみにWebサイトまでは終わらなかったので基盤まで整えたところで、次回の作業になりました。 趣意書はこちらです。 日本語: Dropbox - prospectus-ja.pdf - Simplify your life 英語: Dropbox - prospec

日本は長かったゴールデンウィークが開けるということで、戻って働けるのかしらという話が飛び交ってますが、いかがお過ごしでしょうか。引き続き Hunter Industriees にいまして、学んだことをメモしておこう、というエントリです。前回のエントリは単体のモブプロについて気がついたことが中心でしたが、今日は複数モブについてです。 Hunterで学んだことその8: 仕事領域 = モブ != 人 3つのモブを持つプロダクトに参加していているのですが、それぞれのモブは同じコードベースで、別の仕事をしています。モブごとに紙ベースのタスクボードをホワイトボードに作っていて、WIPは1に制限されてます。 これは私がソフトウェアを作る人生の中でも初めて体験したのですが、モブは作業場所なだけでなく、どの部分をいじっているか、も示します。フィーチャーブランチを切らず、トランクベースで開発しているので、同じ

日本方面は、平成最後とか、令和こんにちわ、連休ながーい、という噂を聞いておりますが、私はなぜか米国に来ていて、フィーバーに参加できておりません。アベンジャーズは一応、公開日に観に行きました。字幕ないし、アメリカンジョーク(推測)とかは聞き取れなかったんだけど、そんなのどうでもいい感じの映像美でしたね。 Hunter Industries にお邪魔してます モブプログラミング・ムーブメントを生み出した、Hunter Industries に来てます。２年前に半日だけお邪魔したんですけど、モブ自体には参加してなくて、もうちょっといろいろわかりたいな、と思いまして。1月にRegional Scrum Gathering で来日してくれた、Director のクリスさんにお願いしてみたら、いいよーってことだったので、お邪魔しに来ました。 ビザの関係で生産活動には従事できないのだけど、横で立ってるの

沖縄でみんなでつくった Fun! Done! Learn! が広がりをみせていて、作った人の一人としてとても嬉しいです。ちなみに私の貢献は寝坊して起きてきた朝に「いいねそれ！」って言ったことと、「Deliverは長いし、汎用性考えるとDoneのほうが使いやすそうだし、なにより英語でも日本語でも語呂がいい」って主張したくらいです。つまりだいたい私のおかげだと思っております(壮大な勘違い)。 yattom.hatenablog.com 大事なポイントは、私たち、全然教えてないのに、これだけ広まって、成果の声が届いていることです。これは、なんかすごいものを、見つけてしまったのではないかと感じています。みなさんの共通の、心のなかにあったものを、見える化できたんじゃないかと。 このエントリは、私の心の中にあったものを、書き出してみたものです。Fun! Done! Learn! とは一体なんなのだろう

アジャイルコーチとして社内でスクラムを始める人のサポートをちょくちょくやってきたのですが、一番多い質問の一つが「緊急の割り込み仕事が多くて予定が立たない」です。作業をどうやって安定させるかはスクラムの本線なのでチームで考えるとして、結構ストレスなのが、割り込みたい人への対処だったりします。 むしろ緊急にして持ってくる人がいる 割り込みを持ってくる人は断られないようにむしろ緊急にしてから持ってくる傾向があります。列に割り込んで一歩でも前に出られたなら承認欲求が満たされるケースとか。私が責任者だから私の意見が通らないといけないと思っているとか。 透明性を担保して相手も理解できるようにする 透明性と心理的安全性を確保して、早めに相談する方が得な環境を作れるといいんじゃないかなぁって思います。スクラムだと、プロダクトバックログを透明に保って、誰でも見られるようにして、その上で何番目にその案件を位置

こんなご相談をいただきまして。 スクラムマスターは支援者だとは思っているんですが言葉が難しく…提案や促し？ではなく「指示」なってしまう場面があり上手く出来なくて うーん、まあそんなに焦らず、刺激を与えたらその反応を、じっくり観察していきましょう。ってなアドバイスをしまして。 スクラムマスターっていうのは、人を変えるというか、理解を促したり、姿勢を矯正していくような仕事なので、「30m走りなさい」って言えるPOとはちょっと違ってですね。人間という複雑なものを複数束ねたチームというのを扱うので、とにかく刺激->反応を見るを繰り返すしかなかったりすると思います。 なので、「こうしてほしい」に「はいやります！」っていう変化は単純、もしくはうわべだけなので、もうちょっと本質的な深い変化を観察する必要があるかなと思います。 問題 (ミーティングが長い) -> 対処 (短くしたほうがいい) ... では

こんなご相談をいただきまして。 スクラムマスターは支援者だとは思っているんですが言葉が難しく…提案や促し？ではなく「指示」なってしまう場面があり上手く出来なくて うーん、まあそんなに焦らず、刺激を与えたらその反応を、じっくり観察していきましょう。ってなアドバイスをしまして。 スクラムマスターっていうのは、人を変えるというか、理解を促したり、姿勢を矯正していくような仕事なので、「30m走りなさい」って言えるPOとはちょっと違ってですね。人間という複雑なものを複数束ねたチームというのを扱うので、とにかく刺激->反応を見るを繰り返すしかなかったりすると思います。 なので、「こうしてほしい」に「はいやります！」っていう変化は単純、もしくはうわべだけなので、もうちょっと本質的な深い変化を観察する必要があるかなと思います。 問題 (ミーティングが長い) -> 対処 (短くしたほうがいい) ... では

前回のエントリもずいぶん多くの方に読んでいただいたようで、大変驚いております。 kawaguti.hateblo.jp さらに、いただいたフィードバックから、もう一点補足した方がよいかなと思いまして、このエントリを書き始めました。補足の補足ですみません。 リーダーがITを学ぶのが早いか、IT技術者が経営を学ぶのが早いか 前回、IT技術者ではないキャリアを歩んでいる方々がプログラミングを学んだ事例としてジャパンタクシーの川鍋社長のエピソードと、若手向けプログラミング研修の例を出しました。 ビジネスマンがプログラミングを学ぶ価値 アジャイルジャパン2018で、ジャパンタクシーの川鍋社長が話していたことが印象に残っています。川鍋さんは正月休みを利用して、１週間詰め込み型のプログラミングスクールに行き、Railsを使ったプログラミングを学んだそうです。そこで発見したのは、「一文字間違えただけでも動

昨日のエントリは思いがけずアクセスをいただきまして、はてブのホッテントリにものったようで、驚いております。ありがとうございます。ここのところお腹の中にぐるぐるしている思いを新年にかこつけて吐き出した記事で、切れない「なまくら刀」のような後味で申し訳なく思っております。 kawaguti.hateblo.jp この記事の中で、業務知識という言葉の定義を曖昧なままに使ってしまって、ブクマコメントで「業務知識とはだな...」というご教示をいくつかいただきました。ご指摘ありがとうございます。 SIerで業務知識といえばお客さんの業務に関する知識 システムインテグレーター(SIer)方面の方は「(自分たちはIT知識を持っている前提で)、ユーザー企業の人が持っているべき知識のことを業務知識と呼ぶ」という認識なのだろうと認識します。そういえば、10年以上前になってしまいますが、業務知識はSIerに必要か

ykmc09.hateblo.jp 横道さんにやたら褒めていただいたRSGT実行委員会の作業ですが、一つ大事な文化があるとおもってます。「集まった時に、議論や検討より、できる限り作業を進める」という文化です。 どうしてもみんな集まった時に議論とか意思決定をやりたくなっちゃうんですよね。いろいろ決めるんだけど、そのあと別れてからの実行ができなくて、次に集まった時にまた同じ議論しちゃったり....。前に来てなかった人が蒸し返して、進めてる人との間で雰囲気悪くなったり。 これ原因は、作業が前に進んでないところだと思うんです。特にコミュニティは主業務じゃないでしょうから時間取るのも大変。そりゃうまくいかないです。 作業を終わらせるために意思決定するわけですから、時間内に作業まで進めれば、結果見てOK/NGのフィードバックも得られます。セッション募集などすぐに結果がわからないものも、作業結果(募集サ