私は夏休みの宿題のやり方を教えてもらったことがありません。約2ヶ月という限られた時間で、どういう風に消化していくと良いのかを学習したことがなかったのです。 夏の終わりに24時間テレビが放送されますが、あれを見ながら、答えをチラ見し、綺麗なドリル(*1)を1冊消化するのは忘れられない子供の頃の思い出です。 この経験はソフトウェア開発にも似ていて、開発の手法を知らなければ、良い結果を生むのは難しいのです。不幸なことに、夏休みの宿題のように明確に何をやるべきなのか、明確では無いのです。 夏休みの苦い思い出と、ウォーターフォールっぽい大失敗プロジェクトの経験をいくつか得た上で、アジャイルソフトウェア開発を学ぶことによって、ソフトウェアのつくりかたを学びました。 これは、中小のSIerでも、イケてるWEBサービスを提供している会社でも教えてくれたことではありませんでした。そう、夏休みの宿題のやり方を

アジャイルと銘打ってあるが、アジャイルを包括的に扱うという よりもかなりXPよりに書いてある。 XPを取り入れるには、この本のとおりに実践するとかなり良い感じに なりそう。 XPのもっとも好きな部分でもある「シンプルな設計」の記載が良いと 感じた。 YAGUNIやfail fast は、どんどん実践していきたいと思う。

「ウェブリブログ」は 2023年1月31日 をもちましてサービス提供を終了いたしました。 2004年3月のサービス開始より19年近くもの間、沢山の皆さまにご愛用いただきましたことを心よりお礼申し上げます。今後とも、BIGLOBEをご愛顧賜りますよう、よろしくお願い申し上げます。 ※引っ越し先ブログへのリダイレクトサービスは2024年1月31日で終了いたしました。 BIGLOBEのサービス一覧

第4.3章アジャイル度を評価しよう ＊＊要約＊＊ アジャイル度の評価ができる ・考えること ・協力すること ・リリースすること ・計画すること ・開発すること の５つについて診断をする ＊＊感想＊＊ 一番低かったのは開発することでした。 とくにバグに関しての診断が低くでました。 プログラムが動く動かないという問題ではなく、顧客からの指摘で仕様バグが見つかった、ということがよくあります。 顧客同席＆顧客テストがあれば仕様バグは減ると思います。 実施できていないプラクティスの中で、これがホント一番切実にやりたいです。

第7.1章完全Done コーディングが完了したからといって、そこで仕事が完了したとは言えない！！ プロダクトレベルに達したときに完了したと言える。 １週間で設計からコーディング、移行、レビューをへて受け入れ完了までってなると、ストーリーをどう設定するかが肝だなーと思いました。 価値観がいい具合に壊れたのは、リファクタリングが終わって初めて設計完了と言えるということ。 しかもチームが満足するようにリファクタリングする。 設計完了はドキュメントだけじゃなくてコードに深く依存しているんですね。

第6.1章信頼 顧客とプログラマの間の「私たち対彼ら」という考え方 という言葉が実はけっこう見に染みました。 うーん、仕事をしてると心のどこかでそういう考えになってしまいがちです。 全員同席が難しいなかで、思いやりの心を築くにはどうすればいいんだろう？ ・毎週のリリースを実際手で触ってもらって、プログラマが今週なにを作ったのか知ってもらう。 →１週間でプログラマが実装できる量を知ってもらうことができ、無理な要求がでにくくなるかも。 ・イテレーション会議に参加してもらって、どの機能を優先的に実装するか意見をもらう →顧客が本当に求めているものを知る機会になる。 あとは旅行のお土産を渡すとか、他にもきっと色々あると思います。 思いやりの心をお互いに築けたら、信頼にもつながるはず。

第5.1章ペアプログラミング ＊＊感想＊＊ ピンポンペアリングがとてもおもしろそうだと思いました。 一人がテストをかいて、もう一人が通す。 次は通した方がテストをかく、という方法です。 すごく簡単なコードですが、試しにyoshioriさんとやってみたら楽しかったです。 現在のペアプロをやっている際の私の反省点として、 ・どうしても先生と生徒のようになってしまう ・黙ってしまう があげられるなーと思いました。 黙ってしまうのは、頭の中で考えていることを発言して改善できたらな思います。 先生と生徒になってしまうのは、プログラミングスキルアップで改善したい！