この門をくぐる者は一切の希望を捨てよ – Agile 2011 Conference フィードバック
今日は、社内でAgile 2011 Conferenceのフィードバックを発表させて頂きました。 フィードバックについて 近いところで働いている人中心の勉強会だったのですが、たくさんの人に聞いていただけてうれしかったです。ただ、時間が足りず、途中駆け足になってしまったり、説明がうまくできていない部分があったと思います。しかも、最後のまとめ部分は、僕が考える未来。そしてそれは限りなく、今の現場の話だったので、自分自身、答えが出ていない部分があり、ものたりない方もいたかもしれません。ごめんなさい。 最終的に伝えたかったのは、例えとして表紙にした「地獄の門」をくぐるぐらいの覚悟がないと、現状をよくできないのではないかという危機感でした。そして、今回はアジャイル開発の話が中心でしたが、そういった武器を持って、乗り越えていく人がいたら、その人と働きたいなぁという気分も入っています。 全部を説明すると
Scrum Gathering 日本でやるよ。(10/19, 10/22)：An Agile Way：オルタナティブ・ブログ
Jeff Patton と Henrik Kniberg が来日して、スクラムギャザリングを日本ではじめて開催されるらしい。 Jeffは、ユーザーストーリーマッピングや、とてもユニークなプロドダクトオーナーコースで有名。ソルトレイク出身です。聞いたところによると、今回は日本はじめてだそうです。ぼくは2003年からお世話になっているので、彼が日本に滞在するのは、とてもうれしい。 Henrikは、スクラムとカンバンの両方を武器に、現場にあったやり方を提案するのが得意。2009年に、北欧から来日し、一緒に愛知県豊田市を訪問した仲間です。 二人とも今のアジャイル会では、とても人気があるスピーカーです。ぜひ、ご参加をお勧めします。 Day 1: 2011/10/19(水)は講演中心で、有料。 Day 2: 2011/10/22(土)はワークショップ中心で、無料。 らしいよ。それに、この週の他の日には
Top 100 Agile Books (Edition 2011) - NOOP.NL
Note: this is an old list. Go here for the Top 100 Agile Books 2013. One year ago, at the Agile 2010 conference, I came up with the idea to publish a Top 100 Agile Books. Like many of my other top 100 lists it was a great success (in terms of blog traffic). This year I am not at the Agile 2011 conference (for various reasons, both good and bad). But nevertheless, I decided to publish a new edition
ペアプログラミングについてみんなが誤解していること | Act as Professional
プログラマ1人で完成できる仕事に、2人のプログラマを投入して、直感的に判断してペアプログラミングを拒否する人がいます。これには大きな間違いとリスクが潜んでいます。ペアプログラミングに対する真実を理解しましょう。 ペアプログラミングはコードを書く時間が15％増える 1999年にユタ大学でおこなわれた実験によれば、設計の時間を別にして、ソロプログラミングに対してペアプログラミングを実施したペアは平均して15％多く、プログラムを書く時間に費やしました。 では、なぜペアプログラミングを選択するのか？ 将来的なテストと現場のリソース要求を減少させるためです。一般的なシステムにバグが見つかると業界のデータでは、33時間から88時間を修正に費やすそうです。これが、開発期間中に欠陥を修正すると0.5時間から88時間の時間を節約できることになるのです。したがって、ペアプログラミングは寿命の長いソフトウェアほ
新しい契約形態での受託開発サービス「価値創造契約」での第1弾システムが無事稼働し始めました - Ruby x Agile
木下です。 昨年11月のニュースリリース以来、大きな反響をいただいている価値創造契約ですが、その第1弾として、首都圏を中心に理科実験教室を展開されているサイエンス倶楽部様の基幹システム開発を受託し、今年の1月より開発を行っていることはAgile Japan 2011のセッションでもご報告していた通りです。 その後、予定していた通り、今年の6月よりこのシステムは稼働を開始しています。サイエンス倶楽部様にはここ1ヶ月間、システムを使っていただいていますが、大きなトラブルがないのは言うまでもなく、現場のユーザーの方からも高いご評価をいただいています。 6月末にサイエンス倶楽部様と私たちの開発メンバーでふりかえりを行いました。ふりかえりの中でも多くのフィードバックや気づきを得ることができました。今回の開発については新しい契約形態でRubyを使ってアジャイルに開発した事例として、追々みなさまにも公表
Scrum Boot Camp横浜を開催しました
6月18日(土)に横浜のアットウェアさんの会議室でScrum Boot Camp横浜を開催しました。 Scrum Boot Campとは以下のようなことを目的としたセミナー＆ワークショップです。 たぶん日本では初めての開催でしょう。 定員は30人で、当日の欠席率は0でした(すごい！) 概要 Scrum(スクラム)は竹内弘高氏、野中郁二郎氏が1986年にハーバードビジネスレビュー誌にて発表した「New New ProductDevelopment Game」を元にしてジェフ・サザーランド氏らが考案したアジャイル開発手法の１つで、近年アジャイルな開発の手法として日本国内においても急速に採用事例が増えています。 一方でコーチや経験者の指導のないままに表面的なプラクティスを導入し、結果としてあまりうまくいかないというケースも良く聞くようになりました。 そこで今回はこれからScrumを導入して
コードは負債、少ない方がいい
あなたにとって重要なトピックや同僚の最新情報を入手しましょう最新の洞察とトレンドに関する最新情報を即座に受け取りましょう。 継続的な学習のために、無料のリソースに手軽にアクセスしましょうミニブック、トランスクリプト付き動画、およびトレーニング教材。 記事を保存して、いつでも読むことができます記事をブックマークして、準備ができたらいつでも読めます。
アジャイルチームにおけるコードレビュー - Sean_SF’s blog
@daipresents さんが「アジャイルなレビューをサポートするツールを5つ」というブログ記事を書かれていました。 コードレビューによりコードの品質を改善することは知られていますが、@daipresents さんのチームのように実際にコードレビューを行っているチームはそれほど多くないと思います。 アトラシアンにおいては、基本的に全てのコードをレビューしています。その方法やヒントなどを説明したブログを以前にいくつか公開しておりますので、参考までに抜粋して下記します。 アジャイルチームにおけるコードレビュー - パートII コードレビューを行う際に留意すべき点として以下の9つを挙げています。 軽量に保つこと 強制しないこと 細かく管理しないこと 非同期のレビューを奨励すること コードレビューを通して、興味深い発見、構成、設計上の決定を積極的に共有すること - チャンピオンになりましょう コ
いいアジャイルと悪いアジャイル
スクラムはラグビーにおいて最も危険な段階であり、それというのも、潰れたり不適切なかみ合い方をすると、前列のプレーヤーが怪我をしたり、首の骨を折る危険すらあるからだ。—Wikipedia 私が子供の頃には、コレステロールは体に悪いものだった。これは覚えやすかった。脂肪は悪い。コレステロールは悪い。塩分は悪い。みんな悪い。しかし近頃では、コレステロールが「いい」コレステロールと「悪い」コレステロールに分かれている。私たちがこの2つをどうにかして見分けられるとでもいうように。そしてその切り替わりは奇妙なものだった。FDAが突然プレスリリースを発表して、殺鼠剤には2種類、いい殺鼠剤と悪い殺鼠剤があり、いい方はたくさん摂って悪い方は摂ってはならず、そして決して2つを混ぜたりしてはいけないのだと言ったかのようだった。 一年くらい前まで、私はいわゆる「アジャイル」プログラミングに対して、ごく一次元的な見
IPA、アジャイル開発向け契約書の草案を公開
情報処理推進機構（IPA）のソフトウェア・エンジニアリング・センター（SEC）は2011年4月7日、アジャイル型開発プロジェクトをITベンダーに発注する際の契約書のひな型を公開した。「アジャイル開発に注目が集まるものの採用が進まない障壁の一つが、適した契約書のひな型がなかったこと。日本の大手ベンダーでも策定していなかった」（IPA/SECの山下博之 エンタプライズ系プロジェクトプロジェクトリーダー）。アジャイル開発は1週間から1カ月といった期間での開発（イテレーション）を繰り返しシステムを完成させる手法。 契約書は2種類ある。一つは「基本/個別契約モデル」と呼ぶもの。プロジェクト全体で開発を委託する基本契約を締結した後、イテレーションごとに個別の契約を結ぶモデルである。基本契約は法的拘束力はなく、個別契約に共通する事項を定める。個別契約はイテレーションで開発する機能が定まっていない場合は準
アジャイル開発 基本のキ - ヲトナ.backtrace
今、アジャイルの導入のお手伝いをさせてもらっている現場で「他のスタッフにもアジャイルについてざっくり教えてよ」というオーダーで勉強会をやりました。 そこで「アジャイル開発 基本のキ」と題し、実際の進め方の説明ではなく、その手前の考え方や心構えにフォーカスして話をしました。 20名ほどの人数向けに作った資料なのですが、普段アジャイルについてのイントロダクションの話をする時にいれるキーワードは大体盛り込んだ感じになったので、もしかすると誰かの役に立つかもしれないので公開しておきます。 ただし、勉強会のターゲットがエンジニアではなかったので、エンジニアリングについては薄くなっているのでご注意を。 Basic of Basics of Agile DevelopmentView more presentations from Nishimura Naoto. あと、話は変わりますが、普段アジャイル
スクラムの生みの親が語る、スクラムとはなにか？ たえず不安定で、自己組織化し、全員が多能工である ～ Innovation Sprint 2011（前編）
スクラムの生みの親が語る、スクラムとはなにか？ たえず不安定で、自己組織化し、全員が多能工である ～ Innovation Sprint 2011（前編） アジャイルなソフトウェア開発手法としてもっとも広く使われているのが「スクラム」です。このスクラムは、1990年代半ばにジェフ・サザーランド（Jeff Sutherland）氏らによって提唱されたものですが、その考え方の基盤となったのが1986年に一橋大学の野中郁次郎氏と竹内弘高氏が日本企業のベストプラクティスについて研究し、ハーバードビジネスレビュー誌に掲載された論文「The New New Product Development Game」でした。 1月14日にコミュニティが主催し都内で行われたイベント「Innovation Sprint 2011」は、このスクラムの生みの親と言える2人、野中郁次郎氏とジェフ・サザーランド氏がそれぞれ
「契約もアジャイルに」、中堅SIerの新たな挑戦 － ＠IT
2010/12/07 「アジャイル」といえば、ソフトウェアの開発手法として近年注目を集めてきた。半年や1年といったプロジェクト期間で完成品を作る「ウォーターフォール型」ではなく、2週間程度の短いサイクルで、途中経過であっても実際に動くものを見ながら開発を進めるスタイルだ。事前にシステム要件を定義しづらい場合や、市場変化が激しい場合などに柔軟に対応できる。 アジャイルは開発スタイルの実践を指すが、これを受託開発の契約形態に当てはめようという企業が登場して注目を集めている。中堅SIerの永和システムマネジメントは2010年11月11日、初期費用0円、月額利用料15万円からという、まったく新しい契約形態による受託開発のトライアルサービスを発表した。永和システムマネジメントに話を聞いた。 こう語るのは永和システムマネジメントサービスプロバイディング事業部の木下史彦氏だ。アジャイルといえば、開発の方
アジャイル導入のよくある間違い
原文(投稿日：2010/11/14)へのリンク たくさんの解説者がアジャイル導入のよくある誤りとアンチパターンについて書いてきた。彼らはさまざまな組織におけるアジャイル導入の誤りを避けるためにすべきこと「トップX」を投稿している。 Target ProcessのMichael Dubakov氏は、“10 Most Common Mistakes in Agile Adoption” (Part 1 & Part 2) という2つのブログ記事を書いた。彼は「企業はアジャイル導入において何度も同じ間違いをしている」と主張している。 彼が挙げたよくある誤りは以下の通りだ。 1. ツールから始める アジャイル開発はそうではない。ツールは即座に効果が現れるものではなく、ツールがあっても問題はほとんど解決しない。さらには、より重要な目標に目をつぶって、あなたはツールの導入に励んでしまう。 2. プロ
Agile in 30mins - 30分でだいたいわかるアジャイル開発
入門 Kubeflow ～Kubernetesで機械学習をはじめるために～ （NTT Tech Conference #4 講演資料）
マネージャにScrumを売り込むか？
あなたにとって重要なトピックや同僚の最新情報を入手しましょう最新の洞察とトレンドに関する最新情報を即座に受け取りましょう。 継続的な学習のために、無料のリソースに手軽にアクセスしましょうミニブック、トランスクリプト付き動画、およびトレーニング教材。 記事を保存して、いつでも読むことができます記事をブックマークして、準備ができたらいつでも読めます。
『JUnit の歴史とテスティングの未来(Kent Beckインタビュー)』を訳します。：An Agile Way：オルタナティブ・ブログ
"Software Engineering Radio" という PodCast の Kent Beck のインタビューがとても面白かったので、要点を日本語訳したい。 http://www.se-radio.net/2010/09/episode-167-the-history-of-junit-and-the-future-of-testing-with-kent-beck/ 1時間くらいのインタビューなので、一人で全部やるのは辛い。。。と思い、リレー形式でこれを訳するプロジェクトを @urimaro さんと（勝手に）立ち上げました！参加したい人は、ぼくか@urimaroさんがこの PodCast を訳したブログや日記に、参加意思表明のコメントをください。基本、先着でまわしたいと思います。 ではここから。正確に訳しているのではなくて、ポイントを日本語にしていきたいと思います。インタビュー
チケット管理システムをつかってみよう！：An Agile Way：オルタナティブ・ブログ
チケット管理システム、使っていますか？ 小川 明彦さん、阪井 誠さんによる、 「Redmineによるタスクマネジメント実践技法」 が出版されました。trac, Jira, redmine などなど、ちまたには多くの優秀なチケット管理システム(BTS, ITS)があります。もし、チケット管理システムをまだ導入していないプロジェクトがあったら、この機会に導入を検討してはいかがでしょう。Excelでタスク管理などをやっている場合ではありません！ 例えば「ソースコード管理システム」は、現代の必須インフラですね。SubversionやGitなどの版管理システムは、プロジェクトでもっとも大切な資産である「ソースコード」を全員で共有し、時間に沿って記録し変更を管理します。今はこれなしでは、ソフトウェア開発のプロジェクトは成り立たないでしょう。そして、現代のプロジェクトに必須なインフラをもう１つあげるとし
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
アジャイル開発とTDDを半年間実践してみた顛末と、これから
ドメインパーキング