転職おめでとう!
酒飲んだ後ブログ書くのは初めてか?
ま、書きたくて仕方ないので、書くことにする。結構個人的な想い満載だが、それほど本当に今宵は嬉しい夜だったから。
同士が転職すると、さっき聞いた。
失礼ながらちょっと意外だったが、でも本人が自分の実力を試したい環境を見つけられたことはとてもいいことで、素直に嬉しい。目の前を考えると同士が辞めるというのは寂しいけど、これは健全なことだし、そういう判断を出来た同士をオレは尊敬する。
オレは新卒からとあるSIerにずーっといる訳で、去年ぐらいから、社外に出ての活動を本格化させ、ブログもはじめ、twitterもちゃんと見るようになり、有志のアジャイル系社内コミュニティがちょうど1周年になるいま、このタイミングだったから余計に衝撃も大きい訳だが、正直な話。
でも、オレは会社に雇われているけど飼われている訳ではないし、SI崩壊とかSIの闇が騒がれる今だからこそ、オレは今の環境でチャレンジしたいことがある。ディフェンシブという言葉がぴったりなSIビジネスだが、受託開発の喜びは言葉にできない素晴らしいものだし、だからこそ今の環境を変える試みに引き続きチャレンジし続けたいとおもっている。その同士だった親友が自分の人生の岐路を判断して新しい道に進むことは素晴らしいことで、お世辞でもなくオレは応援している。
「夢」を叶えるのは会社というステージではなくで、「人生」というステージの上である!!
俺の中で いっしょに仕事してみたいマネージャ一位は10年前から変わらず @ryohei_nakazawa だ。その機会がないのが残念でならない。 / @ryohei_nakazawa: チームメンバが活き活きしている、あの感動を思い出した
#natsumiB3
— ますごん (@ymasuda_) 2014, 8月 1
だから、お互いの環境は変わっても、「夢」の実現はできる。
そうだろ?
一緒に仕事をすることもその「夢」の一部かな〜
嬉しい言葉をありがとう。
お互い頑張ろう(・∀・)!!
夏サミ2014に行ってきました!
※講演資料やまとめへのリンク先を更新(2014/8/2)
今日は月末恒例、パケット上限での帯域制限を喰らっている日。こんな日はwifi環境が整備されているところがマジデ天国デス!!(・∀・) 東京五輪といわず、wifi充実はもっともっと加速度的に進んでほしいな。
さて、今日は久しぶりに御茶ノ水に行ってきました。
初めての夏サミ参加でテンション真夏。
Developers Summit 2014 Summer [Enterprise] #natsumi
SI終末論を良く耳にする今日この頃。
この問題は長らく言われ続けていて、アジャイル開発とともにユーザー企業の内製化は進み、クラウドの普及で自前システム不要からの情報システム部門不要や、納品のない受託開発の成功とか、色々な話がごった煮で如何せん整理するのが大変。
でも、次のSIの形を模索する自分としては、得るもの多く、とても刺激になる話が多かった1日でした。
今日の一番の収穫は、受託開発ならではの「喜び」に気付き直せたこと。
これは、[B-3]セッションGxP・商工リサーチの事例、および[B-5]セッション倉貫さんのお話がメインから。
商工リサーチの300人月の再構築では、8割ウォーターフォールで作って、残り2割をアジャイル型でテスト・改善の繰り返しという進め方で成功したということだが、(GxPの鈴木さん・和智さんが)プレゼン内容でフォーカスしていたのは、受託開発として最も基本的な顧客とSIerの「信頼関係」部分。確かに、顧客と二人三脚でプロジェクトを進めるってSIer側としては理想的で、本当にそれが出来た(お客さんが認めてくれた)時の喜びは、言葉にできないぐらい感動的なもの。
倉貫さんは「納品の無い受託開発」のダイジェスト話の中で、ネタを振りまきながらソフトウェア開発がナレッジワークであることや働くエンジニアの満足度を大事にしながら、その上で、顧客から信頼してもらえて仕事が続くという受託開発ならではの「喜び」に言及されていた。倉貫さんの初リアルプレゼン、沢山笑わせて頂きました(・∀・)
この2点は、顧客向けの受託開発プロジェクトを少し離れている自分に、大切なものを思い出させてくれた。共通するのは顧客とシステムサイドが同じ目的を目指している形。これらの話を聞いてて、自分の中では、いくつかのプロジェクトの場面がスナップショット的にリフレイン。お客さんと一緒にリリースを喜び、道玄坂を転げ落ちてスーツを破いたあの日や、納品日のチーム解散のふりかえりで、メンバ12人とお互い涙を流したあの日とか、色々なシーンがリアルに甦ってきて、1人で遠い眼をしてしまった・・・
技術がどんどん進歩し、新しいビジネスモデルができたり、働く場所がオフィスだけでなくなったり、仲間との国境がなくなったり・・・・そんな劇的な変化が起きている今だからこそ、B2Cでグロースハックもいいけど、「人と人」が「感動」できる『受託開発』はやっぱりいいな、と。
SIの形が変わっても、この「喜び」は変わらないのではないでしょうか。
とても大きなヒントを頂きました。
あ、あと、世間様からSIerは「業者さん』って呼ばれないようにもっと変わりたいぞ
[B-1]のKDDIの話は聞けずに残念。でも色んな方のTweetに感謝。まとめでみてます。
夏サミ2014【B-1】KDDIのAgile&DevOpsへの挑戦と戦果 #natsumiB1 - Togetterまとめ
あと、Twitterやブログで知っている有名な方々と名刺交換とかご挨拶できたのも、本日の収穫♪♪♪
SNSやブログでも今後ともヨロシクお願いしますm(_ _)m
これは、モノにつられて・・・頂いちゃった本。パクえ吉田さんありがとうございます! もっと勉強しますw
しかし、中指が使えないと、タイピングが遅くてイライラ・・・ しかも包帯グルグルだから、タッチパッドでのスクロールが人差し指と薬指は厳ちぃぃぃorz
明日の仕事が思いやられるわ😭
・講演資料とTogetterまとめ
エンタープライズIT版のデブサミ「夏サミ2014」開催、講演関連資料のまとめ:CodeZine
・参加した他の方の記事・ブログ
夏サミ2014で確認したユーザー企業と開発ベンダーの姿 #devsumi #natsumi #natsumiB1 #natsumiB3
夏サミ 2014 『KDDIのAgile&DevOpsへの挑戦と戦果』聴講メモ #natsumi - べにやまぶろぐ
Agile Conference Tokyo 2014 に行ってきた!!
梅雨明け、そして熱帯夜・・・ (;´∀`)フゥ
皆様いかがお過ごしですか?(;´∀`)フゥ
先日久しぶりに外部セミナーに行ってきました。品川シーサイドは1年ぶりかな。しかし、朝から疲れた〜 あの通勤ピーク帯、ここのたった一駅移動で消耗するHPはマジ計り知れず・・・なんか去年よりも人が更に増えたような・・・(;´Д`)フゥ
※ってこの写真、全然人がいないやん!!
先月のAgile Japan は残念ながら業務で行けなかったのですが、今回は抽選に当たって(?)行くことができました。
Agile Conference Tokyo 2014という、テクノロジックアート社主催。
去年は「KANBAN」がテーマで、今年は「継続的デリバリーとDevOps」がテーマ。
特にThoughtWorks社のお二人の話が面白かった!
1.エンタープライズDevOps: 開発とIT運用間の障壁を取り除くには
ー Jez Humble氏 (ThoughtWorks Inc.)
2.アジャイルなプロダクト計画策定と分析手法
ー 藤井 拓氏 (株式会社 オージス総研)
3.アジャイル開発を支えるコード品質とリスク解析
ー JUNG Sang Hun氏 (コベリティジャパン 株式会社)
4.Thoughtworks社による海外導入事例
ー Xiaoshen Wang氏 (ThoughtWorks Inc.)
5.継続的デリバリーの実現へ!
ー 江木 典之氏 (日本IBM)
ー 英 繁雄氏 (日立ソリューションズ)
ー 岡下 浩明氏 (RedHat)
- DevOpsの言葉の定義が大分、広義になってきたようである。ソフトウェアの開発と運用の障壁を取っ払っていきましょいって元々言っていたが(狭義のDevOps)、ビジネスとITの融合まで含んでDevOpsという言い方をほとんどの人がしていた。ま、確かにそれはそうなんだけど、コンテキストによってさす範囲の意味が変わってくるから気をつけないとね。(※後述)
- オーストラリアの保険会社における分散アジャイル開発(thoughtworks事例)は、ソフトウェア開発の事例というよりも、業務とITの融合を含めた新しいビジネス創出の事例。例えば、スーパーマーケットでバーコードをスマホでスキャンし、その場でPayしてレジに並ぶ必要がないアイディアとか、あ、これは保険会社の商品ではないか。言葉は違えどリーンスタートアップの思想に考え方は近い。ITでマーケティングの常識が変わってきた話とも取れた。
- Jez Humble氏(Continuous Deliveryの著者)曰く、アジャイル開発はまだまだ、ウォーター・スクラム・フォール開発である、との認識のようだ。つまり、本質的なアジャイル開発はまだまだってこと?
- 継続的デリバリーはCI等の自動化必須だが、それは作業効率化だけでなく、どれだけ効果的に学べるか(Feedbackを受けることができるか)に繋がってくる。
継続的デリバリー 信頼できるソフトウェアリリースのためのビルド・テスト・デプロイメントの自動化
- 作者: David Farley,Jez Humble,和智右桂,高木正弘
- 出版社/メーカー: アスキー・メディアワークス
- 発売日: 2012/03/14
- メディア: 大型本
- 購入: 24人 クリック: 567回
- この商品を含むブログ (51件) を見る
今日のテーマはDevOps(と継続的デリバリー)。そもそもDevOpsってなんだっけ?
前にも書いたように「アジャイル」って言葉も同じことが言えるのだが、「アジャイル開発」がだんだん、ビジネスや経営レベルを含めた広義な意味でもつかわれるようになったように、DevOpsにも同じことが言えるというのが、今日、複数の登壇者に共通していえることのひとつ。
つまり、開発だけでなくて、運用も含めて、(DevelopmentとOperationの)障壁を無くしてうまくやりましょって狭義のDevOpsが、ITと製品戦略・マーケティングとビジネスモデルそのもの全部をうまく回していきましょって広義になってきたってことを再認識した訳です。
ん?それってリーンスタートアップじゃん?って言う人がいても同じで、結局、「広義のアジャイル」「広義のDevOps」「リーンスタートアップ」の意味することが近づいてきちゃって、人によってはますます混乱する・・・的な。
プログラマのためのリーン・スタートアップ入門(最終回):リーン・スタートアップの実践――ソニックガーデンは2度ピボットした - @IT
にもあるとおり、
リーンスタートアップ = マーケティング + DevOps(開発はアジャイル)
という整理が一番しっくりくるので良いのですが、この辺の言葉の定義の境目がもう曖昧になってきたってことですね!
今回のセミナーでもそうでしたが、自動テスト〜継続的インテグレーション〜継続的デリバリーをまとめている絵がいろいろありますが、どれも間違っていないとはおもうのですが、まとめる人の意図によって(若干)異なる。当然。
DevOps、アジャイル、リーンスタートアップ・・・同じ視点に立てばどれも考え方は共通であるため、そのベースを共有した上で、議論すれば言葉に惑わされることはないかな、なんて思いました。
あ、今月は夏サミにもいけそう♪( ^ω^)ワクワク
(おまけ)
会場で質問できなかったので、Jez Humble氏にTwitterで質問したら、凄いスピードでレスが帰ってきたw
Feedbackが早いって素敵☆
アジャイルって何だ? 〜今だからもう一度整理し直してみる〜
[2014/5/29]スライド内の誤字を修正し再UP、一部追記
1ヶ月ぶりの投稿です・・・
サボり癖がついてしまうとホント悪循環。この1ヶ月間、書きかけた記事3本(未だ編集中)。これは本当にいかん!
よし、言い訳はしない。
「今回こそは!」必ず書き切る。
今日のテーマは、「アジャイル」「Agile」という言葉・単語・keyword。
自分が初めて「アジャイル開発」を知って、たぶん10年ちょっとが過ぎた。
最初はXPのプラクティスやプロジェクトファシリテーション的なことを、自チームに取り込んでみたり、であったが、当時社内(自チーム外)でアジャイルの話をすることは殆どなかった(ような気がする)。
時は経ち、「アジャイル開発」はソフトウェア製品開発では当たり前となり、2、3年前ぐらいから徐々に、企業向け大規模SIの領域にも「アジャイル」は徐々に浸透してきた。そして最近では、結局「アジャイル」って何なの?という声を良く聞くようになってきた。昨年「アジャイル」と銘打つ社内コミュニティを立ち上げたことも影響あるのかもしれない。
特に今、自分は、「アジャイル」を整理して説明することが求められているケースが増えつつある。
確かに、記事タイトルやプレゼン資料で踊る「アジャイル」「Agile」というkeywordにはいろいろな意味が含まれている。
客観的に見ながら結局、何なの?という意見が出るのも分かる。
そんな今だからこそ、自分なりに整理してみる必要を感じた。
整理すると2つの軸がある。よこ軸とたて軸。
絵にするとこんな感じ。
ざっくり言うと・・・
[よこ軸]
アジャイル開発におけるコミュニケーション面とエンジニアリング面
これはシステム開発・ソフトウェア開発のシーンにおいて、分野が異なる。しかも「アジャイル開発」とは言わず「アジャイル」と言うことが多いので、次の縦軸を踏まえると、聞き手によっては混乱を招くことがある。
[たて軸]
変化の中で継続的に成長するという、ビジネスの本質的な側面
これはレイヤーが異なる。マーケティング的な意味も含めた組織活動そのもの、と、(プロジェクト・チームの)開発活動に限定した使い方である。後者(a)についてのみ、よこ軸がある。
「グロースハッカー」に象徴される、昨今のビジネス成果とエンジニアリングを密接に考えなければいけない傾向が、このレイヤーの混乱も招くことがある。
ちなみに、これは平鍋氏の言うアジャイルのライトウィング・レフトウィングにも繋がっている。というかヒントにさせていただいた。パクリとも言う。(しかし、この整理は素晴らしい!!初めて見たときマジ感動した!!)
[2014/5/29]追記
それからアジャイル開発とフォーターフォール開発の違いについては倉貫氏がblogで分かりやすく解説されている。
アジャイル開発の本質 〜 アジャイルとウォーターフォールの違いとは | Social Change!
以下、先日の勉強会で発表した資料。
[2014/5/29]スライド内の誤字を修正し再UP
個別のプラクティスをさして「アジャイル」とも呼ぶし、もっと広い範囲で「アジャイル」と呼ぶこともあり、その意味はコンテキストによって微妙に変わってくる。
想像してほしい。コミュニケーション上で、お互いの認識がkeywordレベルで噛み合っていないときほど、辛いことが多くないだろうか。
おそらく、そんな時の会話では、言葉の意味する範囲を自分の都合のいいように変えながら話していることが多いのではないだろうか。(自戒を込めて・・・)
しかし、言葉の定義という意味では、そんなものなのかもしれない。
新しい言葉というのはどれもそういう側面を持っているし、新しければ新しいほど、keywordの定義も発展途上であることがおおく、このような整理を都度都度繰り返していかなければいけないだろう。
投資家、経営陣、コンシュマー・・・。
お金をPayする人が「アジャイル」「Agile」を理解しているとは限らない。むしろ、このような方の専門はシステム開発・ソフトウェア開発ではないことが多い。投資してもらうためにも説明責任はこちらにある。説明して納得してもらえなければ、どんなに素晴らしいチャレンジでも投資してもらえないのだから・・・
よし、書き切ったwww
第4回Quesにいってきた
オバマ大領領を接待となると、銀座の寿司屋も三ツ星なのですね。うらやま。
さてさて今回は、初めてTwitterで誘われたイベントに行ってきました。
その名も第4回Ques(イケテルQAエンジニアの集い)@渋谷ヒカリエDeNA社。
@ryohei_nakazawa はじめましてQues運営スタッフです。4/22に第4回開催決定いたしましたので、是非ご参加おまちしています! http://t.co/yn2Fx0e31M
— イケテルQAエンジニアの集い Ques (@Ques_staff) March 14, 2014
なんてお誘い頂いちゃったり。
中の方、ありがとうございました!
現在の業務が、ソフトウェアの品質保証にモロ近いところにいるということから、自分がイケテルかどうか確認しにいったのですが・・・
自分があの集まりでおそらく唯一のネクタイキャラだったため、ある意味、イケテなかったかもorz
確かに自分は、ちょっと前までQAとQCの違いを人に説明することもできず、基本的にはプロセスベースの品質保証の方がメインなので、ちょっと場違いな感も。
でも、面白い話が沢山聞けて、交流会でも普段お会いできない方々と情報交換できて、大満足♪♪♪
テーマ:テスト自動化について
講演内容:●機械学習分野におけるテストの自動化(小宮氏、ALBERT)
■機械学習分野におけるテストの自動化
・機械学習の応用例としては、AmazonのReccomendやスパムメールフィルタリング。
・機械学習アルゴリズムのアプトプット(テスト結果)が期待する結果と同じかどうかを検証するのが難しい。(=期待する結果を定義しにくい)
→ codeレベルのテストの重要性
・レイヤーに分けてテストするとか、機械学習機能ソフトとはいえ、普通のソフトウェアのテストと考え方は通じるところ多し。
→ 機械学習アルゴリズムの検証と、ビジネスロジック検証、End2Endでの機能検証を分けて考えるとか
・自分が目指すのはデータサイエンティストではないものの、そっち系の勉強がまだまだ足りないな
■ Mobageオープンプラットフォームでのテスト自動化
・SoftWare Engineer in Testを略してSWET
・SWETグループは、組織として独立したテスト専門部隊(googleのSET+TEイメージ)
・SWETグループの技術者は各プロジェクトに散って入り込んでいて、朝はプロジェクトのスタンドアップ、昼はSWETのスタンドアップ
・テストを自動化しても、機能が増えれば増えるほどテストコードも増えてくる。そこでCI。
・Webブラウザとスマホブラウザの両方(マルチプラットフォーム)を同じようにテストするため、SeleniumとAppiumを利用し(テストコードの共通化が結構できる)、テスト自動化を実現。
・実機でのテストと、実機レステストは使い分ける。
・SWETグループのモチベーションを保つための工夫。自分たちはエンジニアである。テストをすることが目的ではない。テストはあくまで手段。リリースし続けることに自分たちの価値があるなど。
最後に。
技術的な話にはだいぶついていけていなかった自分ですが、自分の知っているQAの世界よりも相当広い感じだなーっていうのが一番印象深かったです。
でも、例えばWebサービスに代表される開発がアジャイル的なソフトウェアの品質をどうやって保証(担保)するか、これはとっても大事なテーマであることはわかってるつもり。
第5回もあったら行きたいな〜〜〜(・∀・)
「失敗の本質」を読んで共有・議論してみた
今日の夜は、毎月開催している社内勉強会。
実はMacbook Airでのプレゼンデビュー♪♪♪
いままで自分が知らなかっただけなのですが、keynote(OfficeパワポのMac標準版)のスライドショー機能がホント感動的。単に手元で次スライドも見えて、かつ時間が表示されてるだけなのですが・・・
今回のお題は2つ。後者が自分発表。
・ スクラムの起原を追う「失敗の本質」より
そういえば、結果的にみごとアジャイルのライトウィングとレフトウィングになってるじゃないですかwww
いつもに増して、議論は多方面かつノンストップに盛り上がり・・・
まずは発表したスライド。
ちなみに、本を読んだ直後のblogはこちらで、それを共有用にまとめた感じ。
失敗の本質―日本軍の組織論的研究 - 部屋とアジャイルと私(仮称)
結構みんな食い付きがよく、議論も白熱。
「沈黙は美」とか「あうんの呼吸」とか「水に流す」とか日本人独特のでも脈々と遺伝子に刷り込まれているような文化的に思い当たる節がみんなある模様。たとえば、知識よりも経験ベースで物事を判断しがちで、システム保守プロジェクトなどのドキュメント化もされない秘伝のノウハウが脈々と受け継がれるか、本当にあるある。
ナレッジマネジメントの重要性はは組織の経営側はどこも感じることだろうし、でも知識の集約と再利用には、どこも悩みを抱えていると仮定して、その理由は当時の日本軍にも日本の企業組織にも共通しているという視点は、いろいろと視野を広げる。
ただ、
今回だけの話では、アジャイル開発におけるスクラムとのつながりにはたどり着かず、その点は、自分も含めて消化不要。
今後の継続テーマでもある。
そういえば、今回に限らず、グローバル化というキーワードはいつでもでてくるのだが、その中ではよく「日本と諸外国の違い」が話題に出る。具体的な違いを単純化するのは難しいが、ビジネスとITの今後を考えるうえで、日本の文化や特徴を勉強することはとても価値があるとおもう。
というか、
自分が歴史(特に日本史)大好き人間なだけかもしれないがwww
しかし、また読みたい本がまた増えて、読むペースが追いつかない・・・orz
Agile Samurai Base Camp 2014 Re:TDDに参加してきた!
うらら〜。うらら〜。春うらら〜。
今日、日曜日は、渋谷マークシティのCA社(2回目)に行ってきました。
実は1回目は昨年12/8。このblogを始めるきっかけにもなった、感動と、衝撃と、自分も動き出さなきゃ!っていう最高の刺激を頂いた機会であり、はてブやTwitterのプロフ写真も・・・(ry とにかく個人的にとても想い深いイベントでありまして・・・
とにかく、その刺激がリフレインしまくったそんな一日でした。
※ピザとbeerの交流会もあったり、前回以上にいろいろなお話を聞いたり、質問できたり、満腹♪満腹♪
※この手作り感も大好き!!
※スピーカーの皆様、スタッフの皆様、お話しできた皆様、本当にありがとうございましたm(_ _)m
12/8の最初の記事。
Agile Samurai Base Campに参加してみた - 部屋とアジャイルと私(仮称)
その後、社内勉強会でTDDのサワリを発表したり、すんごいモチベーションもゲッツ。
明日からTDDをやってみよう! - 部屋とアジャイルと私(仮称)
TDDと直接関係ないが、前回もご説明いただいた同じスライドでも、1回目に感じなかったことが、沢山あったこと自体、blogを始めたおかげであり、そんなきっかけを頂けたことを改めてここに感謝♪感謝♪感謝♪
しかも前回に増して、参加者メンバの中でも、TDDを実際にやっている方(チームだったり、個人だったりはさておき)が結構いて、その現場の本音を聞けたのもすごい収穫でした。
自分は、まだまだ、TDDを「分かった気になってしまっていた」ってことに気づかせていただいたのも、とっても良かった。
分かったつもり、一番の自分の悪い癖。
(・A・)イクナイ!! (・A・)イクナイ!!
うむむ。相変わらず前振り長すぎ・・・orz
~~~~~~~~~~~~~~~~~
■当記事のアジェンダ
(1)今日の自分テーマ
(2)結果サマリ
(3)その他、雑メモ
(4)補足・・・関連リンク集とか
~~~~~~~~~~~~~~~~~
(1)今日の自分テーマ
事前に考えていた、今日ノ場で学びたいこと主な5つ
●仕様のテストと実装のテストの件。実装詳細をテストする必要はないとある。でも不安をテストするともある。自分が前回一番理解できなかった(勘違いしてるっぽいところ)
●レガシーコード改善から始めるTDDに取り組む件(これが一番自分の周辺にハマりそう)
●テスト粒度(テストコードのメンテナンスと、テストコードの資産価値、小さいテストを積み上げてEnd2Endのテスト、どこまでがTDDなのか)
(2)感想サマリ
※自分テーマと順不同
●テストを必ず先に書かなければいけない訳ではない。そこにテストコードが存在することが重要。あまり原理的になる必要はなく、その辺の加減・工夫がいろいろな現場でいろいろ方にノウハウあり、自分なりにTDDをうまく使えるようになることが一番大事だろう。
●TDDはプログラミングの一部であり、TDDだけで品質が保証される(担保される)わけではない。TDDでソースもエンジニア自身も「健康に」というメッセージは非常に深い!
●仕様のテストこそ、テストコードとして価値がある。実装のテストはリファクタリングすることでテストコードが崩れてしまうので、積極的に書くのではなく、でも不安がある場合は、一歩一歩階段を上るという意味でも実装を確認する。(=思った通りに動くことを確認する=つまり不安をテストする=TDD)
※「仕様のテスト」と「実装のテスト」についての参考:
●エンジニアのスキルアップには、フィードバックが細かければ細かいほど良い。TDDのサイクルは小さく小さく回したほうがいい。(でも自信があるときは大股で走ってもよく、でも一歩一歩確認しながら、赤くして自信があってたことを確認する癖をつける)
●自身のモチベーションを保つための工夫は人それぞれ。ひとりから始められるのもTDDのいいところ。こういう社外勉強会にも今後積極的に参加していきたい!
(3)その他、雑メモ
・チームで考えるワークショップいかにボールにチーム全員が触るか(19秒→3秒→0.9秒)
・今年後半ぐらいに「テスト駆動開発入門」が本屋に並ぶかも
・リファクタリングがし難い環境が身近にある・・・動けばいいじゃん。壊したくない。という堕落と恐怖(グサっ!)
・必ずテストコードから書かなくてもよい。少し実装してからテストから書いてみるのもあり。
・リファクタリングは、気づいたときにすぐにやったほうがいい(溜まれば溜まるほどリファクタリングに時間がかかり、理解がないとそんな時間はモラエナイ)ただし、少し先にどのようにリファクタリングすればいいかの答えが見つかりそうなときは一時的にtodoリストに書いておくのもあり
・テストコードが無い現場にて、TDDを普及させていくため、まず最初、まずは依存の少ない部分を狙い撃ちして、テストコードをつくりはじめるとよい。また、その際は大きな仕様のどんどん荒いテストから作り始めて、テストして、カバレッジ範囲を少しづつ広げていくことを繰り返していくとよい
・JUnitの場合、テストコードにGroovyを使うとよい。(これは良いことを聞いた〜)JUnit実践入門「テストフィクスチャ」をあとで見る。
・オフショアでTDD(というかアジャイルプロセスでの開発)を導入している事例。交流会で「アドバイスください」と図々しく・・・、でも、そのチームだけにMacを与えて、周囲が憧れる開発環境のチームをつくるとよい。実は投資額としてはちょっとしたもの。何よりMacでの開発は良いyo!とかナルホドー
・新人研修でテストコードを書かせて、TDD実践のハードルを下げて組織的に取り組む姿とか眩し(真似したいけどなぁぁぁ)
・テストを書きながら進めることで、安全に前にすすめる
(4)補足・・・関連リンク集とか
Agile Samurai Base Camp 2014 Re:TDD #agilesamurai - Togetterまとめ
Agile Samurai Base Camp 2014 Re:TDDに参加してきました - 個人的なまとめ
Agile Samurai Base Camp Re:TDD に行ってきた! - 終電23時15分って早くね?
アジャイルサムライ TDDトラック行ってきた - まっつんの日記
Agile Samurai Base Camp 2014 Re:TDD|ラブリー東京♡気まぐれコリアンの東京日記
※随時追記ヨテイ(しかしみんなblogうp早〜! )
JUnit実践入門 ~体系的に学ぶユニットテストの技法 (WEB+DB PRESS plus)
- 作者: 渡辺修司
- 出版社/メーカー: 技術評論社
- 発売日: 2012/11/21
- メディア: 単行本(ソフトカバー)
- 購入: 14人 クリック: 273回
- この商品を含むブログ (67件) を見る
Fearless Change アジャイルに効く アイデアを組織に広めるための48のパターン
- 作者: Mary Lynn Manns,Linda Rising,川口恭伸,木村卓央,高江洲睦,高橋一貴,中込大祐,安井力,山口鉄平,角征典
- 出版社/メーカー: 丸善出版
- 発売日: 2014/01/30
- メディア: 単行本(ソフトカバー)
- この商品を含むブログ (8件) を見る
まだまだ整理が必要で混乱もしている。
自分で手を動かしながら、体現しつつ、少しづつでも前に進みたい。
いきなりTDDというおっきな相手に立ち向かうのではなく、分解して1体づつ倒していく・・・そんなTDDのイメージで、これからもTDDを続けていこう!!
余談
インセプションデッキの2回目もあるらしいよ〜〜〜〜っ ( ̄ー ̄)ニヤリ