書籍でたどる「リーン」の本質
先ごろ出版された「リーン開発の現場：カンバンによる大規模プロジェクトの運営」（ヘンリック・クニバーグ著／オーム社／2013年10月）は、アジャイル開発手法を実践事例の視点から解説した力作である。スクラム、カンバン、XPなどの手法に言及しているが、中でも「リーン開発」を正面から取り上げているのが大きな特徴となっている。 本書ではリーン開発現場の写真、会話をふんだんに使って事例解説がなされていたり、まさに現場でプロジェクトに立ち向かっているマネージャ、エンジニアたちによって訳されていたりと、実に臨場感あふれる仕上がりとなっている。ちなみに著者のヘンリック・クニバーグ氏は私の長年の友人であり、本書、日本語訳巻末の解説も私が担当した（詳細はこちらで紹介している／参考リンク：「リーン開発の現場」紹介ページ）。 ただ「リーン」という言葉は、米国で注目を集めた経営書「リーンスタートアップ」で広く知られる
TDDという名の幻想... - Qiita
TDDは死んだ。テスティングよ栄えよ。 by DHH http://d.hatena.ne.jp/yach/20140424#p1 【翻訳】TDD is Fun http://diskogs.hatenablog.com/entry/2014/04/25/085112 を読んで思ったことをつらつらと書いてみます。 TDDはできれば、やったほうが良いのは確か？です。 しかし、実際の開発現場で全面的に採用するのは ミドルウェア等の画面の存在しないソフトの開発以外では ほとんどの場合、無益です。 なぜなら、TDDを採用すると開発時間が膨らむ、すなわち、開発コストが 膨らむからです。そして、ソフト開発では細かな仕様は変化していきます、 するとTDDではそれに合わせ、テストを修正していかなくてはなりません。 また、TDDで書かれたテストが全てのケースを抜けなく網羅できていること は稀です、抜けは必ず
ペアリング対コードレビュー: 開発者文化の比較
前職 と 現職 で、ペアプログラミング文化からコードレビュー文化への移行を経験した。文化の差に適合するのは興味深い経験だった。ちょっと気づいたことを書いてみよう。 (ペアプログラミング|コードレビュー)の(メリット|危険性)みたいな題名の記事はもう山ほどある。著者はどっちかの信奉者なわけだ。私は明確トレードオフがちょっとあるにせよ、どっちの戦略も有効であると認識している。このトレードオフについて、もうちょっとバランスのとれた議論をしてみようと思う。 用語の定義 まず、舞台を整えよう。”ペアプログラミング” とか”コードレビュー”という言葉は、人によってとらえ方が大きく異なることがある。 ペアプログラミング文化 といったとき、作業のほぼ100%をペア作業で行っているチームを指す。一つのタスクに二人の開発者が割り当てられ、同じ画面を共有して作業をする。開発者は両方コード構築のプロセスに関わって
ワンクリックデプロイ 〜いつまで手でデプロイしてるんですか〜 #devsumiA
2013/2/15に目黒雅叙園で行われたデブサミ2013 15-A-7セッションの資料です。Read less
こんなプログラマはアジャイル出来ますって言ったらアカンやろ - メソッド屋のブログ
最近、とある機会があって、いろんなアジャイルが出来るといってくるベンダーさんとあう機会があるけど、正直「おい！どの口がアジャイル出来るって言ってるねん！」って思う事がむっちゃくちゃ多い。 今は確かにアジャイル開発ブームで、世間では引き合いも多いらしい。いろんなベンダーの営業さんが、「うちもアジャイルできます」って言って営業してはるけど、マジでちゃんと自社でできるか調査してから営業してほしい。私はアジャイルを１０年以上やってるけど、元々は「この方法やったら、お客さんにホンマにええアプリを届けれるんちゃうか？」と思ったところから来ている。 それが、今や猫もしゃくしもアジャイル出来ますとか言って、ろくにアジャイルも出来へんのに売りつけて、結局効果がでなくて、「やっぱアジャイルなんかアカンやん」ってなるのがむっちゃくちゃ嫌なのだ。 これって数十年昔のオブジェクト指向ブームと一緒やん。当時のオブジェ
「アジャイル開発基本のキ リターンズ 完全版」#agilesamurai #横浜道場 - ヲトナ.backtrace
5/25 に開催されたアジャイルサムライ読書会 横浜道場で話しをさせてもらいました。 当日の資料は以下になります。 この資料は、今年開催された AgileJapan2012 の時の資料に、時間の都合上割愛した部分と現場に何か持って帰る切っ掛け作りのワークショップを足したものになります。 ＃タイトルは半分悪ふざけですww これは普段の仕事で、これからアジャイル開発を始めたい人向けのセミナーに利用しているものなので、今回のアジャイルサムライ読書会の参加者には物足りないんじゃないかと心配でした。 また、仕事あがりの時間帯から約 2 時間ぐらいの仕事っぽいセミナーとかやってゴメンなさいww でも、少なくともワークショップ部分はみなさん楽しそうだったので、何とか喜んでもらえたんじゃないかと、ひと安心しました。 それよりも、後半は僕の方が体力フラフラな感じになって、質疑応答とかだいぶ言葉足らずになって
being agile: Frank: Automated Acceptance Tests for iPhone and iPad
Friday, July 23, 2010 Frank: Automated Acceptance Tests for iPhone and iPad Recently I joined a team developing an iPad application. The application had no existing automated tests, and the team was under a tight deadline to deliver on promised functionality. Faced with similar circumstances in the past I have advocated introducing automated UI-driven acceptance tests to establish a loose but broa
ソフト開発における受発注契約慣習の弊害と対策 ― ＠IT
いまの技術は20年前の技術と比べると面影も残さないくらい進化したにもかかわらず、受発注の契約システムはそのままという点についてとても疑問に思います ITによる業務の効率化は大企業だけのものではなく、中小企業経営の基盤をも支えるようになった昨今、市場競争はますます激化しています。少ない投資で大きな利益を上げるためにはIT投資の仕組みを正しく理解し、そのリスクの少ないIT化戦略を取らなければなりません。テクノロジの進歩はインターネットへ接続可能なPCと携帯端末の普及をもたらしました。いままでITと無関係だった人たちにも（ITは）身近な存在となったことにより、ITをベースとしたサービスの市場は拡大傾向にあります。 その一方で、いくら良いアイデアやサービスを思い付いても市場への投入が遅れればすぐに競争力を失うことになります。そのため迅速に価値のあるシステムを構築することが望まれています。IT投資に
Redmine0.9.0のスクラム化 – タスクボード（Task Board Plugin）で見える化
Redmine Kanban Pluginではチケットの移動ができなかったので、タスクボードプラグイン（Task Board Plugin）を試してみる。 作者はバーンダウンチャートと同じ人みたいでScrum Alliance Developer Team開発のものですね。 GitHubからダウンロード。Downloadファイルがなかったので、これもTortoiseGitで落としてきました。バージョンは1.0.0です。 例によってRedmine0.9.0で動かすために、langフォルダをconfig/localesに変更して中身を以下のように修正。日本語化もしておく。 https://gist.github.com/daipresents/17cd91b69efbb90214ff4af8ae058211.js?file=gistfile1.txt こんだけで動いた。ラッキー。 チケットの移
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Kent Beck氏、ごく短期のプロジェクトではテストを省略することを提案
はてなブログ | 無料ブログを作成しよう
History of WaterFall
IBM Developer