はてなブックマーク

が、ブログのURLが含まれていることに気がつきまして、最新エントリがさすがに去年のままだとまずかろうと。 WEB+DB Press Vol.83は先週の金曜日発売でした。 内容についての紹介は、共著のryuzeeがもう書いてくれたので、割愛して、こちらでは、ちょっとその背景みたいなものを書いてみようと思います。 仕事がら、コンサルタント、コーチまたはトレーナーなどとして、いろいろなチームに伺うことが多いのですが、こういう立場で呼ばれるということは、いろいろと問題があることが多いのですね。 ご依頼の内容の通りの問題があるときももちろんあるのですが、よく見受けられるのは、問題そのものを議論の対象にすること自体を怖れているという状況です。問題があることはわかっているが、それに触れてしまうと、もっと大きな問題を引き起こしそうで、みんな触りたがらないという状態ですね。 そうなってしまうと、どう解きほ

寒くなってきましたね。 この前の記事が暑い話だったのは、いつの話ですかね。 で、今回は、スクラムチームの最悪の敵の話です。 まあ、プロダクト開発をぐるぐる続けられているなら、魑魅魍魎ステークホルダーともうまくつきあえるようになっているでしょう。 でも、怖い敵はいるのです。 インフルエンザ 寒くなってくると、そろそろと流行りはじめます。 チームメンバーの誰かが、敵の手に落ちます。敵もさることながら、いきなりは攻撃してきません。ちょっとだるいなとか、頭が重いなくらいの感覚です。 でもプロジェクトは進めないといけませんから、がんばって出社します。最近の風邪薬は強力ですから、多少の熱、咳くらいはコントロールできます。熱が下がったのでデイリースクラムに参加します。プランニングポーカーでエキサイトすることもあるでしょう。 はい、これでチームは敵の手に落ちてしまいました。しばらくすると、みんな感染します

あまりに暑いのでちょっと怪談を。 今のような仕事のやり方をする前、いわゆるシステムインテグレータに所属していた。まあ、呼び方はいろいろあるのだろうけれど、一番長いこと仕事にしていたのは、いわゆる「火消し」。問題プロジェクトにがあると、プロジェクトに投入されるという役どころだ。まあ投げ込まれるのは大変だけれど、いろいろなものを見ることができた。 投入されたプロジェクトは多種多様だけれど、たいていの場合、すぐに問題があるようには見えない。みんな忙しそうに働いているし、大きな開発プロセスの問題もない。粛々と作業がすすんでいるように見える。でも、クライアントと管理職は怒っている。怒っているから、いろいろな作業が追加されて、メンバーはどんどん忙しくなる。 しばらく見ていると、プロジェクトには必ずある種類の人がいることに気がつく。みんなに頼りにされていて、なにかあると彼(彼女の場合もあるよ、もちろん)

東北デベロッパーズコミュニティにお招きいただき、DDD/Scrumのワークショップをやってきました。 ワークショップは、DDD のモデリングのうずまきに、スクラムのワークショップでよく使うタイムボックス縛りを組み合わせて、Agile でいうところの Swarming という状態になれないかな、という目標で設計しました。 正直、１時間の枠組みで、シナリオ書いて、モデル描いて、コードも実装するのは、だいぶ大変だったと思います。ご参加いただき、ありがとうございました。 ただ、１時間を二回廻すだけでも、チーム内で駐車場を語る語彙、モデル、設計実装案は、だいぶ共有できたのではないでしょうか。そのまま、プロジェクトに突入できる訳ではありませんが、わからないことがわかっているというのは、プロジェクトを始めるときには非常に役に立つでしょう。 参加された方は、各チームの発表したモデルの中心(コアドメイン)が

まあ、大人げないと思いつつ。いろいろ考えるのですよ。 というわけでアジャイルに不慣れな受託のマネージャー向けに。 「プロジェクトが成功するためならなんでもする」 まあ聞いたことがあるよねこの言葉。SIer にいたころに協力会社の営業から。できれば頼みたくない会社だったりするんだが、そういうところに限って見積が安かったりするんだな。 で、トラブルになっても何もしない。唯一やってくれるのは、「人が足りないんですか？職務経歴書お送りしますよ。」だ。 あうち。 ソフトウェアにアーキテクチャがあるように、プロセスにもアーキテクチャがある。変わりにくいものと変わりやすいことを読むのが本質だ。 ソフトウェア開発において、みんなどこでも「なんでもやりますよ」をやるとどうなるかはみんな知っているだろう。大きな泥だんご(Big Ball of Mud)っていうやつだ。結局何もできなくなるまで、無駄を生み続ける

ちょっと大人数で行うプロジェクトに参加したことがある人なら、WBS (ワークブレークダウンストラクチャー) を目にしたことがあるだろう。 日本語だと作業分解構成と説明されることが多い。Work(作業) Breakdown(分解) Structure(構造) というわけだ。日本語の説明では、そういう説明が主流のようだ。 でも、WBS の Work は実は作業ではない。 WBS を定義した標準の最新版MIL-STD-881Cを見てみると、"A product-oriented family tree composed of hardware, software, services, data, and facilities." 「WBS の定義は、ハードウェア、ソフトウェア、サービス、データ、設備などからなる成果物指向の分解ツリーである。」 ここでいう Work は、成果物のことだ。Workb

というお題で、第二回大阪Jenkins勉強会でデモをしてきました。 Arduino jenkins View more presentations from Kiro Harada. Jenkins がせっせとビルドしてエラーを報告してくれるのは助かるのですけれど、やっぱり忙しくなると見に行かなくなってしまうのですよね。パトランプなどの実体のあるデバイスを置いておくのは、やっぱり有効です。 タスクボードやバーンダウンチャートは、まずは紙！という感覚とも近いのかもしれません。 ソースコードは、https://github.com/haradakiro/arduinojenkinsxfd Arduino のデジタル８番ピンを、リレーの制御に使っています。 今回利用したArudino やリレーなどは、Strawberry Linux で入手できます。 Arduino Arduino Ethern

デイリースクラムのやり方は、いろいろなところに書いてあるし、チームによっていろいろ工夫をしていると思うので、ここでは書かない。 Scrum Guide にも書いていないけれど、ScrumMaster が絶対にやるべき重要なことがある。 メンバーの顔色を確認することだ。メンバーの体調を計測することだ。それだけでも、ScrumMaster がフルタイムの役割である十分な理由がある。 メンバーの体調は、常に気を配っていないと気付くことはできない。デイリースクラムの３つの質問に気を遣うと同時に、ScrumMaster はメンバーの体調についても十分注意を払う必要がある。 どうも風邪薬や栄養剤のCMのおかげで、体調が悪くても会社にいくべき、のような風潮がある。でも、この時期、インフルエンザのメンバーを一日出社させてしまったら、そのスプリントは終わりだ。チームが全滅するだろうし、他のチームにも迷惑をか

初めてのRegional Scrum Gathering Dhakaが無事終わったところで、一年ぶりのブログを書いてます。一日目のキーノートと、二日目のOSTを担当しました。 ＃で、辛いものでお腹を壊したので、打ち上げパーティに行き損ねたホテルで書いてます。残念。 # 毎年参加してた Agile Vietnam は、日程かぶりで今年は不参加です。またね。 Dhakaに来るのは初めてだったのですが、ギャザリングだとあんまり初めてな気がしないんですよね。いろんなところからいつもの面子が集まって、情報交換が出来るので。近況を交換しているうちに、レストランの値段が違うことで場所の違いに気づきます。 ちなみにこちらの通貨1タカ=1.3円くらいなので、日本人は価格を掴みやすいです。まあ、ホテル以外は価格表などなく基本交渉なので、思った様には行きません。日本への主要な輸出品のひとつがエビで、ここのエビは

森崎先生のソフトウェアレビューの講演を聴いて、今やっているレビューの方法をまとめときたいと思ったので、まとめてみます。今回は、コードレビューの話です。Scrum ではといっていますが、レビューのやり方はチームによって違うので、あくまでも例ですよ。PBI とか、仕様、ドメインモデルのレビューの話はまたこんど。 レビューの目的は、もちろん作成するプロダクトの品質向上です。障害を検出するのも、もちろん目的ではあるのですが、それ以降のスプリントで作成されるコードで同じ障害を作り込まないのが目的としては大きいです。そのため、レビューはプロジェクトもしくはチーム立ち上げ後、数スプリントで重点的にやります。後はスプリントの振り返りでレビューをやりたいが出てきたら、チームで決めます。 レビューのやり方 基本はチーム全員で集まってやります。最大２時間。それ以上やっても集中力が続かないので。プロジェクタで対象

Coderetreat へようこそ Coderetreat は、一日中集中して練習するイベントです。ソフトウェア開発と設計の基礎に重点を置いています。開発者を仕事を片付けなければならないというプレッシャーから開放して、集中して練習する機会を提供することで、非常にスキルの向上に有効なことが示されています。モジュール設計、オブジェクト指向設計の基本原則を練習することで、将来にわたって変更コストを小さくするコードを書くスキルを改善できます。 ファシリテーション Coderetreatにはファシリテーターが必ず必要です。ファシリテーターの責務は、一日の概要を説明すること(私の解説ビデオを参考にしてください)、セッション中にペアをガイドすること、セッション間の振り返りと、終わりの会をリードすること。このページでは、一日の概要スケジュールと、効果的なファシリテーションのコツを説明します。ブログにも c