マイクロソフトのAgileの事例 - プログラマの思索
マイクロソフトのAgileの事例の記事を見つけたのでメモ。 【元ネタ】 マイクロソフトにおけるアジャイル開発はこんな風に進められている － Publickey Visual Studio 2005では当初の予定24ヶ月を大きくオーバーして39ヶ月もかかったらしい。 そこで、Visual Studio 2008の開発プロセスを根本的に変えたとのこと。 Redmineによるチケット駆動開発の経験から類推すると、下記のように置き換えられると思う。 フィーチャー単位の開発は、ユーザストーリー単位の開発と同じ。 進捗はタスクの達成率ではなく達成したユーザーストーリーの規模で測定するのは、ストーリーポイントと似ている。 「「クオリティゲート」を通過したもの以外、アクティブなブランチに統合してはならない」とは、メインラインモデルによる構成管理。 Yellow/Red Gameは、チケットの取捨選択。 進
WindowsのキラーアプリExcel - プログラマの思索
チケット駆動開発におけるExcelの役割についてメモ。 ＃あくまでもメモ書き。 受託開発では顧客の業務のうちExcelで手運用している業務をIT化、Web化することで狙い撃ちにしているのに、自分たちのSW開発ではExcelが幅を利かせている。 つまり、SW開発の業務そのもののIT化は遅れているのが現状だろう。 なぜ、Excelによるプロジェクト管理は良くないのか？ その理由は下記で書いた。 Excelのプロジェクト管理は何故良くないのか: プログラマの思索 一言で言えば、ExcelのドキュメントはSVN・Mercurialなどでバージョン管理すべきか、RedmineのチケットやTestLinkのテストケースなどで代用できるか、使い分けることが肝心。 では、チケット駆動開発は何をもたらしているのか？ その理由は下記で書いた。 Excelのプロジェクト管理から脱却せよ～SW構成管理を見直そう:
ObserverパターンとMulticastパターン - プログラマの思索
JavaよりもC#が優れている点は、Deledateという機能があるおかげでイベント通知のロジックが書きやすい点にある。 Javaでは、Multicastというデザイパターンでカバーする必要がある。 平鍋さんの記事が分かりやすいのでメモ。 【元ネタ】 - デザインパターンによる進化的設計 Jude開発記 - Java プログラマのためのデザインパターン入門 [Effective C#] 項目21 デリゲートを使用してコールバックを実現する | まさくらのブログ デザインパターンにあるObserverパターンは、デスクトップアプリを作る時に非常に重要なパターン。 GUI上のイベントをキャッチして、次のイベントを発火するロジックに使うから。 しかし、- デザインパターンによる進化的設計に書いてあるように、Push型のObserverパターンでもPull型のObserverパターンであっても、情
Webプログラミングは何故オブジェクト指向でない？～WicketはWebプログラミングにオブジェクト指向を取り戻す - プログラマの思索
Webプログラミングは何故オブジェクト指向でない？～WicketはWebプログラミングにオブジェクト指向を取り戻す JavaでWebアプリを10年書いて思ったこと。 Webプログラミングは全然オブジェクト指向でない。 Sevlet＋JSP主体のプログラミングスタイルは、リクエストとレスポンスへPrimitiveな値をどうやって渡すか、という手続き型の発想でしか書いていない。 従来のWebプログラミングスタイルの問題点について書いてみる。 以下ラフなメモ書き。 【参考リンク】 Wicketって？ ウェブ開発をもう一歩前に Wicketで始めるオブジェクト指向ウェブ開発：第1回 Hello, Wicket｜gihyo.jp … 技術評論社 【コラム】イマドキのIDE事情 (39) Wicket、Grails、Click - IDEでみる軽量Javaフレームワーク | エンタープライズ | マイ
Agile2.0時代で必要な技法を示唆している資料 - プログラマの思索
小川 明彦, 阪井 誠 : チケット駆動開発 日本のソフトウェア開発の現場で生み出された「チケット駆動開発」という概念を、数多くの実例を元にモデル化・体系化を試みた最初の本。 小川 明彦, 阪井 誠 : Redmineによるタスクマネジメント実践技法 Redmineによるチケット駆動開発の実践技法に関する最初の本。アジャイルなソフトウェア開発への適用方法、TestLinkによるテスト管理手法についても言及。 清水 吉男: 「派生開発」を成功させるプロセス改善の技術と極意 組込システム開発をベースとして、ソフトウェア開発特有のスタイルである派生開発、特にXDDPについて解説した世界でも稀な本。既存製品を保守するのではなく継続的に機能追加していく昨今の開発では、派生開発特有の問題を意識しなければならない。XDDPはプロセス論だけでなく、要件定義などの上流工程の品質改善にも役立つので注意。 Le
Agile2.0は何を解決しようとしているのか？ - プログラマの思索
Agile2.0について再考してみる。 【元ネタ】 第二期アジャイルムーブメント ～ アジャイル開発の商業的取り組み と Agile2.0 ないし 「２週目の世界」 について - kawaguti の日記 (id:wayaguchi) XPが登場してアジャイル開発の利点は数多く知られてきた。 そして、多くの人達がアジャイル開発を現場で実践してきた。 しかし、アジャイル開発の弱点でよく言われるのは「アジャイル開発は大規模プロジェクトに適用しにくい。スケールアップが難しい」というもの。 実際、素のままのアジャイル開発では、サブチームが2個以上になると途端に難しくなるように思う。 又、その運用ノウハウも公開されていない。 そんな中、昨今は「2週目のアジャイル」「Agile2.0」と呼ばれる動きがあり、アジャイル開発が復権した流れが起きている。 僕の理解では2つの流れがある。 一つは、Scrumや
アジャイル開発と要件管理 - プログラマの思索
要求や要件管理に関する本「要求開発と要求管理―顧客の声を引き出すには」「成功する要求仕様 失敗する要求仕様」を読んで、アジャイル開発との関係についてメモ。 【1】IBMでは、「要求」と「要件」の言葉を意識的に使い分けていると聞いた。 「要求」とは、ユーザの生の要望。粒度が荒く、MECEでもない。 「要件」とは、SIが要求を咀嚼して、顧客が分かるレベルの要望にしたもの。 「要件」には3種類あると言う。 一つ目は、ユーザ企業の経営層の観点から見る事業要件。ビジネス要件とも言われる。 2つ目は、ユーザ企業の現場層の観点から見る業務要件。顧客の実際の業務フローのレベルに相当する。 3つ目は、システムの観点から見た機能要件。非機能要件は、性能や信頼性などに関わる要件として区別される。 我々技術者が見る要件は、システム要件に相当する。 しかし、顧客と話す場合、業務要件でなければ会話ができない。 更に、
Rails検証報告書 - プログラマの思索
日本OSS推進フォーラムという団体がRailsに関する調査結果を公開していたのでメモ。 【元ネタ】 日本OSS推進フォーラム 「RubyTF_Ruby_on_Rails検証報告書」 （PDF：975KB） おそらくIPOの外郭団体のような立場で、日本の大手SIの技術者がRailsを調査したらしい。 その報告書を読むと、Railsは企業向けにそこそこ使えるが、スケールアップやセキュリティ、技術蓄積にやや難がある、とのこと。 報告書で興味を引いたのは、セキュリティに関する所。 リダイレクト、Web アプリケーション内リンクをSSLにする対応は特に問題なく非常に簡単。 Railsで特徴的なのは、CookieでHTTP セッションを管理できることだろう。 ここの仕組みが非常に分かりやすい。 Railsでは、HTTPセッションをシリアライズ化してCookieに書き込む。 この時、サーバーにもハッシュ
ITの地殻変動はどこで起きているか？～Agile2.0をサポートするチケット駆動開発 - プログラマの思索
2010年を迎えるに当たり、ITの地殻変動がどこに起こっているのか？を考えてみる。 ＃自分の理解した範囲内のラフなメモ書き。 【過去の記事】 第二期アジャイルムーブメント: プログラマの思索 「塹壕よりScrumとXP」 チケット駆動開発はアジャイル開発の実装である: プログラマの思索 ITの地殻変動はどこで起きているのか？～2009年: プログラマの思索 ITの地殻変動はどこで起きているのか？～SeasarとRuby、そしてPF～2008年: プログラマの思索 ITの地殻変動はどこで起きているのか？～2006年: プログラマの思索 【Agile1.0の登場と課題】 2000年頃出現したXPによって、初めてアジャイル開発が開発者へ認知されたように思う。 XPは従来のウォーターフォール型開発のアンチテーゼとして、特に開発者に熱狂的に受け入れられた。 XPの最大の特徴は、繰り返し開発の実践プラ
チケット単位に並行開発する事例 - プログラマの思索
分散バージョン管理Git、Mercurialを絡めたチケット駆動開発で、興味深い事例があったのでメモ。 【事例1】 gitだからこそできるチケット駆動開発のやり方 - kunitの日記 今やっている方法は、作業するなら作業用のブランチを切れ！それにはチケット番号を付けろ！という方式にしている。 たとえば会員管理の機能に追加したい場合は以下のような手順になる。 1. 会員管理を拡張したいなぁ 2. じゃRedmineでチケットを切るぞ 3. チケット番号が振られた(たとえば #567 だとする) 4. さぁ、ブランチ切るか(members_567) 5. そのブランチで作業開始！ 濱野さんがWEB+DBでも入門Gitでもかかれている「トピックブランチ」というものの良さが本当に現れてくる。 【事例2】 Mercurialを使った俺々バージョン管理ノウハウまとめ(2009年夏編) - 文殊堂 t
【公開】第4.5回Shibuya.trac発表資料「RedmineとTracの機能比較～TiDDに必要な必須機能」 - プログラマの思索
第4.5回Shibuya.trac に参加して発表してきた。 スタッフの皆さん、ありがとうございました。 その発表資料「RedmineとTracの機能比較～TiDDに必要な必須機能」をCC Attribution ライセンスで公開します。 今回の発表は、昨年のKOFで発表したRedmine＋TiDDから続く一連のチケット駆動開発のまとめになります。 SQIP2009では、大手SIの経営者や管理職が多いせいか、チケット駆動開発の発表はプロセス改善というよりもツールに依存した運用改善と捉えられがちで、あまり反響がなかった。 でも、第4.5回Shibuya.tracはまるでホームのような雰囲気で、聴衆はTrac使用者がRedmine使用者よりもやや多かったけれど、チケット駆動開発に興味のある人達ばかりだったので、熱く語ることができた。 関西から八朔さんや小枝さんも来てくれて心強かった。 最後のパ
チケット駆動開発のベストプラクティスを収集したい - プログラマの思索
チケット駆動開発を実践して、色々考察してきて、ベストプラクティス集を作りたいと思っている。 理由は、チケット駆動開発とアジャイル開発の密接な関係を明確にして、アジャイル開発を簡単に運用できるノウハウとして公開したいからだ。 僕は、チケット駆動開発には下記4個のプラクティスが最低限必要だと思っている。 但し、XPのプラクティスと同じだがTiDDの言葉で言い換えているものもあるので注意。 １・チケット・ファースト(Ticket First) 【説明】 基本は、プロジェクトの作業はチケットを受け取ってから始める。 チケット無しで作業はしない。 また、SVNコミット時に、チケット無しのコミットも不可。 【効用】 チケットがタスクカード(作業指示書)のため、コミュニケーションロスがなくなるし、作業履歴がチケットのコメントとして残る。 進捗情報は全てチケットに書くから、BTSのチケット集計機能でリアル
SVNリポジトリの管理方法 - プログラマの思索
かおるんさんの記事のコメントで、誤った意見を書いてしまったので修正しておく。 【元ネタ】 Subversion のフォルダ構成 - かおるんダイアリー Subversionのフォルダ構成 | Ryuzee.com Subversionで簡単・確実にファイルを構成管理 － ＠IT自分戦略研究所 InfoQ: 複数のアジャイルチームでのバージョン管理 【問題】 SVN直下のディレクトリは、branch/tag/trunkになっている。 ソースやドキュメントはどこに配置すべきか？ 【結論】 管理したい一つのまとまり(プロジェクト)単位で、trunk/branch/tag を作った方がブランチを管理しやすいと思っていた。 最初はtrunkの中にソースやら仕様書を配置して、管理方法がよく分からなかった。 でも、さかばさんと議論してみて、ryuzeeさんのやり方が良いと思う。 思い出してみたら、下記の
XDDPと言う派生開発 - プログラマの思索
初めて、XDDPと言う派生開発の提唱者である清水さんの話を聞いた。 本は2冊読んでいたけれど、自分の理解が不十分だったことに気付いた。 以下、メモ書き。 【1】XDDPの最大の特徴は、SW開発の殆どは機能追加という保守開発である、という認識を前提としたアジャイルっぽい開発スタイルにある。 ソースからリバースエンジニアリングで要求仕様書を作り、ソースをダラダラと修正するのではなく、一気に修正してしまう。 駄目なプロジェクトでは、ソースに手を入れては修正漏れが出て、それを直してはまたバグが出る、といった症状が多い。 影響範囲や修正方法を確実に見極めれずに、ソースに手を入れてどんどん劣化させてしまう最悪なパターン。 清水さんのフレーズで面白いと思ったのは「移植作業は、ソフトウェアでも拒否反応を起こす」という内容。 人体でも、風邪を引いた場合、抗生剤を飲む。 しかし、抗生剤は人によっては免疫機能が
アジャイル開発は受託開発の方が向いている - プログラマの思索
ある人と話して気付いたこと。 アジャイル開発は受託開発の方が向いている。 組込系の製品開発やパッケージ製品開発では、マーケティングやビジネス上の要請から、既に要件が殆ど決められていることが多い。 だから、ウォーターフォール型開発で進めやすい。 受託開発では、おおまかな要件は決まっているが、あくまでも方針だけ。 顧客のためにカスタマイズしていく間に要件が絞られて、具現化していく。 ガチガチのウォーターフォール型開発で進めると、度重なる仕様変更を制御できずに、コストや納期がオーバーしやすい。 だから、小刻みにリリースしながら、顧客のフィードバックをイテレーション単位で取り込んで、システムをブラッシュアップしていく。 コストと納期は厳守しながらも、スコープ(要件)を変化させることで、顧客満足を稼ぐ。 でも、アジャイル開発だからといって、設計書は不要、とか、計画は不要、というわけではない。 要件の
【公開】ETWest2009講演資料「TestLinkでアジャイルにテストする」 - プログラマの思索
ETWest2009の講演資料「TestLinkでアジャイルにテストする」を公開します。 CC Attribution ライセンスとします。 上記の講演で、TestLinkを半年間運用してみて、経験したこと、理解できたこと、そして確信したことは全て書いた。 一番言いたい事は、TestLinkがアジャイル開発の弱点の一つである受入テストを補強してくれることだ。 テスト駆動開発や継続的インテグレーションのプラクティスで単体テストの品質は保証できるが、結合～受入テストの品質を確保するのは、ウォーターフォール型開発だけでなくアジャイル開発でも難しい。 その問題の本質は、二つある。 一つは、受入テストの自動化は難しいこと。 もう一つは、手動の受入テストの生産性が悪いこと。 TestLinkの導入によって、手動の受入テストを効率化できると確信している。 だが最終的な目標である受入テストの自動化は、Te
RedmineとTracの機能比較 - プログラマの思索
RedmineとTracの両方でチケット駆動開発を運用してみて、色んな気付きがあった。 以下メモ書き。 【比較対象】 ・Redmine0.8.0 ・Trac0.11.1.ja 【元ネタ】 脱Excel！ Redmineでアジャイル開発を楽々管理 － ＠IT自分戦略研究所 【1】複数プロジェクトの扱い RedmineがTracよりも機能が優れている点の一つは、複数プロジェクトに対応していること。 Tracはプロジェクトに親子関係を入れることができないため、特に大規模プロジェクトではチケット駆動開発を実践しにくいだろうと思う。 複数プロジェクトを作りたい状況は、二つある。 【1-1】開発チームが複数のサブチームに分かれていて、それぞれでタスク管理したい場合。 RedmineやTracを運用してみると、一つのプロジェクトでメンバーが5人以上だとチケットが乱発されたり、放置されやすくなるようだ。
Antリファクタリングカタログ - プログラマの思索
「ThoughtWorksアンソロジー ―アジャイルとオブジェクト指向によるソフトウェアイノベーション」本を読んで興味深くかつすぐに使えそうな箇所は「Antビルドファイルのリファクタリング」だった。 以下メモ書き。 【1】「ThoughtWorksアンソロジー ―アジャイルとオブジェクト指向によるソフトウェアイノベーション」の1章に「ビジネスソフトウェアの「ラストマイル」を解決する」という章がある。 長年、継続的に機能追加されて肥大化したシステムへいかにアジャイルにリリースできるか？という「ラストマイル」問題を提示している。 XPが提示したプラクティス「継続的インテグレーション」「テスト駆動開発」は、高速・高品質な開発を可能にした。 しかし、本番環境へのデプロイ＋リリースのプロセスではその恩恵がない、と。 理由は、3つある。 一つ目は本番環境は大変高価であり、二つ目は検証が複雑で、三つ目は
要件定義をロジカルシンキングで解析する - プログラマの思索
「30の「勝負場面」で使いこなす ロジカル・シンキングの道具箱」を読んで、高度情報処理試験の論文問題を解いているような気がしてきた。 要件定義と問題解決、ロジカルシンキングについて考えたことをメモ。 【1】業務系システム開発のリスクは、Railsのような最新技術の習得、TiDDのようなプロジェクト管理、TestLinkのようなテスト管理など色々あるが、一番のネックは要件定義だ。 元々の要件が顧客の認識とずれていたら話にならない。 しかしながら、新規顧客の場合、顧客と一緒に開発してリリースして運用しなければ、顧客の本来の要求が何だったのか、が分からない時はすごく多い。 だから、SIerのビジネスモデルとしては、1次開発は赤字だったとしても2次開発や運用保守で黒字になるように仕向けるのが普通だろう。 特に大手SIerが政府の公共システムを受注する場合が当てはまるだろう。 だが、そういうリスキー
開発プロセスを設計するという発想 - プログラマの思索
最近興味があること。 それは、「開発プロセスを自由自在に設計して、運営できるか？」ということ。 こんな本「SEの仕事を楽しくしよう」を読んでみて、色々と考えさせられる所があった。 RUP、XP、CMM/CMMI、ソフトウェアプロダクトラインなどを聞きかじって、自分で少しだけ試してみた経験を振り返ってみて、考察してみる。 【１】新規開発と派生開発～ＩＴ業界特有の開発プロセス 開発プロセスを勉強すると必ず「ウォーターフォール型開発よりもインクリメンタル型開発の方がいい」という文句に良く出る。 でも、実際の現場では、ウォーターフォール型開発でもインクリメンタル型開発でも、プロジェクトを制御できていない。 その原因は、2種類の開発プロセスがある事実を知らないことにあると思う。 最初からスクラッチ開発する時は、小さなサイクルでウォーターフォール型開発を行う時が多い。 最近なら、オブジェクト指向言語で
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
