オープンな開発プロセスとオープンな開発言語
アジャイル開発プロセスはオープン（な開発プロセス）であり、Rubyはオープンな開発言語であると平鍋氏が主張し、第4回の議論が始まる。ここでの「オープンさ」とは、改変可能、という意味だ。短い期間でフィードバックを反映させながら、動くモノを着実に構築していくという基本的な考えがアジャイル開発プロセスにはある。状況に応じて、開発チームの間で柔軟にプロセスの組み替えや改変がおこる。 一方Rubyも、クラスを改変可能であるし、DSLとしてドメイン語彙を作っていくこともできるというオープンさを持つ、と角谷氏も呼応する。また、まつもと氏は、DBスキーマ変更などをランタイムに許容するフレームワークや言語が、ビジネスとしても本質的に重要だという。このように“オープンな開発プロセス”に適する開発言語が、同じく“オープンでダイナミックな言語”Rubyであり、両者は、変更に対する柔軟性という意味でとてもよい相性を
はてなグループの終了日を2020年1月31日(金)に決定しました - はてなの告知
はてなグループの終了日を2020年1月31日(金)に決定しました 以下のエントリの通り、今年末を目処にはてなグループを終了予定である旨をお知らせしておりました。 2019年末を目処に、はてなグループの提供を終了する予定です - はてなグループ日記 このたび、正式に終了日を決定いたしましたので、以下の通りご確認ください。 終了日: 2020年1月31日(金) エクスポート希望申請期限:2020年1月31日(金) 終了日以降は、はてなグループの閲覧および投稿は行えません。日記のエクスポートが必要な方は以下の記事にしたがって手続きをしてください。 はてなグループに投稿された日記データのエクスポートについて - はてなグループ日記 ご利用のみなさまにはご迷惑をおかけいたしますが、どうぞよろしくお願いいたします。 2020-06-25 追記 はてなグループ日記のエクスポートデータは2020年2月28
【レポート】JavaWorld Day 2007 - アジャイル開発の伝道師が明かす、プロジェクト成功の秘訣 (1) アジャイル開発に対する9つの誤解 | エンタープライズ | マイコミジャーナル
米IBM Practice Leader Agile DevelopmentのScott W.Ambler氏 19日、東京都千代田区において、IDGジャパン主催の技術カンファレンス「JavaWorld Day 2007」が開催された。JavaWorld Dayは、昨年末まで定期刊行されていたJavaWorld誌の内容をライブで技術者へ伝えることを目的として始まった技術カンファレンス。同誌が休刊になった現在も、継続して開催されている。 7回目を迎えた今年のJavaWorld Dayでは、「The Agile Modeling(邦訳:アジャイルモデリング)」などの著書で知られるScott W.Ambler氏をはじめ、国内外の著名なエンジニアによる10のセッションが設けられた。ここでは、同カンファレンスの中からScott W.Ambler氏の基調講演を取り上げ、その模様をお伝えしよう。 アジャ
開発プロセスを設計するという発想 - プログラマの思索
最近興味があること。 それは、「開発プロセスを自由自在に設計して、運営できるか？」ということ。 こんな本「SEの仕事を楽しくしよう」を読んでみて、色々と考えさせられる所があった。 RUP、XP、CMM/CMMI、ソフトウェアプロダクトラインなどを聞きかじって、自分で少しだけ試してみた経験を振り返ってみて、考察してみる。 【１】新規開発と派生開発～ＩＴ業界特有の開発プロセス 開発プロセスを勉強すると必ず「ウォーターフォール型開発よりもインクリメンタル型開発の方がいい」という文句に良く出る。 でも、実際の現場では、ウォーターフォール型開発でもインクリメンタル型開発でも、プロジェクトを制御できていない。 その原因は、2種類の開発プロセスがある事実を知らないことにあると思う。 最初からスクラッチ開発する時は、小さなサイクルでウォーターフォール型開発を行う時が多い。 最近なら、オブジェクト指向言語で
Ruby Inside: The Ruby Blog
In math, a unary operation is an operation with a single input. In Ruby, a unary operator is an operator which only takes a single ‘argument’ in the form of a receiver. For example, the – on -5 or ! on !true. In contrast, a binary operator, such as in 2 + 3, deals with two arguments. Here, 2 and 3 (which become one receiver and one argument in a method call to +). Ruby only has a handful of unary
中国人の日本型開発アプローチに対する本音は？
中国人の日本型開発アプローチに対する本音は？：オフショア開発時代の「開発コーディネータ」（16）（2/3 ページ） 日本企業の仕様変更が嫌われる本当の理由とは 日本から変更要求が発生したとき、会社の存続と持続的成長にコミットする中国企業の経営層は、「正当な対価を支払ってもらえれば対応すべきだ」と考えるのが一般的です。プロジェクトマネージャも同様に、プロジェクトを完遂させるには、日本側の変更要求に対応するしかありません。余計な作業が増えるため、本音はやりたくないかもしれませんが、「やるしかない」のがプロジェクトマネージャ層なのです。 一方、日本側の変更要求に対応しても技術蓄積に結び付かないと考えてしまう技術者がいると、現場のモチベーションは一気に下がってしまいます。現場の技術者は、経営者やプロジェクトマネージャ層とはコミットする対象が異なるので、日本からの要求変更の対応に嫌悪感を隠しません。
［動画］Ruby設計者まつもとゆきひろといろいろ語りたい － ＠IT情報マネジメント
プログラム言語Rubyとアジャイルソフトウェア開発の連携が生み出す新たな可能性を縦横無尽に語り合う。全6回シリーズの第1回。まつもとゆきひろ（ネットワーク応用通信研究所）がRubyの来歴を語り、平鍋健児（チェンジビジョン）がアジャイル開発とRubyの接点を模索する。角谷信太郎（永和システムマネジメント）が両者の橋渡しをする。 なぜ、「まつもとゆきひろ」か？ 「RailsによるアジャイルWebアプリケーション開発」は一風変わった書籍である。RubyによるWebアプリケーションフレームワーク、Ruby on Rails解説の決定版である本書は、書名に「アジャイル」を冠しながらも、本文では具体的なアジャイルソフトウェア開発手法への言及がほとんどない。その理由は「アジリティ（agileであること）はRailsの構造の一部」であり「フレームワーク自体にアジャイル宣言の原則を語らせるように」執筆したと
残業のない開発現場、ビジネスとITのリスク共有：An Agile Way：オルタナティブ・ブログ
TRICHORDの開発は、完全にアジャイル開発です。タイムボックスを区切ったマネジメントスタイルで、基本的に残業はなしです。っていうか、一日３コマのペア・プログラミングをやったら、へとへとで残業できません。ということを言ったら、記事になっていました。 残業ゼロの開発現場 http://itpro.nikkeibp.co.jp/article/OPINION/20070523/271904/ なぜ残業をなくせるかというと、それは（当たり前のことなんですが）開発のビジネスオーナーが自社だからです。受託型の開発だと、それはなかなか難しいのだと思います。つまり、ミッションとリスクをビジネスとITの間で分割してしまうと、そこでWin-Win関係と良好なコミュニケーションを確立することが難しくなってしまいます。 市場を「調査」し、仕様をまとめ、それを「発注」する。そして、それを開発し、「納品」し、市場
第19回 TRICHORDの開発現場に見るふりかえりの進め方
前回は，「ふりかえり」の概要とその効果について解説した。具体的なふりかえりの内容やファシリテーションの仕方については，前回紹介した「プロジェクトファシリテーション 実践編 ふりかえりガイド」に解説がある。詳しくは，そちらを参照してほしい。今回は，実際にTRICHORDチームで毎週実施しているふりかえりを題材に，ふりかえりの進め方と工夫を紹介する。 TRICHORDチームは，1週間を1イテレーションとして，イテレーションの最終日の午前中（金曜）にふりかえりを実施している。毎週実施しているので，プロジェクトが始まってかれこれ数十回行っていることになる。2006年5月から，内部で行ってきたふりかえりの内容をブログで公開している。ほかのプロジェクトのふりかえりの結果を見る機会はなかなかないと思うので，参考にしてほしい。 TRICHORDチームのふりかえりは，KPTと呼ぶスタイルを用いている。これは
第6回 アジャイル開発でタイム・ボックスを決める---TRICHORDの開発現場から
前回までの平鍋からバトンタッチして，今回から懸田が本連載を担当する。筆者は平鍋が代表を務めるチェンジビジョンで，プロジェクトの見える化ツール「TRICHORD（トライコード）」の開発を担当している。以下では，TRICHORDの開発を例に，Web 2.0時代の軽量開発について具体的に考えていく。 TRICHORDは，先の4月3日に最初の公開版であるバージョン0.1をリリースした（図1[拡大表示]）。TRICHORDは本連載で提唱したコンセプト・アウト/デマンド・イン型の開発プロジェクトとなっている。まだ完成していない状態でプロダクトを世に送り，利用者にそのコンセプトを問うて，フィードバックをもらいながら，プロダクトを育てていこうとしている。 図1 TRICHORDの画面 2006年4月に最初の公開版であるバージョン0.1をリリースした。現時点ではごく基本的な機能しか実装していない。 [画像の
残業ゼロの開発現場
明日（5月26日）発行の日経SYSTEMSに「アジャイルは現場をハッピーにしたか」という記事を掲載しています。「ワクワクするような座談会ができた」。記事を校了した後に，そんなふうに感じました。 アジャイル・ブームの火付け役となった「XPエクストリーム・プログラミング入門」が日本語に翻訳されて出版されたのが2000年12月。それから6年半経ってブームは去りましたが，アジャイル開発を採用する現場は少しずつ増えています。当時目指していた現場は生まれているのか。そういう問題意識で企画したのが，この座談会でした。 アジャイル開発は現場から生まれた開発方法論です。開発担当者のコミュニケーションやモチベーションを重視しています。開発方法論とは言っても，工程ごとのプロセスや成果物が明確に定義されているわけでありません。具体的な開発手順やマネジメント方法は自分たちで作ることが必要で，さらに一度作った手順や方
I Have a Dream - elm200 の日記(旧はてなダイアリー)
かつて Martin Luther King, Jr はそう言った。でも自分の夢を公にするのは、なんだか恥ずかしい。きっとその夢に対してツッコミを入れられることを恐れるからだろう。 私には夢がある。最近、それが何なのかおぼろげにわかってきた。私は、生産性の高いソフトウェア開発のチームを作りたい。XP で代表されるようなアジャイル開発の考え方はそれに近い。 私は、大学では経済を学んだが、紆余曲折の後、プログラマになることになった。1996年のことだ。3年後、日本のソフトウェア業界に絶望して、カナダに渡る。しかし、外国でも自分の理想の職場は見つけられず、3年前に日本に舞い戻った。 自分に理想があるなら、それを探し出すのではなく、作り出すべきなんだ。 日本人は、世界的に見ても、非常に教育水準が高く優秀な労働者が多いと思う。これは、いろんな国を見てきた実感である。日本にも優秀なハッカーたちは大勢い
アジャイルのレイヤ 〜 アジャイルを整理し直して理解する - kuranukiの日記
【アジャイル】という言葉は、システム開発の世界ではかなり一般的な言葉になりつつあります。大手のSIerの経営者までが当たり前のように使うようになったことは、ある意味で感慨深いものです。しかし、言葉としてメジャーになりつつある一方で、その言葉の本当の実体を理解しないで誤解したまま使っているケースが多くあるように思います。アジャイルで開発すれば「速い・安い・旨い」が手に入るという誤解や、プログラミング工程だけで使う手法だという誤解、朝会やふりかえりをすることがアジャイルだという誤解、などなど。どれも、完全な誤解という訳ではなく、あながち間違いでもないところが、さらなる混乱を産んでいるように感じます。 最近では、アジャイルの事例も多く出てきたように思いますが、それらの事例も具体的にどういったことを実践したからアジャイルだったかと問われるとそこに明確な答えは無いように思えます。アジャイルとは何か、
実践「From Java To Ruby」 - いたわさににほんしゅ
角谷信太郎さんによるプレゼン 自社で進めている、Ruby を推進する活動の紹介を含めつつ、 Ruby への熱い思いがメインだったのか? 論理というより、「感覚」だったと思うので、僕が心に残ったキーワードを羅列 XP と Ruby の2本指で月を指さす Ruby はプログラマを信頼する言語 チームを信頼し、チームから信頼される Open Classes, Open Campanies の話は、元ネタを読んで噛み砕いてみたい 角谷さんとしては、「だから、Ruby とビジネスは相性抜群」 去年に引き続き、熱いお話で、聞いているだけでもこちらにやる気が湧いてくる、濃い45分間でした。 会社という組織への Ruby 導入は、同じような立場で聞かせてもらい、共感しました。それをネタに、休憩時間に話をさせていただきましたが、一歩ではなく、数歩も先を行かれているので、そのうちもっとゆっくり話をさせてくださ
■ - ( ・ω・)ノ＜しすてむ開発。
こちらで見かけたことより。 ソフトウエアに役立つ「日本型ハードウエア生産法」 元記事のこれを読んで思った。 (,,ﾟДﾟ)＜知らない分野を自分なりに理解しようと努めた内容だなこりゃ。 1個人の学習過程が、即ち「現実」ではありえないもの。 ゆえに、さも現実を示唆しているように語らないで欲しいな〜っと感想を持った。 そんなことよりも。 気になった単語が一つ。「要求工学」。 なんじゃこりゃと思い、調べてみたらすぐ出てきた。 第1回 要求工学の概要 要求工学の必要性 多要求工学（ Requirements Engineering）は新しい技術ではなく1970年代から議論されている。 ソフトウェア危機が1960年代に認識されたときに、ソフトウェア開発プロジェクトが失敗する主要な原因が要求の欠陥にあると報告されている ま、これも昔からあることかっと思った最後の部分。 まとめ 本稿では、要求工学の必要性
アジャイルソフトウェア開発 - Wikipedia
ソフトウェア工学におけるアジャイルソフトウェア開発 (アジャイルソフトウェアかいはつ、英: agile software development) は、人間・迅速さ・顧客・適応性に価値を置くソフトウェア開発である[1]。典型的なアジャイルソフトウェア開発では、チーム主導で設計・実装・デプロイを短期間に繰り返してユーザーが得た価値を学習し適応する、すなわちトライアルアンドエラーで開発が行われる。アジャイルソフトウェア開発を可能にする開発手法にはエクストリーム・プログラミングやスクラムなどがある。 ペアプログラミング アジャイルソフトウェア開発は人間・迅速さ・顧客・適応性に価値をおくソフトウェア開発である（アジャイルソフトウェア開発宣言）。すなわち自己組織的なチームが対話の中で方向性・仮説を見出し、顧客へ価値を素早く届け、実践投入の学びから素早く改善をおこなう在り方に価値を置く。 この価値観を
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
