英国政府、新ポータルGov.ukをクラウド、アジャイル、Rubyで開発。ソースはGithubで公開
クラウド上でRubyを使って開発し、成果物はオープンソースとして公開。開発プロセスにはアジャイル開発を採用し、毎日スタンドアップミーティングを実施。まるでベンチャー企業が新サービスを開発するようなスタイルを採用しているのが、英国政府のポータル「Gov.uk」の開発チーム。 Welcome to GOV.UK Beta (Test) - simpler, clearer, faster access to UK government services and information Gov.ukは、英国政府の情報とサービスを利用するためのポータルサイトとして開発が進んでおり、現在β版が公開されています。 グーグルのプロジェクトのようにGov.ukは作られている Gov.ukがどのように開発されているのか、ブログGovernment Digital Serviceにポストされたエントリ「Int
アジャイルにTDDしようとしてペアプロして失敗した話 - 水まんじゅう2
これはTDD Advent Calendarの18日目。 記事としては @mao_instantlife さんの TDDやってみてコメントが減った話 のあと、@cubeon さんの きっと方眼の理から逃れられないお前たちにも告げる！テストコードを手に入れるのだ！ の前となります。 最近、新しい開発手法の一貫としてTDDを採用しようとするプロジェクトが出始めている印象があります。 ただし、とりあえず取り入れてみたけれどもうまくいかなくて結局ウォーターフォール方式に逆戻りという例も多いのではないでしょうか。 以前、アジャイルにTDDをしようとしてペアプロして失敗したプロジェクトの話を聞いたことがあるので書こうと思います。 その時のプロジェクトでは数百人月前後の工数をかけてそれまであったレガシーシステムをJavaでリプレイスしようとしていたようです。 それなりの規模のプロジェクトに多いように、さ
OGIS Scalable Agile Method の真髄（後編） | オブジェクトの広場
既存の見積もり方法を用いた場合の見積もり精度 一括（請負）契約が可能か 開発依頼者の関与がどれくらい必要か 以降、推敲フェーズ終了時点での要求の不確定性の大きさで場合分けして議論します。 まず、不確定性が小さくなる場合（大→小、中→小）では、不確定性が小さくなる作成フェーズ以降は従来の見積もり方法で費用を見積もり、開発スコープと費用を定めた一括（請負）契約が可能になり、開発依頼者の負荷も減ります。 不確定性が中ぐらいの場合（大→中、中→中）では、不確定性が中ぐらいで残るため従来の見積もり方法で精度よく費用を見積もることが困難であり、契約上の選択肢は準委任契約になります。また、不確定性を解決するために開発依頼者の継続的な関与が必要になります。 不確定性が大きいままの場合（大→大）については、開発スコープが定まらないために、開発スコープと費用を定めた一括（請負）契約を結べないことになります。そ
OGIS Scalable Agile Method の真髄（前編） | オブジェクトの広場
［技術講座］ OGIS Scalable Agile Method の真髄 前編：日本でアジャイル開発の普及を阻む 7 つの不安と OGIS Scalable Agile Method （株）オージス総研 技術部アジャイル開発センター 藤井 拓 アジャイル開発手法スクラムだけでは実現できないことや日本でアジャイル開発の普及を阻んでいる 7 つの不安を解消するためのフレームワークが OGIS Scalable Agile Method (以降 OSAM と略す)です。今月と来月の 2 回に渡り、OSAM の概要を紹介します。今月号では、アジャイル開発手法スクラムを補うために OSAM が用いているアジャイルUPを中心に OSAM の開発手法としての側面を説明します。なお、本記事に挿入したいくつかの漫画は同僚の正木氏が作成したものです。 本記事の背景 本記事は元々 3 部構成の白書として執筆さ
”アジャイル開発先進国”ブラジルからのレポート｜オブジェクトの広場
［レポート］ ”アジャイル開発先進国”ブラジルからのレポート 株式会社オージス総研 グローバルビジネス推進部 細谷竜一 オージス総研グローバルビジネス推進部の細谷です。 Agile Brazil 2011に参加するため、ブラジルへ行ってきました。 個人的な話になりますが、ブラジルへ行くのはこれが二度目です。 一度目は 1983 年、小学生のころ、親の出張について行ったのです。 その時の強烈な印象は、とにかく英語が一切通じない国だということでした。 「ウォーター」といってもだめで、「アグア」と言わないといけません。 「オレンジジュース」もだめで、「スーコ・ジ・ラランジャ」と言います。 すべてがそんな具合で、当時現地の案内人を務めてくださった日系人の通訳のかたがどれだけ頼もしく思えたことか・・・。 そういう印象があったため、今回は事前に数の数え方から、簡単なフレーズは有る程度ブラジル・ポルトガ
プログラミングファースト開発の必要性 - ひがやすを技術ブログ
ここではフローチャートの是非を論じるつもりはない。クソだから。もっと一般化してしまえば、○○設計書みたいに「設計書」と名のつくものは全部クソだ。だって動かないんだもん。 動かない以上、それら設計書が正しいのか、漏れがないのかは保証のしようがない。机上検証なんていう工程もあるらしいけど、君たちの脳味噌は何MIPSなんだと問い詰めたい。もちろん、机上検証で見つかる凡ミスもあるだろうけど、そんなのはズボンもパンツも履かずに会社に向かうのと同じくらいのレベルの間違いだろう。 結局はコードを仕上げてから動かして初めて「だめだこりゃ」ということになる。 ○○設計書は、動かないから検証ができない。だから、だめだというのは、半分あっていて半分間違っていると思う。システム開発の大多数は、最初に○○設計書を作成する。顧客にレビューしてもらったり、自分たちでも内部レビューしたりするが、あれは、有効性が低い。 動
Martin Fowler's Bliki in Japanese - アジャイル対リーン
http://martinfowler.com/bliki/AgileVersusLean.html 2008/6/26 アジャイル対リーン 「アジャイルソフトウェア開発をしようと思っています。 ですが、アジャイルの代わりにリーンソフトウェア開発をしたほうがいいんでしょうか？」 最近、こういう質問を何回か受けた。安易に答えるわけにはいかない―― そもそも、アジャイルとリーンの関係について誤解があるのだ。 そこで、まず歴史をひもといて、その関係について説明しよう。 「リーン」は、もともとは工業生産の世界で1950年代にトヨタが開発した手法を指す。 当時日本は第二次世界大戦の打撃から立ち直りつつあった。 リーン手法は、トヨタ生産方式と呼ばれることも多いが、 主に大野耐一の功績とされている。 もっとも、大野は西洋の多くの思想の影響を受けている。 特にデミングの影響が強い。 トヨタ生産方式が日本以
アジャイルはウォーターフォールよりも難しい
ここにきて、アジャイル開発手法を業務システム（アプリケーション）の開発に適用しようとする動きが本格化している。これまで小規模、Webシステムへの適用が目立ったが、最近は業務システムや大規模プロジェクトへの適用事例も出てきた。アジャイルはもはや“ブーム”ではなく、本格的な普及が始まったと見てよさそうだ。 ところが、実際にアジャイルを採用した現場に話を聞くと、何とことごとく失敗している。そもそもアジャイルは、大規模プロジェクトを想定していないし、請負契約が多い国内のプロジェクトは、要求の増加に歯止めが利きにくいアジャイルと相性が悪い。さらに業務システムへの適用となると、コストや納期の制約があり、品質優先で開発を繰り返しながらシステムを成長させていくアジャイルと考え方が相反する面がある。 それでも開発現場はアジャイルに望みをかけている。刻々と変わる要求やリスクに迅速に対応する必要があるからだ。最
組織に継続的インテグレーションを導入していく7つの段階
みなさんこんにちは。@ryuzeeです。 継続的インテグレーションの導入に関する分かりやすい記事があったので抜粋・意訳にてご紹介します。 原文はJohn Ferguson Smart氏のブログ記事「The Seven Phases of Introducing Continuous Integration into Your Organization」です。 継続的インテグレーションは全部かゼロかといった類のものではない。事実、CIの組織への導入はいくつかの明確な段階を経て進んでいくのだ。それぞれの段階は技術的な構造もそうだが、それ以上に重要であるであろう開発チーム自体のプラクティスや文化のインクリメンタルな改善を含んでいる。 以下の章では各段階についておおよその全体像を示すことにしよう。 第1段階 ビルドサーバがない初期の段階ではチームはなんらの中央ビルドサーバも持ちあわせていない。ソフ
- 継続的インテグレーション
継続的インテグレーション 原題: Continuous Integration Martin Fowler Chief Scientist, ThoughtWorks Matthew Foemmel ThoughtWorks 「確実なビルドを行う」 -- これはどんなソフトウェア開発プロセスであれ重要なことだ。そのわりには、このことがきちんとされていないことに驚かされる。本論文では、Matt が ThoughtWorks 社でのある大規模プロジェクトにおいて採用したプロセスを紹介する。このプロセスは全社的な広がりを見せつつある。テスト部分も含めて「全てが自動化された」「再現可能な」ビルドを、「日に何度も」行うことに力点がおかれている。このプロセスを用いれば、開発者はインテグレーションを毎日行うことになるので、インテグレーションに伴う問題を減らすことができる。 継続的インテグレーションの恩恵
Agile Conference tokyo 2011 参加レポート｜オブジェクトの広場
Agile Conference tokyo 2011 参加レポート 株式会社オージス総研 アドバンストモデリングソリューション部 浅井 良 Agile Conference tokyo 2011概要 7月20日に江東区文化センターホールにて行われたAgile Conference tokyo 2011に参加してきました。 Agile Conference tokyo 2011 - イベントTOP 株式会社テクノロジックアートにより主催・運営されるAgile Conference tokyoは今回で3年目を迎えます。「回を重ねるごとに来場者数も伸びており、アジャイル開発がいよいよ日本国内で本格的に広がっていくのではないかという期待を抱かざるをえません。」と書かれているように、400名の定員に対して参加希望者が殺到して抽選制になるほどの人気で、特に、午前中のマーティンファウラー氏の基調講演
「本番環境への適用まで自動化して繰り返す」、Martin Fowler氏がアジャイルのテクニックを語る
「本番環境への適用まで自動化して繰り返す」、Martin Fowler氏がアジャイルのテクニックを語る 「本番環境への適用までを自動化する『Deployment Pipeline』のテクニックが重要だ」──。オブジェクト指向開発やアジャイル開発の専門家で、2001年に発表された「アジャイルソフトウエア開発宣言（Manifesto for Agile Software Development）」の起草にも参加した米ThoughtWorksのMartin Fowler氏（Chief Scientist）が7月20日に東京・江東区で開催された「Agile Conference tokyo 2011」の基調講演に登壇（写真）。「Software Design in the 21st Century：21世紀のソフトウェアデザイン」と題して、アジャイル開発で効果的な手法について語った。 Fowler
Agile Conference Tokyo 2011 行ってきました - ShiroKappa Blog
アジャイル・カンファレンス・トーキョーに行って来ました。台風の影響が懸念されましたが、行き帰り共傘をさすほどの天候ではありませんでした。内容については下記に良くまとめていただいておりますので、相変わらず感想を綴ります。 Agile Conference Tokyo 2011 ・・・ 公式サイト Agile Conference Tokyo 2011 まとめ（Ver.3000） ・・・ [twitter:@take3000]さんのTogetter Agile Conference Tokyo 2011 マーティン・ファウラー氏の基調講演 #agiletokyo ・・・ [twitter:@mike_neck]さんのTogetter Agile Conference Tokyo 2011 午後 Jez Humble氏の講演 #agiletokyo ・・・ [twitter:@mike_neck
マーチン・ファウラー氏が語る、21世紀のソフトウェアデザインとしてのアジャイル開発（前編）。Agile Conference tokyo 2011 － Publickey
アジャイル開発に関する論客の一人マーチン・ファウラー氏は、7月20日にテクノロジックアートが主催したイベント「Agile Conference tokyo 2011」で「21世紀のソフトウェアデザイン」をテーマに基調講演を行いました。 ファウラー氏の基調講演の様子を紹介しましょう。 アジャイル開発の意味が希薄化している ThoughtWorksのマーチン・ファウラー氏。 アジャイルソフトウェア開発宣言から10年がたち、そのあいだいろんな人が伝えていくうちに当初の意味の希薄化（Semantic Diffusion）が起きてしまったと思う。私の役割は、最初の意味を思い出してもらうことだ。 要件の安定性に依存するのは不健全だ まずは「予想的な計画（Predictive Plannning）」と「適応的な計画（Adaptive Plannning）」について。 土木や建築に由来するのが「計画駆動開
Agile Conference tokyo 2011に参加してきた #agiletokyo - Diary of absj31
Agile Conference tokyo 2011 - イベントTOP 直前の台風6号が本土上陸、関東直撃か？と言った不安はありましたが、幸い台風は進路を反らし、関東にも上陸する事無く不安は取り除かれ、無事開催会場にも着く事が出来ました。 開催会場は周りを住宅街に囲まれたとても庶民的な(？)風景の中にある江東区文化センター。 Togetterまとめ Togetter - 「Agile Conference Tokyo 2011 まとめ（Ver.3000）」 Togetter - 「Agile Conference Tokyo 2011 マーティン・ファウラー氏の基調講演 #agiletokyo」 Togetter - 「Agile Conference Tokyo 2011 午後 Jez Humble氏の講演 #agiletokyo」 その他参戦レポート Agile Conferenc
Fearless Change 第一章の非公式翻訳 - kawaguti’s diary
Agile Japan 2011 の基調講演のため、Linda Rising さんが来日予定です。基調講演は日本中のサテライト会場にも中継される予定です。 Linda さんは、企業組織の柔軟な変化について、コンサルティングやコーチングを行っています。その方法は、パターンランゲージを用いて、誰にでも実行可能な方法を記述していく、というアプローチです。コンピュータサイエンスのバックグラウンドを持ち、通信系の大企業で勤務した経歴をもっているせいか、その一人称の語り口、安易に切り捨てない包容力に驚かされます。 InfoQでのインタビュー (2008年) http://www.infoq.com/interviews/Linda-Rising-Fearless-Change "Fearless Change" という本は、彼女と、ビジネスマネジメント系のバックグラウンドを持つMary Lynn Ma
Agile Conference tokyo 2011 - イベントTOP
昨年開催した「Agile Conference tokyo 2010」では、多くの方々にご来場いただき、大盛況のうちに終えることができました。 一昨年から始まったこのイベントも今年で3年目を迎え、回を重ねるごとに来場者数も伸びており、アジャイル開発がいよいよ日本国内で本格的に広がっていくのではないかという期待を抱かざるをえません。 第3回目となる今年の「Agile Conference tokyo 2011」では、海外からメインスピーカーを招き、アジャイル開発に関する講演をしていただきます。 今年一番の見どころは、なんといっても久々の来日となるマーチン・ファウラー氏の基調講演です。No.1アジャイル開発企業として名高い ThoughtWorks社に10年以上在籍し、大規模ソフトウェア開発のコンサルタントとして常に業界の最先端を突き進むマーチン氏の最新動向は要チェックです。 また午後の特別講
開発者にやさしい環境
ikeike443と申します。このブログの言いだしっぺです。 シャノンに転職してきてちょうど1年になります。前職は業務パッケージソフトの会社に所属していました。 転職してきた経緯などについては、下記のインタビュー記事で話したので、よかったら読んでください。 SaaSの可能性を信じて、新たな道を踏み出したエンジニアの「視点」 で、今回はとりあえず、シャノンに入社してこれは”いいね”と思ったポイントをつらつらと挙げてみます！ アジャイル開発やってるよ 開発方法論としてはアジャイル開発手法の一つ、Scrumを採用しています。 約一ヶ月をひとつのスプリントとみなして、毎月頭にスプリントの計画と見積りをして開発／テストに入ります。 毎朝のミーティングでバーンダウンチャートを確認し、文字通りみんなでスクラムを組んで開発しています。 バーンダウンチャートの作成、プロダクトバックログの管理には、ヌーラボさ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
アジャイルリーダーシップと組織改革 ～楽天のアジャイル開発というリアル～
はてなブログ | 無料ブログを作成しよう