読者です 読者をやめる 読者になる 読者になる

@thorikiriのてょりっき

@thorikiriがWebとかAndroidとかの技術ネタや本を読んだブログです

アジャイルサムライ-達人開発者への道- その1

book development

えらいこと長い間詰んでありました。もっと早く読むべきでしたね。追いつきます。

アジャイルサムライ−達人開発者への道−

アジャイルサムライ−達人開発者への道−

今日は第I部について、第I部はアジャイル入門と言う事で、アジャイルの基本的な部分になりますね。お客様に価値のある成果を毎週届けると言うことですね。大きな問題は1週間には収まりませんので、価値のある単位で小さく分割し、それに集中し、他のことは今は考えないようにします。そして、それを動く状態で提供し、フィードバックを得ます。計画通りいかないこともあるので、その場合は計画を変更しようと言うことでしょうか。毎週成果を届けてフィードバックを得ると言うのは素晴らしいことですが、誰もがこの方法を気に入るわけではないのですね、私はいいと思うけどね。それが現実ですよね。
計画は、マスターユーザーストーリーとしてリスト化するよ。で、ざっくり規模と、それぞれがどれくらいで終わるのかの実績を取っていくと、ベロシティがわかるんだね。それを次へ活かすって寸法さ。むりやりやってたまたま運良く終わらせられるような奇跡のマネジメントは良くない。当たり前だね。実際にはおうおうにして奇跡に頼るんだけど。
ユーザーストーリーの開発の完了はどこなのか?それは、分析して実装してテストまでして完了と定義するんだね。そうでなければユーザにとって価値はないからね。

アジャイルなチームは一丸となる必要がありますね、そういう意味で一箇所に集まることは重要な要素といえますね。一箇所に集まれないからアジャイルは無理だと言う事にはなりませんけど。そして、顧客も積極的に関わってくる必要があります。誰のためのシステムかっ!
そして、目標を目的を共有して、自己組織化する必要があります。そのためには自分たちで見積もり、肩書きや役割にこだわらず、自ら動いていかなくてはならないね。そして、成果をあげると言う責任と、それに必要な判断を下すための権限を持っている、委譲されていることが必要になるね。
チームには、要求をもたらす顧客と、自ら何でも関わっていけるようなゼネラリストの集まりである開発者で構成されるね。もちろん、得意分野はそれぞれあるだろうけど、それしかしたく無いとか、それは私の仕事じゃありませんとか、そういう人ではダメなんだよね。結局のところ、当事者意識を持っていて、それに対応できる人でないとダメなんだ。

そんな感じの第I部はざっくりと全貌で、これ以降で掘り下げていく感じになるのでした。

目次