2013-03-04
『アジャイル開発とスクラム』と『SCRUM BOOT CAMP THE BOOK』を読んだ
今回は今年1月、2月に発売されたスクラム系の本2冊。
アジャイル開発とスクラム 顧客・技術・経営をつなぐ協調的ソフトウェア開発マネジメント
- 作者: 平鍋健児,野中郁次郎
- 出版社/メーカー: 翔泳社
- 発売日: 2013/01/18
- メディア: 単行本（ソフトカバー）
- 購入: 1人 クリック: 12回
- この商品を含むブログ (13件) を見る
- 作者: 西村直人,永瀬美穂,吉羽龍太郎
- 出版社/メーカー: 翔泳社
- 発売日: 2013/02/13
- メディア: 単行本（ソフトカバー）
- 購入: 5人 クリック: 13回
- この商品を含むブログ (23件) を見る
最初は別々に記事を書こうと思っていたのですが、書けるときに書いておかないと両方書きそうにないので、まとめてしましました…。
購入理由
前者は『ユーザー向け』というのに興味をもったからで、後者は
感じたことをざっくりまとめると
アジャイル開発とスクラムが経営層・プロダクトオーナー対象、SCRUMBC本がスクラムマスター対象かな、という印象を受けました。
アジャイルサムライ*1などは開発チームを対象にしている印象があるので、三点セットで読めばアジャイルやスクラムを学べるのではないでしょうか。
スクラムを通して考える
アジャイル開発とスクラムでは、ソフトウェア開発におけるリーダーシップと企業理念・イノベーションについて、スクラムを通して考えることになります。
SCRUM BOOT CAMP THE BOOKでは、スクラムを通して"学びの仕組み"について考えることができます。
雑感
SCRUMBC本にはプラクティスという言葉がほとんど（もしくは全く？）出てこない。TDDやペアプロなどの言葉も登場はするものの、言葉の説明はない。"Scrum Boot Camp"の本だからなのかはわからないですが、この割り切り(?)方は好きです。
対して、アジャイル開発とスクラムにはプラクティスが概説されています。こちらは"ユーザー向け"だからこそ説明を入れたのでしょうか。
そう考えると、この2冊(サムライ入れると3冊か)は絶妙なバランスですね。
気になったところ
SCRUMBC本、p109。
ボク「1週間で8ポイント…全部で168ポイントだから…」
ボク「今の人数で5ヶ月あれば…イケる！」
ボク「ブチョーと営業部長のところに行ってくる！」
キミ「いってらっしゃい…って、なんなの…」
SCRUM BOOT CAMP THE BOOK
仮に1ヶ月=4週間計算だったとして、5ヶ月で160が限界なのではー、と思った*2のはさておき。
これ、どう説明したのだろうね…というところが気になっていたりします。
おわりに
各視点から考えてみたい、学びたい方にもお勧めです。
アジャイル開発とスクラム、SCRUM BOOT CAMP THE BOOKは読書速度の早い方なら土日で読みきれると思います。わりと遅めの私でも前者は3日、後者に至っては1日かからなかったので。ちなみに、アジャイルサムライも3日くらいあればたぶん読めるので、読書の苦手な方にも大変親切な3冊ですね。
最後に。この文章は実践が伴っていない感想なので、仕事でScrumチームに入る日が来れば、改めてもう一度読み直して感想を書こうと思います。
Permalink | コメント(0) | トラックバック(0) | 08:44
2013-01-20
今年はじめのTDDBC大阪(通称3.0)を開催しました
1/12に2013年はじめのTDD Boot Camp in 大阪を、1/13に2013年はじめのTDD Boot Camp in 大阪 外伝を開催しました。
色々と書きたいことはあるのですが現在進行形で修論の理に導かれているので、空き時間に随時更新していきます。
謝辞
- 会場スポンサーの株式会社Aiming様、および会場スタッフとしてお手伝いいただいたAiming社員さん
- 講演もしくはディスカッションに登壇していただいた和田さん、渡辺さん、西さん、いろふさん
- 当日スタッフおよびTAな方々
- TDDBCのMLで意見を投げてくださった皆様
- 本イベントに参加された皆様
ありがとうございました。
誰かが欠けても、本イベントは開催できなかったと、振り返ってみて改めて感じます。
開催理由
一部禁則事項に触れてしまうためすべては書けませんが、年始めにどでかい花火を打ち上げたかったとかそういうわけではないはずです。
一日目
いつもの内容で構成しました。
ペアプロの相方PC環境で苦労する問題はどうにかならないかなと思いつつ、今のところ初日にSCMBCを開催するしか思いついていないのが現状です。
何かないですかねぇ…。
二日目
当初はレガシーコード改善がいいなと思っていましたが、MLで「TDDBCで魂を削る必要は無い」という意見をいただいたため、最終的に「他人のコードを引き継ぐ」に変更しました。
イベントのゴールをもっと明確にすること、課題の難易度をもう少しゆるくすることが次回開催時に気をつけたいところでしょうか。
あとはこの大量のKPTをみると大体のことは察せると思われます。
TDD Boot Camp(TDDBC) - TDDBC大阪3.0/KPT
雑感
そういえば、今のTDDBCとかつてのTDDBCでは雰囲気全然違うなーとか思ったりします。
どっちが良い・悪いとかそういう意味ではありませんが、なんとなくそう感じます。
あと「手を挙げれば誰でも始められる」という言葉がかつてはありましたが、今はどうなのだろうと開催中に思ったりしたのでした。
あー、もう一つ。
全工程終了後のスタッフ振り返りはスタッフオンリーでやるべきだと反省しました。
コンテキスト共有が難しいのですよね…。
おまけ
F#でやってみていましたが、私の残念加減が露呈しただけでした。とりあえず残骸を晒しておくのでどなたか改善してくだしあ。
https://gist.github.com/4605144
おわりに
終わりは始まりのための終わりなのだよ、とよくわからない言葉で締めておきます。
Permalink | コメント(0) | トラックバック(0) | 14:14
2013-01-17
関数型言語を独学で勉強している学生です に対する私的考え
http://oshiete.goo.ne.jp/qa/7896221.html がTLで流れてきて、ちょっと思うところがあったので書きなぐっておきます。
なお、先に下記記事を読むことをおすすめします。丁寧かつとても面白い内容でした。
関数型言語を独学で勉強している学生です への答 - Oh, you `re no (fun _ → more)
これを読んで、自分でも少し言語化しておきたいと思いました。なので、投稿されていた質問に対する、昨年就活をしていた私個人の考えというか感想っぽい何かを簡単に書いておきます。
関数型言語で何か作って、それが新卒採用で評価されることはあるのか
あります。
私はいわゆる関数型言語の一つと言われているF#のコードを提出して、内定を頂きました。なので、技術を重視する会社であれば少なくとも可能性はあると思います。"可能性がある"と書いたのは、おそらく採用というのはコードだけで判断されるわけではないはずだからです。
ただまぁ、ほとんどの会社が"個人作成のオリジナル品"を要求するでしょうし（そうでないならコード要求しないと思います）、提示された条件をクリアしたコードである必要はありますよね、と。
いくつかの言語を試したほうがいいかも
（定義は人それぞれですが）関数型言語といってもたくさんあるので、納得がいくまで色んな関数型言語を触ってみるといいのでは、と思いました。そして、実用的なものがかけた言語でコード提出してみると。
これは時間の許す限りでしか行えない方法なので、時間のない場合は触ったことのある言語でやるしかないでしょうけれども…。
なぜ関数型言語のコードを提出したいのか
仕事で使いたいから、関数型言語に多少でも興味を持っている会社に就職したいから、自分の書いたコードが関数型言語のものしかないから…理由は様々あると思います。
いずれにせよ、何かしら肯定的な考えを持っていない限りは、無理してまで関数型言語で作ったものを提出しないほうがいいと思います…ってこれは書かなくてもわかることかもしれませんが。
何を作る？
別の言語で実装したものを移植してみる、とかでもアリなのではないでしょうか。車輪の再発明にはなりますが、まったく新しいものを作ろうとして挫折するよりは気が楽かなと。
以上、なげっぱなし記事でした。
Permalink | コメント(0) | トラックバック(0) | 20:36
2012-12-20
NaturalSpec+unquoteで出力をリッチにしようとしたけど現実は厳しかった
TDD Advent Calendarの没ネタその9。先月やってみようと思っていて忘れていた一品（昨日思い出した）。
PowerAssertあるよね
Groovyのあれ。あれいいよね見やすくて。
F# でも似たようなものがあるよ
その名もunquote。本家サイトトップページの一番下に"Unquote was inspired by Groovy Power Asserts"と記述されている。
ちょっと仕組みについては割愛させていただく。
きちんと更新されているみたいだし(.NET4.5に対応できているかしらないが)、使ってみない手はないでしょー。
まぁ、本家サイトにも書かれている通りNUnitやMSTest、あとFsUnitなら普通に動く。そんなにいじるわけでもないのでそりゃそうだ、という感じ。
NaturalSpecでやりたい
NaturalSpecはGiven,When,It shouldなんちゃらなどの関数を使うため、そのままではunquoteの関数は使えない。いや、GivenWhenを使わなければ使えるのだけど、それではNaturalSpecの意味がなくなるので。。。
というわけでNaturalSpecのUtil.fsやらSyntax.fsに存在する関数のうちいくつかを上書きしてみた。
そしてテストコードを書いた結果がこれ。
[<Scenario>] let ``とりあえず割り算のテスト``() = Given (1,1) ||> When (fun x y -> <@ x / y @>) // うにょーん |> It should equal 2 |> Verify [<Scenario>] let ``リスト操作のテスト``() = Given [1;2;3;4;5] |> When removing 3 // removingはシャドウィングでコードクォート用のものを作った |> It shouldn't contain 3 |> It should contain 4 |> It should have (length 3) |> It shouldn't have duplicates |> Verify
ラムダ式…これはきつい。コードクォート内に式を書かなければならないので仕方のないことだが、それでも全テストにラムダ式はきつい。ラッパー関数を作るにしても、数が多ければきつい。私は悲しい。
テスト結果はこちら。
UnquoteSpec.とりあえず割り算のテスト: Elements are not equal. 1 / 1 = 2 1 = 2 false UnquoteSpec.リスト操作のテスト: (Seq.filter (fun y -> 3 <> y) [1; 2; 3; 4; 5] |> Seq.length) = 3 (seq [1; 2; 4; 5] |> Seq.length) = 3 4 = 3 false
通常のものよりはかなり見やすい気がする。そして、出力に関してはこちらでいじれるのでもっおなんとかできる気がする。気がするのだが・・・やはりテストコード側がネックだ。
というわけでF# erのどなたが素晴らしい改造を施してくださることを祈りつつ、私はunquoteを使う場合はFsUnitにしようと妥協するのだった。
ソース
見るからにNaturalSpecのコードをラッパーしたとしかいえないですね。
Permalink | コメント(0) | トラックバック(0) | 13:52
2012-12-18
TDDのテストと型のような話
TDD Advent Calendarの没ネタその8です。前記事のリストに入れ忘れていたので、先に取り上げておきます。
個人的にこう考えてみたというだけで、間違っているかもしれないので反論、意見等大歓迎です。あと、うまくまとまっていませんごめんなさい（なので没ネタだったのですが）。
注意事項
これは静的型付け偏重な人物が書いたものです。戯言だと思ったら戯言だと思ってスルーしてください。
また、他の静的型付け言語利用者は異なる意見かもしれないことをここに記しておきます。調査してみたいところではありますけどね。
型とテスト？
確か、TDDBC大都会の懇親会でid:t-wadaさんとの会話していた時、何かのタイミングで「動的型付けってテスト多くならないですかね」と発言してからこの話になったと記憶している。
静的型付けの場合、型チェックは基本的*1にコンパイル時にコンパイラにやってもらえる。動的型付けは実行時に型の判定が行われる。期待された型と合致しない場合に暗黙的な型変換が行われるかどうかは、言語・処理系依存なのでちょっと脇においておく。
動的型付け言語の場合、型と合致するかどうかの判定や判定後の動作（分岐処理を書くか、実行時エラーなげてもらうか、etc）は開発者にお任せだろう。そして基本的に、こういった判定や型による分岐はあまり書かないのではないだろう。
TDDにせよ何にせよ、設計も考えずにいきなりコードを書き始めることはあまりないと思う。「モジュール（クラス）名はこれで関数（メソッド）名はこう、引数は…具体的なデータで考えるとhogeというデータの型はこれ、返り値は…」と、テストやコードを書くためにそれなりのことを考えるはずだ。そこには型もしくは具体値（テストデータ）も含まれる。こうして考えたことを元に開発を進める、テストを書く、設計を見直す、リファクタリングする。
ここで一つ思うこと。動的型付け言語が書ける、もしくは好き（と書くと誤解を生むかもしれないが）な人は、引数や戻り値の型を決めたときに、それ以外のデータ型をメソッドに渡さない自信があったり、仕様変更があったとしても「テストがあるから対処できる」という自信があるのではないだろうか？いや、自信はいいすぎかもしれないが。それが当たり前、という感じなのだろうか？
これならなるほど、「あなたが思っているほどの分量を、動的型付けのテストで書くわけではないよ」という言葉は納得できる。"当たり前なことに対して不安を持つか？"と問われ「不安あるよ」と答えるのは、当たり前が信頼できないか疑問を抱いているときだ。
ちなみに私は現時点では「不安かな」と答える。
静的型付けでは機械がチェックしてくれていたものを「入れないはずだからテストしなくてもいいよ」と言われて、はいそうですかと言えるほどの自信はない。あったものがなくなったのだ、不安になってしまう。そして、"不安をテストに"という信条のもと行う場合のTDDにおいて、これほどまでに書きたくなるテストはない。慣れていない、熟練度が足りないと言われてしまってはそれまでだけれども。
確かに自分だけが使う小さなコードであれば、なんとかなる。目の届く範囲だからだ。
では規模が大きくなり、複数人で開発するときはどうだろうか？"慣れ"と"動的型付け流なテスト"だけで、どこにバグが潜んでいるかを素早く発見できるだろうか？mergeした時に、型が変わっていたけどテストは全部通ってしまった、なんてことは本当に起きないものだろうか？
今の私には、判断材料がない──
まとめ
というわけで「テストたくさん書かないと…」「なんでそんなに書かないといけないと考えたの？」という話を思い出しながら書いたよ、というなげっぱなしな記事でした。
Permalink | コメント(0) | トラックバック(0) | 20:44
*1：リフレクションやvoid*はあえてスルーしておく
