はてなブックマーク

「偉大な書籍は偉大な出だしで始まる。ケント・ベック著『テスト駆動開発』(2003, 2017)はこう始まります。 「動作するきれいなコード」。Ron Jeffriesのこの簡潔な言葉が、テスト駆動開発(TDD)のゴールだ。 」 テスト駆動開発エバンジェリストとして活躍している、和田卓人さん(t_wada)の講演より引用 セミナー講師やアジャイルコーチの立場で、私もTDDを教えることがよくあります。そんなときはこの言葉を意識しつつ、TDDはあくまでスキル、手法のひとつに過ぎず、本当に求めるべきは動作するきれいなコードなのだと、伝えるようにしています。そのことを説明する補助として、こんな図を作りました。 絵を描いてみて気づいたのですが、「動作する(Works)」には2つの側面があります。書いたコードが、書いたつもりの通りに動くこと(Verification)と、期待に応えて働き実際に役立つこと

この文章は、Yves Hanoulle編纂 "Tips from the agile trenches" に寄稿したエッセイ(tips!)を元に、概要を日本語にしたものです。書籍はLeanPubで購入できます。 私がスクラムマスターとして一緒に働いたチームの話です。そこのプロダクトオーナーは、ユーザーの獲得と知名度向上に注力していました。その点では非常に上手くいったのですが、1年も経たないうちに企業合併の影響で製品は破棄され、ブランド名だけ残してビジネスが継続されることになりました。私個人の感想としてですが、目の前に注力しすぎて、将来を形作れなかった事例として印象に残っています。 また別の機会に、半分アジャイルコーチ半分開発者というかたちでスクラムチームに参加しました。開発者はみんな経験豊富なエキスパートで、自動テストはキッチリ、アーキテクチャも十分、コードはソリッドでした。メンテナンス性

2021年7月1日に「モダンアジャイル 再考 2021」というイベントが分散アジャイルチームについて考える会の主催でありました。 distributed-agile-team.connpass.com このイベントのきっかけは、私のFacebookでのつぶやき？でした。 これへのコメントできょんさん、鬼木さん、川口さんらに反応していただけ、さっそくオンラインイベントとして開催されたのでした。 以下では、イベントでいろいろな方から出た話、意見、考え方を踏まえながら、私自身の解釈や思っていることを書いてみます。最初に議論したいと思っていた内容もあれば、イベントでのやりとりから感じたこともあるし、後から思い出しつつ考えが変わってきた部分もあります。内容や文章について責任は私にあります。 モダンアジャイルとは モダンアジャイル(Modern Agile)はJoshua Kerievskyが2016

スクラムマスターに資格(職務に就くための必須の条件)はありませんが、認定(スクラムマスターとして有能である、十分である)はいくつかあります。 ですので、タイトルに直接答えれば「資格は必要ありません(そんなものはありません)」となります。 いっぽうで、スクラムマスターの認定はいくつかの組織から提供されています。こちらは勉強する目標としても、就任する上での判断材料のひとつとしても、有用ではないかと思います。 Certified Scrum Master® / CSM® / 認定スクラムマスター 非営利組織Scrum Allianceが提供しています。認定トレーナーの研修を受けた上で受験します。日本ではOdd-e Japan、アギレルゴコンサルティング、アトラクタなどが提供しています。 Licensed Scrum Master / LSM Scrum, Inc.が提供、日本ではScrum, I

インセプションデッキ Advent Calendar 2019 - Adventarの参加エントリです。 アジャイルコーチとして活動する中で、インセプションデッキ作りを手伝うことがよくあります。私がファシリテートする場で、どんなことを考え、どんなことをしているのか、思いついたところを書き出してみました。一例として参考になる部分があればいいなと思っています。書き出してみると、我ながらちゃんと考えられていないところがあるなあと気づいたりしますね。 目次 インセプションデッキ作りが重要だ、作ったインセプションデッキはどうでもいい (いくないけどそれほどでもない) タフクエスチョンカードを手作りする 全体の進め方も合意で決める オーナーは目的意識を持って事前準備する タイムボックスはあんまり使わない 休憩は戦略的に それぞれのスライドについて個人的なメモ インセプションデッキ作りが重要だ、作ったイ

asobannは現在herokuにデプロイしてMongoDBを使っているが、「herokuのMongoDBが11月で使えなくなるよー」という通知が来た。なるほど。また、サーバーをスケールするためにはFlask-SocketIOを複数プロセス起動してロードバランサを置かないといけないのだけど、herokuでそれを実現できない。あるいはすごいお金がかかる(herokuのガイド通りに1プロセス1Dynoにすると、ロードバランサ1つ＋メッセージキュー1つ＋アプリn個ぶんのDynoが必要になる。処理負荷はぜんぜん小さいのにもったいない)。 もともとパフォーマンス改善を考えていて、複数プロセス構成に載せ替えたかったので、これを機会に取り組んでみることにした。いちおう開発環境レベルでは動くようになったので、そこでやったことを主に自分のメモとして、もしかしたら誰かの参考になる情報として、書いておく。どれも

先日、現場の人から質問を受けました。 「スクラムで進めているプロダクトに、大きめの問題(バグっぽい挙動)が見つかった。POは最優先で対応したいと思っているが、まず状況把握や原因調査だけでも時間がかかりそうで、ましてや対応までどのくらいかかるかわからず、1スプリントに収まる気がしない。どう対応していくのがいいか」 バグ対応とスプリントについては、いろいろな人が言っています。自分の中ではそういう話と自分の経験がまぜこぜになってしまっていますが、それを思いつくままに書き出して回答を送りました。なんとなく、自分にとっても整理された感があったので、こちらにも置いておきます。 問題を特別扱いしない。問題も、機能追加も、どちらも「理想と現実のギャップ」であり別々に扱う必要はない。どちらも同じように、調査や準備をし、見積もり、プロダクトバックログに入れ、優先順位を検討し、スプリントで開発する。 POが優先

心理的安全性ゲーム、おかげさまで体験ワークショップを大小合わせて6回くらいやらせてもらっています。毎回その場でカードを販売していて(1セット2500円)、少なからぬ参加者の方がその場で購入してくれています。とてもありがたいのと同時に、この売り方って最強だな……とも考えていたりします。 どう最強なのか 心理的安全という概念を知ってほしい、参加者それぞれの仕事などの場で実践するきっかけになってほしいというのが、ゲームを作り体験ワークショップをやっている理由です ゲームを実際にやった人が「これ面白い！」と感じてくれるのは嬉しいですし、その人がカードを購入して自分のところでやってもらえば、広めるパワーとしては一番強力になります(知人から「これ面白いよ！」と紹介される以上の手はそうそうない) その場で販売できるということは、私がそこまで出向く時間やコストを捻出しやすくなるということでもあります。無料

RSGTアドベントカレンダー2018のエントリです。昨日はJean-Baptiste Vasseurさんの「RSGT2019 スポンサーブースでスカベンジャーゲームをやる！」でした。明日はTakao Oyobeさんの「私がアウトプットする理由」 です。 RSGT2019のセッションで、心理的安全性ゲームをやる予定です(一日目1/9(火)15:15〜)。このゲームは、チームにおける心理的安全性を考えるきっかけづくりを狙いにしています。 さて、心理的安全性という言葉は最近あちこちで使われるようになり、優れたチームや組織にとって重要という考え方が広まっています。ここであらためて関連する研究を見直し、心理的安全性について理解を深めたいと思います。 エイミー・Ｃ・エドモンドソンは90年代から心理的安全性についての研究をしています。書籍『チームが機能するとはどういうことか』(2014年)では、心理的安

ふりかえりで使える手法としてKPTやYWTなどがありますが、新しくファン・ダン・ラーン(Fun/Done/Learn)というアプローチを作ったので紹介します。チームがやったことを、Fun、Done(またはDeliver)、Learnという3つの軸とその重複で見直します。上の図のように、Fun、Done(Deliver)、Learnのを重ね合わせた図をボード上に書いて、そこに分類していきます。 この図を見れば、経験のあるファシリテーターやスクラムマスターなら自分なりのやり方が思いつくのではないでしょうか。ぜひ自由に使ってみてください。以下では、私たちが実際に試してみた方法を紹介します。 まずホワイトボードや模造紙に、上のFun/Done/Learnの図を描く。重なり合う領域が狭くなりすぎないよう気をつけること メンバー1人ひとりで、やったことを付箋に書き出す 付箋の内容を共有して会話しながら

「新米スクラムマスターが読むべき、読んでおくべき書籍や資料を教えてください」とFacebookで書いたところ、何人かのアジャイルコーチやスクラムマスターといった皆さんからお勧めをもらいました。 https://www.facebook.com/yattom/posts/1771377669542867 (ログインしなくても読めます。「コメント26件」みたいのを開いてください) せっかくなので、ここにも転記しておきます。私の独断で分類しつつ、一部紹介コメントも追加しました。 超基本、必読 「スクラムガイド」 Jeff Sutherland, Ken Schwaber バイブル。ときどき読み返すといい 「アジャイルマニフェスト」 基礎知識。12の原則がだいじ 『エッセンシャル・スクラム』 Kenneth S. Rubin ガイドがバイブルならこちらは事典 『アジャイルサムライ』Jonathan

DHHの"TDD is dead. Long live testing."を、訳してみました。 翻訳 やっとむ By David Heinemeier Hansson on April 23, 2014 著 David Heinemeier Hansson 2014年4月23日 Test-first fundamentalism is like abstinence-only sex ed: An unrealistic, ineffective morality campaign for self-loathing and shaming. テストファースト原理主義は禁欲のみを唱えた性教育のようなものだ。つまり、自己嫌悪に陥っている人に向けた、非現実的で効果のない、道徳教育のようなものだ。 It didn't start out like that. When I first disco

TDDに関連する論文をいろいろ探し回っていたのですが、今年(2013年)に書かれた、既存のTDD研究をまとめて全体像を描こうとしている研究を見つけ、しかも無料で公開されているので、紹介したいと思います。 以下のように書いてあるので、学会(?)発表用のものであって、雑誌に載ったわけではないのかな(アカデミックな話はよくわからない。査読があるかどうかが重要なんだっけ)。 This is the author's version of the work. The definite version was published in Proceedings of the 6th International Conference Software Quality Days (SWQD 2014), Vienna, Austria, January 14-16, 2014 "Effects of Tes

来日中の James O. Coplien と話をする機会があり、いまTDDをクライアントに推薦していると話したら目を剥いて "Are you still doing TDD!?" と詰め寄られ、TDDの問題について大変熱烈に語ってくれました(ディスカッションをした体ではあるんだけど、だいたい10対0くらいで押されてました)。 Cope はその後、丁寧にfacebook上にもTDDの話を書いてくれました。ここで読めます。 さらにメールで、TDDの問題を指摘した論文などをいくつか教えてくれたのでした。そこで紹介してもらった論文を、自分の理解の整理も兼ねて、サマリをしてみようと思います。とりあえず1つだけですけど。 "A Comparative Case Study on the Impact of Test-Driven Development on Program Design and T

バグを見つけたとき、どうするか。プログラマなら3つの選択肢がある。 直す 原因を調べる 再現テストをする プログラマなら、直感的に脊髄反射的に1番を選ばないだろうか。 バグを見つけた！ このへんが怪しい！ よし直そう！ やった直った！ というのが典型的なプログラマの動物的本能である。いや、そうであるかどうかは知らないけど、わたしはそうでした。 わたしがどういうデバッグをしていたかというと、当たりをつけて直してみて、直らなくて、アテが外れたなあホントはこっちがおかしいのかなーと、別のところも直してみて、ついでにあっちも直してみて、いろいろ直してるうちになにがどう正しいのかわからなくなって、いや待て落ち着け原因をちゃんと把握するんだっと思ってソースを改めて見直したり、print文を埋め込んで流れを追ってみたり、予想と違う動きをするんだけどそれはそれで正しかったり、考えたり唸ったりまたソースを見

https://sites.google.com/a/scrumplop.org/published-patterns/product-organization-pattern-language/scrummaster を訳してみた。精読するために訳したので、どっかに正式の日本語版があったらごめんなさい。 ScrumMaster スクラムマスター スクラムチームは自己組織化する。重要な役割や責任をチーム内に落とし込むのも自己組織化のプロセスの一部だ。 自己組織化したチームが自分自身を客観的に観察するのは難しい。そのために、改善や、問題発見、ときによってはベロシティと品質を維持するのにも苦労することがある。 プロジェクトはトップダウンで遂行するのが伝統的だが、うまくいっているとは言えない。知性的で想像力ある個人でチームを構成するなら、自分たち自身のやりかたで組織化する必要がある。自己組織化し

スクラムのエッセンスを手軽に体験できる、トランプゲームを使ったワークショップを紹介します。短時間(20〜30分程度)でスクラムの役割の意味を把握し、スクラムにどんな効果があるのか理解できます。チームで理解のベースラインを合わせて、チームビルディングにもなります。事前準備はほとんどいりません。 以前に id:nawoto = 西村直人さん(スクラムブートキャンプ本の執筆や、アジャイルサムライの翻訳)と一緒にすくすくスクラムに登壇したとき、新しいゲームとして作って実施したものです。最近では西村さんが「アジャイル開発基本のキ」セミナーの中で採用しているので、やったことがある人も多いと思います。 学び: コマンド＆コントロールと自己組織化チームの差 自己組織化チームは自ら変化するという気づき 全員がゴールを共有することの大切さ POと開発チームの役割 必要な事前準備: トランプ (参加者5〜7名ご

TDDのサイクルはRed-Green-Refactoringです。このリファクタリングは、プロダクトコードはもちろんですが、テストにも適用されます。しかしテストのリファクタリングには、プロダクトコードのリファクタリングと違うところもあります。 プロダクトコードのリファクタリングは、一言で言えば後で変更するときのためにやるものです。プロダクトコードを変更するのは、機能追加や変更、問題の修正のためです。つまり、将来プロダクトコードの価値を高めるためにリファクタリングをします。 テストのリファクタリングも、もちろん変更のためですが、テストコードの変更はプロダクトコードの変更に追随して発生します。テスト内容を変更するためにテストコードを直すことは稀です。したがって、プロダクトコードを変更しやすくするために、テストをリファクタリングする。 通常の(つまりプロダクトコードの)リファクタリングは、まさに

実はモデリングが大好きです。元々はオブジェクト指向プログラミングを勉強しているところからUMLに(自然に)興味が向き、そこからオブジェクト指向設計とかオブジェクト指向分析とかそういう脇道にそれ(脇道とか言ったら怒られる!)、仕様も設計もこれからはオブジェクト指向だ!というありがちな若気の至りもありました。デザインパターンにも転んだし、責務!ロール!コラボレーション!ってのもやったし、重厚長大なフレームワークとかもなかなか楽しいですよねえ。ねえ? 今でも概念モデルとか大好物で、上の話を聞きながらうっかりとこんなオブジェクトモデリングをしてしまったりします。 そんなわけで、プログラミングする対象の仕様を理解しながら頭の中でモデリングして設計を進めてしまうのはやむを得ません。多かれ少なかれ、なにかしらの設計が浮かんできてしまいます。 でもTDDはテストを書きながら設計をします。先行して設計してし

アジャイルなソフトウェア開発を導入する手伝いという仕事の中で、ペアプロでTDDをやってみせるという機会がよくあります。ここ最近のバディであるid:haru01と組んで、ライフゲームをやってみせるのが定番化しています。 ライフゲームをテーマにしてどんなふうにTDDを進めるのか、これから簡単に紹介していきたいと思います。ベーシックな手法のみで進めるので、モック(テストダブル)とか、データドリブンテストとかそういうことはしません。言語はPythonですが、誰にでも読みやすいのがPythonのいいところなので、Pythonを知らなくても理解できるんじゃないかと思います。 ライフゲームにはWikipediaにもあるように、誕生・生存・過疎・過密の4つのルールがあります。TDDでライフゲームを書くには、この4つをもとにTODOリストを作ります。 死んでいるセルに隣接する生きたセルがちょうど3つあれば、

10月22日におこなわれた、Regional Scrum Gathering® Tokyo 20192日目のワークショップとして、「スクラムプロジェクト逆計画ゲーム」をやってきました。 ゲームは「プロジェクトが成功して終わった」ところから、どうやって成功までたどりついたのかを、時間を逆回しにして終わりのスプリントから始めのスプリントに向かって、計画と実績を組み立てていくというものです。 スクラムに限らずアジャイルなプロジェクトにおいて、プロジェクトの最初に計画を立てて後はそれに従うというのでは不十分です。プロジェクトの途中でも計画を変更する覚悟で、むしろ計画を変更しつつ進めることを前提として、「計画づくり」という活動を積み重ねなていきます。そうした考え方を直感的に理解し、そうした認識をチームで共有するためのゲームを、今回のために作りました。 今回はイベントのワークショップとしてやりましたが

昨日、4/15はアジャイルジャパン2011でした。私は岡山サテライトに参加して、午後後半のワークショップをやらせていただきました。 内容は、Linda Risingの基調講演を受けて、アジャイルジャパンで得たものを実際に自分の現場に持ち帰るのに、パターンをどう使えるだろうかと、具体的に議論して案を作ってみるというワークショップです。参加者のみなさんには、登場人物の「帽子」を作ってかぶってもらいました。 スライドはこちらです。 Fearless ChangeパターンView more presentations from yattom. また、48のパターンを一覧にした資料を配付しましたが、そちらはFearless Change読書会Googleグループに参加していただくと、その中で公開しています。お気軽にどうぞ。 岡山を仕切っていただいた、すくすく瀬戸内の阿部さん、「笑顔コーチ」岸本さん、

システム開発ジャーナルVol.10の 「【特集1】困ったら読む! 困る前に読む! 今すぐ使える エンジニアのためのソフトウェアテスト術」に、TDDのコラムを書きました。 システム開発ジャーナルVol.10 TDDの歴史や位置づけから、BDDや自動受け入れテストにも触れながら、全体を概観しつつ現状を整理したつもりです。要件ホルダーを巻き込んでのTDDの部分は、じゃっかん勇み足というか、期待感の溢れを書いてしまったような気もしてますけど。 TDDをやったことがない、知らないという人は幸いです。これから生産性を飛躍的に上げることができるから。でも知っててできるんだけど、今の現場ではできない・あんまりちゃんとやってないというのが、わりと現状であったりもすると思います(自分もそう)。でもそこを頑張るというのが必要なことであり、頑張るためのテクニック、ノウハウというのが、いま必要なTDDのはなしなのか