初めてのアジャイル開発
読んだり読まなかったりを繰り返していたが最近読了。
第2章 反復型と進化型
1年ほど前、イテレーション1のときの失敗談。
スコープ定義で決めたとおりにイテレーションが進捗しなかったので
イテレーション2を進行しながらイテレーション1で終わらなかったものを
実装するイテレーション1.1という意味のないイテレーションを作って
チームを混乱させたことがある。イテレーションはタイムボックス化した
ほうがよい。スコープ定義どおりに進捗しなかったとしたら振り返って、
次のイテレーションに含めれば良いだけ。
あとイテレーションの進行中に（スコープ定義の後に）新規で
タスクを追加しないほうが良い。
第3章 アジャイル
アジャイル宣言と原則が書かれている章。当たり前のことだが非常に大切な事が書かれている。
以下コピペ。
アジャイルソフトウェア開発宣言
- プロセスやツールよりも個人と相互作用
- 包括的なドキュメントよりも動くソフトウェア
- 契約交渉よりも顧客との協調
- 計画に従うことよりも変化に対応すること
アジャイル原則
- 最も重要なことは、価値あるソフトウェアを早い段階から継続的に納品し、顧客を満足させることである
- たとえ開発が進んだ後であっても要求の変更を歓迎する。アジャイルなプロセスとは、顧客の競争優位のために変化を生かすものである
- 動くソフトウェアを頻繁に納品する、その感覚は2,3週間から2,3ヶ月で、短いほど良い
- ビジネスサイドの人間と開発者が、プロジェクト全体を通じて毎日一緒に仕事をしなければならない
- やる気のある個人を中心にプロジェクトを構築する。環境を整え、必要なものを提供し、仕事をやり遂げてくれると信用することである
- 開発チームに対して、あるいは開発チーム内で情報を伝えるために最も効率的かつ有効な手段は、直接の対話である
- 動くソフトウェアこそが進捗を測る一番の尺度である
- アジャイルなプロセスは、開発の持続可能性を促進するものである。スポンサー、開発者、ユーザーが一定のペースを無期限に保てなければならない
- 技術的卓越性と優れた設計に常に注意をはらうことが、アジャイルさを向上させる
- 簡潔さ（できるかぎり作業をしないですませる術）こそ本質である
- 最も優れたアーキテクチャ、要求、設計は、自己組織化チームから創発されるものである
- チームは定期的に、より効果的な方法を検討し、自分たちのやり方を調整し適合させる
第7章 スクラム
ブタとニワトリが新しく開くレストランの名前について話し合った。ニワトリは「ハムエッグ」を提案したが、ブタは「それはごめんだね」と言った。「君は生むだけだけど、僕は切り刻まれるんだよ」
スクラムミーティングの際、チーム外のメンバー（ニワトリ）は輪の外に出る。
定義されたプロセスよりも経験的プロセスを重視することがスクラムの重要なテーマである。
これは良きこと。
総評
変化を受け入れる。コミュニケーションを重視する。フィードバックを受け入れる。
基本原則さえ守れているならどんなプラクティスでも良い。
P169 にすごく好きになった言葉があった。
複雑に考えることは簡単である。
単純に考えることは非常に難しい。
ー カーバー・ミード
初めてのアジャイル開発 ?スクラム、XP、UP、Evoで学ぶ反復型開発の進め方?
- 作者: クレーグ・ラーマン,ウルシステムズ株式会社,児高慎治郎,松田直樹,越智典子
- 出版社/メーカー: 日経BP社
- 発売日: 2004/09/09
- メディア: 単行本
- 購入: 2人 クリック: 113回
- この商品を含むブログ (59件) を見る
#agilesamurai dojo gathering 2012@オラクル青山センターに行ってきました
サムライ戦記実践編で登壇しました
サムライ戦記実践編で「内製基幹システムのOne-Iteration」というタイトルで登壇。
内製基幹システムのOne-Iteration
View more presentations from 知聖 竹之内
その時のTweetのトゥギャりは以下のリンク。
http://togetter.com/li/277905
資料について補足すること
資料はあまり細かく書いていないので補足します。
現在の基幹システムプロジェクトを1年と3ヶ月ほど進行しています。
プロジェクト初期
プロジェクト開始当時2週間（月曜始まり、金曜終わり）を1Iterationとして成果を
お届けしていたのですがスコープ定義とFeed backを行った結果のブレが大きかった
ことや開発人員が途中で1名増えるなどの要因があり1Iterationを1週間（水曜始まり、
火曜終わり）に変更しました。プロジェクト運営をして11ヶ月目のことでした。
当初「2週間でいいんじゃない？」という意見が開発メンバーから出ましたが
「2週間だと必ずしも当初要求通りに成果を届けられていないような気がしている。
1週間1Iterationを実験的にやってみないか？」と改めて開発メンバーに提案して
切り替えました。
金曜終わりから火曜終わりにしたのは、金曜をイテレーションの終わりにしていると
リリースのタイミングを合わせづらいのとイテレーションのクロージング、
イテレーションの開始準備の負荷が高いので火曜終わりにしました。
同じくプロジェクト開始当時、HudsonのようなCIを導入したいと思ったのですが
社内の関連部署にお断りされたのとそこまで緊急でもないので共用の開発機に
DailyBuild.shなるものを作ってcron登録を行いテストの自動実行環境を構築しました。
ついでにgrepでインデントや改行コードだけ簡易チェックを実施。
（静的コード解析を入れるのが面倒だった）。
改行コードをDOSで保存されてしまうと非常に稀ですがプログラムが正常に動作しなく
なったりバージョン管理の差分チェックで引っかかるなど手間が増えるので常にチェック
しておいたほうが良いです。DailyBuild.shは約1年以上、毎日稼動しています。
今は約1,200個のテストが稼動しています。他のプロジェクトのエンジニア（@katzchang）
からは「1年プロジェクト運営してその数は少ないよ」と指摘を受けていますが。
プロジェクトを1年運営してみて
1年以上開発を続けているけれども開発速度は落ちていません。というより、初期よりも速いです。
プロジェクト開始当時は要件が不確実なので思考錯誤と認識の相違で悩む時間や
手戻りが多くて開発速度がとても遅かったです。おそらく現在の半分程度の速度
だったんじゃないかなと思っています。
Day 1〜Day 4の開発プラクティス補足
TDDとテストの自動化を実施していないとリファクタリングはかなり困難であろう
という話もしました。テストが自動実行されていないと、テスト自体の品質が確認されていない
という事態になり、テストコードを信頼できなくなります。そこで前述のbash + cronが効いてきます。
Day 5の補足
Feed back MTGの難しいところは「顧客の時間を確保できないこと」です。
基本的に顧客は既存の業務で忙しいです。忙しいなか出ていただいても
ちゃんと動く画面を軽く実演したりするとOKとおっしゃってくれます。
リリースしたあとに本当は全然OKじゃないということに気づくこともありました。
こういうとき、顧客が忙しいということを認識しているにもかかわらずFeed back MTGの
進行や成果物自体を洗練させられていないことの問題はこちらにあります。
アジャイル関連の本にはよく、
「毎週Feed back MTGを開催して価値ある成果を顧客に届けよう！」
なんてことがサラっと書かれているのですが司会進行の能力や成果物の見せ方や勘所の
説明などは短いMTGの中で行う必要があるのでかなり難しくスキルを要求されます。
質問への回答
当日講演が終わってからの質問とTweet上での質問があったのでこちらに回答、記載します。
Q:リファクタリングをスコープに含めることは非常に難しいと思っている。どのように実施しているか？
これは我々のプロジェクトでもとてつもなく難しい。「リファクタリングを実施する」
といってもその成果を示すというのは至難です。この質問をされた時に改めて
振り返ってみました。我々のプロジェクトでは、「KPTのTryでリファクタリング
対象として認められた範囲かつ次のイテレーションに関係している場合は
リファクタリングを実施する」と、タイミングを見計らって押し込んでいました。
Q:今の環境で新しい言語、フレームワーク、開発方法の学習コストが高い、あなたのプロジェクトではそれをどのように支払っているか？
これは経験を話しただけで解決策を提示できていないのですが、ペアプログラミングや
コードレビューを行いながらそれ相応の時間を払っていくしかないんじゃないかと
答えました。プロジェクトごとに言語もフレームワークも開発方法も異なることは
仕方がないので都度学習するという方法しかないんじゃないかなーと。
我々のプロジェクトでも新しく人が入ったらそのあたりの習得には3ヶ月ほど
かかっていました。
一週間イテレーションが水曜日始まりな理由と二週間イテレーションを辞めた理由が大変興味深い。資料に載ってないけど。 #agilesamurai
上に記載しておきました。
やってみて思うのは、二週間でもイテレーションでやれることってそんな多くない。一週間のイテレーションでどれくらいの仕事がこなせるのか気になる。 #agilesamurai
2週間を1Iterationにしている時よりもMTGの時間は少し増えるので作業時間は減ります。
その代わり手戻りにかける時間は減ったと思います。
TDD で Functional tests なんて先に書けるものなの? #agilesamurai
TDDでFunctional testは書いていないです。Functional testを書くときは
大体以下の流れで構築しています。
- UT作成
- 開発
- リリース
- 運用
- Controllerのテストがあったほうがもうちょっと楽だよね
- Functional test作成
さらに質問があればこのエントリーにコメントに書いて頂ければと思います。
感想
基調講演からビアバッシュまでどれも面白かったけれど、個人的にはワールドカフェが
断トツに面白かったです。自分の経験とまだ経験していないことに対する疑問。
同じテーブルにいる方たちの経験とまだ経験していないことに対する疑問。
それをぶつけ合うのはとてつもなく面白い。
ワールドカフェでは、
の3つに参加しました。
- そもそもアジャイルとは何か？
- 人やエンジニアはどのような特性を持って業務を執行しているのか？
- 朝会っていいよね！
- 振り返りっていいよね！
そんな話をして盛り上がりました。こういう話は楽しい。来週から何をやろうか。
普段何を心がけようか、それらを考えさせられる良い機会でした。ワールドカフェ最高！
最後になりますがagile samurai dojo gatheringを主催してくれたスタッフ各位、
アジャイルサムライを書き上げた執筆者各位、この会に参加してくれて一緒に
議論してくれた参加者の皆さんに感謝いたします。
インデントを4spaceに、改行コードをunixに変換するシェルスクリプトを書いた
今のプロジェクトで適用しているルールで使用するものなので
完全にオレ専用スクリプト。github上に公開している。
あとはてなダイアリーでgist使えるか試したかったのでエントリー書いた。
validation
- 引数判定
- ファイル存在判定
- ファイルの種別判定（テキストのみ許容）
はてなブログに初投稿
初投稿テスト。
URLとか決められるのかな？
#97prog_ja プログラマが知るべき97のことの書評
プログラマが知るべき97のこと（通称きのこ本）の中から個人的に関心を
得た45のことを2011年8月から2012年1月までブログに書いてきた。
このエントリーはそのまとめ。
当初目的は2つあって、プロジェクトメンバーに対して、
「良いサービスを作るためには何が必要か？」
とプロジェクトメンバー内でサービスに対する考え方をシンクロ
すること。そして日々上司にエントリーを見てもらい、僕ら
プロジェクトチームが考える「良いサービス」と上司の考える「良いサービス」
をシンクロしたかったため。
成果を計測することはできないけれど、約半年、ほぼすべての営業日で
きのこ本を抜粋して、朝会で話してきてその目的は果たせたと思ってる。
また、当初目的には無いが、僕自身きのこ本で感銘を受けたエントリーを
抜粋し、考えをまとめることで幾分か成長することができた。
| 05 | 美はシンプルさに宿る |
| 06 | リファクタリングの際に注意すべきこと |
| 09 | 他人よりもまず自分を疑う |
| 14 | コードレビュー |
| 18 | 学び続ける姿勢 |
| 19 | 誰にとっての「利便性」か |
| 21 | 技術的例外とビジネス例外を明確に区別する |
| 22 | 1万時間の訓練 |
| 24 | 変更を恐れない |
| 25 | 見られて恥ずかしいデータは使わないこと |
| 26 | 言語だけでなく文化も学ぶ |
| 28 | 「魔法」に頼りすぎてはいけない |
| 33 | オープンソースプロジェクトで夢を実現する |
| 34 | API設計の黄金律 |
| 35 | 超人の神話 |
| 36 | ハードワークは報われない |
| 37 | バグレポートの使い方 |
| 38 | 余分なコードは決して書かない |
| 46 | すべきことは常に明確に |
| 48 | いろいろな言葉を学ぶ |
| 51 | プロジェクト自身にしゃべらせる |
| 52 | 「その場しのぎ」が長生きしてしまう |
| 56 | 未来へのメッセージ |
| 60 | 真実を語るのはコードのみ |
| 64 | プロのプログラマとは？ |
| 65 | バージョン管理システムを有効に使う |
| 66 | いったんコンピュータから離れてみる |
| 67 | コードを読む |
| 68 | 「人間」を知る |
| 70 | シングルトンパターンの誘惑に負けない |
| 72 | シンプルさは捨てることによって得られる |
| 75 | 面倒でも自動化できることは自動化する |
| 76 | コード分析ツールを利用する |
| 78 | テストは夜間と週末に |
| 79 | テストのないソフトウェア開発はあり得ない |
| 80 | 1人より2人 |
| 82 | 他者への思いやりを意識したコーディング |
| 83 | UNIXツールを友にする |
| 84 | 正しいアルゴリズムとデータ構造を選ぶ |
| 90 | コードを見る人のためにテストを書く |
| 91 | 良いプログラマになるには |
| 92 | 顧客の言葉はそのまま受け取らない |
| 93 | エラーを無視するな |
| 95 | ペアプログラミングと「フロー」 |
| 10 | 日本人プログラマによる知っておくべき10のこと 名前重要 |
- 作者: 和田卓人,Kevlin Henney,夏目大
- 出版社/メーカー: オライリージャパン
- 発売日: 2010/12/18
- メディア: 単行本（ソフトカバー）
- 購入: 58人 クリック: 2,074回
- この商品を含むブログ (325件) を見る
2012年
もう少し具体的に、取り組みたいことを書く。
特にテーマというわけではないが"この1年が楽しければ良い"。
やってみること
ユーザ要求の理解力を高める
2011年、ユーザ要求の理解力が低いと感じている。どう
理解力を高めるか？多分ユーザにすぐ使ってもらうように
すること、制作側の議論を活発にするしかない。実際に
出来たかどうかは仕事のアウトプットにつながる。
設計のスキルを高める
2011年、設計で外してしまうことがたまにあった。
どう設計のスキルを上げるか？DDD本をしっかり読み込んで
定期的にアウトプットを出していく。アウトプットは仕事以外
にも自分のブログに書いたり、会社のブログに書いたり、
社内外問わずLTしたりしても良い。何をアウトプットしたか
2012年中にまとめてみる。
OSSプロジェクトに貢献する
これは単にやってみたいこと。
Symfony2で翻訳作業やってみたい。
2012年に理解するテクノロジー
一エンジニアとして必須で抑えておきたいというだけ。
- git & github
- Jenkins(CI)
- Symfony2
ダンス
なんとなくやってみたい。なんとなく。
身体の動かし方を理解しておきたい。
料理
また一人暮らしを再開するので料理スキル上げたい。
katzchangをリスペクトして頑張りたい。
#97prog_ja 92 顧客の言葉はそのまま受け取らない
これはいつだって意識すること。僕は顧客の言葉を鵜呑みにしない。
顧客が自らの要望を完璧に伝えられないと思っている。これは顧客を
馬鹿にしているのではなくて、要望を伝えきるということが至極難しい
ことであるためだ。例えば僕自身が顧客の立場に立ったとして、やはり
すべての要望を完璧に伝えきる事はできない。誤りもあるだろう。
顧客の言葉に耳を傾ける時は「本当に顧客が求めているものはなんな
のか？」ということに意識を集中させなければならない。
本当か嘘かは知らないけど、車がまだ無い時代にヘンリー・フォード氏が
顧客から言われたのは「今より早い馬が欲しい」だったとか。
この要望の本質は「今より早い移動手段」だ。
自分の希望を伝えるのを嫌がる顧客はまずいないでしょう。少なくとも私は会ったことが
ありません。ほとんどの人は、尋ねれば、詳しく希望を話してくれます。問題は、顧客が
いつも本当のことを言うとは限らないということです。嘘をついているわけではありません。
ただ、顧客とプログラマとでは話し方が違うのです。顧客には顧客独自の用語とコンテキ
ストがあります。私達から見れば、非常に重要と思われることをまったく話さないことも
よくあります。
