はてなブックマーク

「アジャイルコーチの道具箱 – 見える化実例集」を読みました。 ギルドワークスで現場コーチとして、様々な現場がアジャイルな開発をうまくやれるような支援、現場の改善や見える化をしている自分としてはとても興味をそそられるタイトルです。 また翻訳した方々も@haradakiroや@ryuzeeなど期待せざるをえない人達ばかりで、すぐに読み始めました。 読んでいる途中「あの現場のあのチームはこれが良さそうかな」「あのチームが持っている課題はまずこれをやってみて、それからこっちをやってみてはどうだろう？」とアイデアが色々出てきてワクワクしてきました。 やるかどうかは現場のチームが決めればいいですが、「こういうアイデアがあるよ」「こういう感じで一度試してみてはどうかな？」とコーチとして色々なカードを見せたり、背中を押すことができそうです。 コーチだけでなく、チームが見える化を推進していくのも役立ちます

システム開発の要素の1：新規開発(スクラッチ)と2：保守開発(機能追加)があります。 #保守開発は派生開発とも呼んだりするようですが、ここでは保守開発とします。 新規開発はその名前の通り「一から」システムを作り上げていき、生み出されるソースコードは全て新規で、バージョンもピッカピカの1.0です。 保守開発は既に稼動しているシステムに、新しく機能を追加したり既存の機能を改善するものです。 開発者にも新規開発、保守開発に対する得手不得手(適性的なもの)があるようです。 今回はこの新規開発、保守開発という2つの要素に、それぞれ開発者に求められることは何か？を書いてみます。 新規開発に求められる開発者の能力は何か？ 1つは、要件仕様、外部設計に基づいてソースコード、機能を「生み出す」能力です。それは0から1にする感じで、その後の保守開発での1から5にするよりも色々なパワーが必要になります。 もう1

このエントリは？ このエントリは達人出版会から出版された電子書籍【開発現場に伝えたい10のこと】で私が書いた内容を許可を得て転記したものです。 2014/01/14(火)にはDevLOVE関西で書き手が集まる【「開発現場に伝えたい10のこと」それぞれの後日談】を行います。 よろしければご参加ください。 では少し長いですが、お付き合いください。 最初に行う3つのプラクティスと継続していくコツの目次 前半はチームビルディングにフォーカスを当てて、私がチームに参加した際にまず最初に行うことが多い3つのプラクティスについて書きます。後半はそれらのプラクティスを導入し、継続していく時に気をつけている点を書きます。 前半：私がチームに参加したら最初に行う3つのこと 朝会 ふりかえり タスクボード 後半：変化を起こそうとした時の心構え的なこと 「やり始める」のは簡単 「やり続ける」ことの難しさ 「効果を