はてなブックマーク

挙げだすときりがないが、代表的な課題をいくつか挙げよう。 人材。優秀なエンジニア 従来型の企業文化と組織 技術的プラクティスの導入および安定稼働させるインフラ・ツールの整備 協力会社（国内・海外）との契約と働き方 個人単位の人事評価 ソフトウェアの会計上の扱い 物理的なコロケーションスペース 他にもアジャイル導入を難しくしているものがたくさんあるだろうが、わたしが１番ハードルが高いと思っているのは人材だ。とりわけ、開発チームの人材である。 開発チームは単にプログラムが書ければよいというものではない。わたしの考えるアジャイルにマッチした開発者はこれだ。 ・人間関係構築能力 ・柔軟性 ・学ぶ力 ・顧客主義のマインドセット ・テクニカルスキル ひとつずつ説明していこう。 ・人間関係構築能力 アジャイルはチーム単位で共同する。同僚の開発メンバーもいるし、スクラムマスター、そしてプロダクトオーナーも

完了の定義について問い合わせが多いので書いておこう。 英語では、”Definition of Done” とか、”Done Done” と言われる。日英ミックスで「Doneの定義」と言われることもある。 外国人と仕事していると”Everything’s done!”等、頻繁に耳にする言葉だが、一般的にはステーキを注文する際、お肉の焼き加減を伝えるときに”Well-done”と伝える位だろうか。 プロダクトマネジメント、とりわけスクラムでは、「完了の定義」はマストである。そして完了の定義は開発者のものである。 字面の通り、何をどこまでやったら「完了」なのか明確化しておくために定義する。 プロダクトインクリメントは開発メンバーが共同して作り上げる。 チームとして仕上げる条件を決めておかないと仕事のできばえにバラツキがでる。同一プロダクトなのに部分部分でムラがでるとやっかいだ。だから、開発チーム

「私どもは、アジャイルをしています。スクラムチームもあります」 クライアントから、こう説明されることがある。 「スクラムは既にできているから、全社的にスケールするために支援して欲しい」という依頼である。 こういったケースでは、まず1番進んでいるチームを見せてもらう。 だが。。残念ながら、本当にスクラムができているケースは全体の2割程度だ。。 今回は、スクラムの公式ガイドを基準に、「大抵できていない」ところを説明していこう。 スクラムガイドは黒太字で転記し、私の解釈と考えは青字で示している。 スクラムは無料であり、本ガイドで提供されるものである。スクラムの役割・イベント・作成物・ルール は不変である。スクラムの一部だけを導入することも可能だが、それはスクラムとは言えない。すべてをまとめたものがスクラムであり、その他の技法・方法論・プラクティスのコンテナとして機能する。 毎日朝会をしているから