タグ

ブックマーク / forza.cocolog-nifty.com (32)

  • ITの地殻変動はどこで起きているのか?~アジャイルへの流れと設計技法の違和感 - プログラマの思索

    第50回SEA関西プロセス分科会の放談会で話しながら、2012年末時点で、ITの地殻変動がどこに起こっているのか?を考えてみた。 #ラフなメモ書き。 【1】日のSIもアジャイル開発を最近は積極的に取り入れようとする流れがある。 2000年代前半、XPをコミュニティ中心で実践したものの、日IT業界のメインストリームにならなかった頃に比べると隔世の感がある。 ニュース - NTTデータと楽天が共同でアジャイル教育コース作成、両社で180人育成へ:ITpro その理由は、欧米を中心にScrumを中心としたアジャイル開発が主流になったため、日でも従来のウォーターフォール型開発にこだわらず、最新の開発プロセスを取り入れようとしたいからだろう。 だから、アジャイル開発が日のソフトウェア開発の現場に合っているかどうかは、過去の経緯からして、まだ未知数の段階だろうと思う。 でも、リーマン・ショッ

    ITの地殻変動はどこで起きているのか?~アジャイルへの流れと設計技法の違和感 - プログラマの思索
    katzchang
    katzchang 2012/12/03
    んー。
  • チケットファーストからビルドファースト、Gitoriousへ - プログラマの思索

    Gitoriousやゼロ機能リリース(Zero Feature Release)に関するラフなメモ書き。 【元ネタ1】 Gitを使った開発・運用フローの紹介 | FIRN.JP Gitという優れた分散バージョン管理をソフトウェア開発の中心の配置して、チケットやビルド管理ツールを連携する方法が書かれている。 GitoriousとRedmineを使った開発 - ひかえめプロジェクト (引用開始) ポイントは,フィーチャーブランチ,リリースブランチ,ホットフィックスブランチをそれぞれRedmineのチケットに対応付ける点です. これらのブランチの名前をすべて id/xx (xxはチケットナンバー)にすることで,自動的にブランチ上のコミットがRedmineのチケットに対応付けられます. (引用終了) ブランチRedmineプロジェクトだけでなく、チケット単位に作ってもいい。 分散バージョン管理を

    チケットファーストからビルドファースト、Gitoriousへ - プログラマの思索
    katzchang
    katzchang 2011/05/25
    「ゼロ機能リリース」
  • アジャイル開発の始め方 - プログラマの思索

    小川 明彦, 阪井 誠 : チケット駆動開発 日のソフトウェア開発の現場で生み出された「チケット駆動開発」という概念を、数多くの実例を元にモデル化・体系化を試みた最初の。 小川 明彦, 阪井 誠 : Redmineによるタスクマネジメント実践技法 Redmineによるチケット駆動開発の実践技法に関する最初のアジャイルなソフトウェア開発への適用方法、TestLinkによるテスト管理手法についても言及。 清水 吉男: 「派生開発」を成功させるプロセス改善の技術と極意 組込システム開発をベースとして、ソフトウェア開発特有のスタイルである派生開発、特にXDDPについて解説した世界でも稀な。既存製品を保守するのではなく継続的に機能追加していく昨今の開発では、派生開発特有の問題を意識しなければならない。XDDPはプロセス論だけでなく、要件定義などの上流工程の品質改善にも役立つので注意。 Le

    アジャイル開発の始め方 - プログラマの思索
    katzchang
    katzchang 2011/03/30
  • 基幹系バッチ処理をHadoopで高速化 - プログラマの思索

    基幹系バッチ処理をHadoopで高速化する記事を見つけたのでメモ。 以下ラフなメモ書き。 間違っていたら後で直す。 【元ネタ】 プレスリリース|2011年2月9日 |ウルシステムズ、業界初、基幹バッチ用のHadoopフレームワーク「Asakusa」 を開発、オープンソース化して提供開始 | ウルシステムズ株式会社 | UL Systems, Inc. ウルシステムズ、基幹バッチ用HadoopフレームワークをOSS化 - ニュース:ITpro 基幹バッチが超高速化する?|HATのブログ 業務システムは、日中のフロントエンドのリアルタイム処理と夜間の大量データを集計するバッチ処理の2パターンを組み合わせたアーキテクチャが多い。 フロント側はVisualBasic→CGI→JavaRailsHTML5と次々に技術革新が起きているのに、バッチ側は昔のCobolで作った資産が残っていて、そこから

    基幹系バッチ処理をHadoopで高速化 - プログラマの思索
    katzchang
    katzchang 2011/02/11
  • データベース設計で派生関係は難しい - プログラマの思索

    @t_wadaさんが、データベース設計の素晴らしい資料をリンクしていたのでメモ。 下記の資料は、MySQLでソーシャルゲームDB設計のお話らしいが、データモデリングの設計ノウハウが秀逸。 気になった点をメモしておく。 理解できたことをラフなメモ書き。 【元ネタ】 Twitter / Takuto Wada: 素晴らしい資料。"「スキーマ」「トランザクション」「インデックス」はもっと評価されるべき" / ソーシャルゲームのためのデータベース設計 http://htn.to/PzrnbR 【1】可用性や整合性に関する要求が意外と多い たとえ、SNSゲームであろうが、課金体系になるとお金が絡むため、ユーザの要求のレベルも上がるし、事業者の責任も大きくなる。 データモデリングはアーキテクチャ設計につながる。 【2】派生関係 データベース設計(DOA)でも、派生関係(継承関係)はオブジェクト指向

    データベース設計で派生関係は難しい - プログラマの思索
    katzchang
    katzchang 2011/01/18
    派生関係は悩んだ記憶がある。現場で最もよく見るのは、スーパータイプに「取引先用column」や「得意先用column」などを全部入れてしまうパターン。
  • メールでRedmineチケットを登録する機能の可能性 - プログラマの思索

    メールでRedmineチケットを登録する機能の可能性について考えたことをメモ。 【2016/3/5 更新】 @netazoneさんのおかげで、現在も動作するThunderbirdのアドオンを見つけられました。 Redmine連携 :: Add-ons for Thunderbird ThunderbirdとOutlookRedmineアドオン: プログラマの思索 【元ネタ】 Thunderbirdで受信したメールをRedmineのチケットとして登録できる「Quick Ticket to Redmine」 | Redmine.JP Blog メールによるチケットの登録 | Redmine.JP Email-ext plugin - hudson - Hudson Wiki RedmineとHudsonやTestLinkを連携させるプラグイン: プログラマの思索 Hinemos+Redmin

    メールでRedmineチケットを登録する機能の可能性 - プログラマの思索
    katzchang
    katzchang 2010/11/17
    インシデントのメール通知からチケットを登録すりゃいいんじゃないのという話。
  • 韓国SIがIT技術を日本に逆輸出 - プログラマの思索

    小川 明彦, 阪井 誠 : チケット駆動開発 日のソフトウェア開発の現場で生み出された「チケット駆動開発」という概念を、数多くの実例を元にモデル化・体系化を試みた最初の。 小川 明彦, 阪井 誠 : Redmineによるタスクマネジメント実践技法 Redmineによるチケット駆動開発の実践技法に関する最初のアジャイルなソフトウェア開発への適用方法、TestLinkによるテスト管理手法についても言及。 清水 吉男: 「派生開発」を成功させるプロセス改善の技術と極意 組込システム開発をベースとして、ソフトウェア開発特有のスタイルである派生開発、特にXDDPについて解説した世界でも稀な。既存製品を保守するのではなく継続的に機能追加していく昨今の開発では、派生開発特有の問題を意識しなければならない。XDDPはプロセス論だけでなく、要件定義などの上流工程の品質改善にも役立つので注意。 Le

    韓国SIがIT技術を日本に逆輸出 - プログラマの思索
    katzchang
    katzchang 2010/10/12
    九州のどこかの自治体システムを韓国系が構築、という話が何年か前にあったような。どんな感じだったんだろか。
  • 現代のAgile開発が抱える課題 - プログラマの思索

    チケット駆動開発でAgile開発を初めて実践できて、Agile開発の長所や短所が色々分かってきた気がする。 今の時代にAgile開発はとても優れていると思っているが、乗り越えるべき課題はまだまだある。 その課題も、時代の変化によって、より難しいレベルまで要求されているように思う。 2000年代に現れたXPを代表とするAgile開発は、その利点は広く知られてきたが、適用の限界や短所について従来から指摘され続けてきている。 その課題についてまとめてみる。 #考えたことをラフなメモ書き。書きかけもある。 【1】Agile開発はプロジェクト管理が弱い アジャイル開発でプロジェクト管理、そしてプロセスを管理する部分が弱いという指摘は従来から言われていた。 確かに、PMBOK、CMMIなどの観点から見れば、Agile開発はプログラミング重視で全体的なプロセス設計がなされていないように思える。 だが、S

    現代のAgile開発が抱える課題 - プログラマの思索
    katzchang
    katzchang 2010/08/08
  • ソフトウェアプロダクトラインと構成管理、ソフトウェアパターンの関係 - プログラマの思索

    ソフトウェアプロダクトライン(SPL)を分かりやすく解説された記事があった。 考えたことをメモ。 【元ネタ】 ZACKY's Software Engineering Laboratory: プロダクトラインとは(1) ZACKY's Software Engineering Laboratory: 共通性と可変性,スコーピング ZACKY's Software Engineering Laboratory: 製品指向とフィーチャー指向の可変性実現(1) ZACKY's Software Engineering Laboratory: 製品指向とフィーチャー指向の可変性実現(2) ZACKY's Software Engineering Laboratory: 製品指向とフィーチャー指向の可変性実現(3) 研究室|株式会社エクスモーション 組込みシステム開発を現場から支援する「実践型トータ

    ソフトウェアプロダクトラインと構成管理、ソフトウェアパターンの関係 - プログラマの思索
    katzchang
    katzchang 2010/03/19
  • チケット駆動開発のスケールアップ - プログラマの思索

    Redmineを大規模プロジェクトで使っている例を見たのでメモ。 【元ネタ】 複数プロジェクトとワークフローの設定について - Redmine Users (japanese) | Google グループ 上記のメールでは、下記の規模まで使っているらしい。 例1: プロジェクト:12 ロール   : 8 ステータス :25 トラッカー :12 例2: プロジェクト:200~400ぐらい ロール   : いまのところ6個にしぼっているけど今後は20ぐらいになりそう ステータス :6ぐらい トラッカー :20以下 正直な感想は、すごい!の一言。 Redmineはおそらくこんな規模まで運用するとは想定していないと思う。 上記の問題点は、Redmineによるチケット駆動開発のスケールアップにある。 サブチームの数が無制限でも運用に耐えれるのか?という問題。 スケールアップはプロセスの標準化と密接に

    チケット駆動開発のスケールアップ - プログラマの思索
  • Excelのプロジェクト管理は何故良くないのか - プログラマの思索

    XP祭り関西2010のTiDDセッションの感想を読んでメモ。 【元ネタ】 [TiDD] BTSがチケット駆動開発に向いている理由: ソフトウェアさかば 2010-02-07 - winplusの日記 XP祭り関西2010に参加してきた - Basic XP祭り関西2010でアジャイルとチケット駆動開発について考えてきた #xpjugkansai - Pragmatic Style 【1】2010-02-07 - winplusの日記の感想について、倉貫さんの事情は色々あると思うけど、僕の意見を一言。 (前略) それと、倉貫さんが「Redmine でも重い」「Googleのスプレッドシートでタスク管理している」という発言に、あきぴーさんが「僕は納得していない」と。 この日に目撃したほとんど唯一の衝突だったのですが、それ以上の展開がなかったので、すごく残念でした。 倉貫さんの Excelならダ

    Excelのプロジェクト管理は何故良くないのか - プログラマの思索
    katzchang
    katzchang 2010/02/09
    Excelの利点は自由度が高いことと、コピペが効きやすいこと。(BTSの利点はそもそもコピペが不要なことか)
  • Redmineに入れたプラグイン一覧 - プログラマの思索

    RedmineのVer0.8.4、0.8.6に入れたプラグインのうち、使っているものを公開してみる。 1年前に比べると、プラグインが充実していて楽しい。 結局10個以上も入れていた(^^;) 【コードレビュー】 r-labs - Code Review - Redmine Redmineのプラグインが充実している: プログラマの思索 リポジトリ画面からコードレビューのチケットを発行して、レビューをワークフロー管理できる。 お手軽にコードレビューできるのがいい。 レビューもチケットにするから、ワークフローのカスタマイズも可能。 【Hudson】 r-labs - Hudson - Redmine Redmineのプラグインが充実している: プログラマの思索 Hudsonと連携して、ビルド管理する。 SimpleCIプラグインよりもはるかに機能が充実している。 【Wiki拡張】 r-labs

    Redmineに入れたプラグイン一覧 - プログラマの思索
    katzchang
    katzchang 2010/01/14
  • 画面プロトタイプに対する違和感: プログラマの思索

    画面プロトタイプ専用ツールについてメモ。 【元ネタ】 NTTデータアジャイルネット Axure紹介サイト InfoQ: 要件抽出漏れ低減に貢献―画面プロトタイプを用いた要件抽出技法の紹介 開発現場のUIトラブルを解決!? 画面プロトタイプ入門(1/3)- @IT Rubyアジャイルプロトタイピング(1) - @IT Webシステム開発の要件定義では、紙芝居と言われるHTMLモックを作って顧客と要件を確認する。 しかし、結局作ってみないと来の要件が分からない時が多い。 又、紙芝居を見せると、ユーザはデザインやレイアウトに目が向いて、来の要件とは無関係の議論になりがち。 また、頻繁な仕様変更を反映しながら、設計書と実際のプログラムの同期を取るのも手間がかかる。 上記の専用ツールで解決できると言うが、当なのか疑問。 プロトタイピングによる開発をするくらいなら、Ruby on R

    katzchang
    katzchang 2010/01/13
    「「NTTデータアジャイルネット」の「アジャイル」は何を意味しているのだろう? 今「アジャイル」という言葉がインフレを起こしているので、曖昧な意味には注意しよう。」
  • Mercurialによるチケット駆動開発は強力だ! - プログラマの思索

    Mercurialを使ったチケット駆動開発の記事が非常に素晴らしいのでメモ。 このやり方を使いこなせれば、ソフトウェア開発の生産性は劇的に上がると思う。 【元ネタ】 mercurialでチケット駆動開発 - ろじぼ 上記の記事を理解できた範囲でまとめてみた。 【仮定】 ・SCMはMercurial。(Gitでも良い) ・BTSチケットでSW開発のタスクを管理する。 ・trunk、confirmブランチは中央リポジトリ(サーバー)にある。 ・チケットブランチ(トピックブランチ)は、ローカルとサーバーの2箇所にある。 常時同期されている。 ・作業の優先順位によって、チケットがリリース順≠開発順の状況はある。 【チケットAブランチ上の作業手順】 1・チケット担当時に、ブランチ作成。【チケットのステータス=担当】 ↓ 2・チケットAブランチ上でガンガン開発する。【チケットのステータス=担当】 →t

    Mercurialによるチケット駆動開発は強力だ! - プログラマの思索
    katzchang
    katzchang 2010/01/02
    チケット上で修正し、confirmで検証、チケットからtrunkへpush。
  • プログラマの思索: Subversionのブランチを有効活用してアジャイルに開発せよ

    デブサミ2008講演資料の「SubversionとMaven 2 による構成管理」を読んで、改めてソフトウェア開発ではソース管理が最重要であると再認識した。 ソース管理について振り返ってみる。 【1】ソース管理の歴史 ソフトウェア開発では、ソース管理が必須だ。 ソース管理の質は、履歴を辿って、いつでもソースをUndo、Redoできること。 昔のコンピュータ資源が希少な時、そもそもプログラムを履歴に残すことすらできなかっただろう。 今でもリリース時によくやるように、システム一式を複製して日付でリネームしていた。 僕は当初、ソース管理に、MSのVisualSourceSafeを使っていた。 CVSよりも直感的でGUIが使いやすい。 VSSを使い始めてから、下記の作業がルーチンになった。 朝、出社後、VSSから最新ソースを落として、VisualAgeForJavaのワークスペースにインポートす

    プログラマの思索: Subversionのブランチを有効活用してアジャイルに開発せよ
    katzchang
    katzchang 2009/12/25
    「ブランチはメインラインから行う。つまり、ブランチからブランチを切ることはしない。」
  • プランニングポーカーのカードが欲しい - プログラマの思索

    katzchang
    katzchang 2009/10/29
    「「アジャイルな見積りと計画づくり ~価値あるソフトウェアを育てる概念と技法~」第2版が出版されたのを記念に、プランニングポーカーのカードが付属して売られている」ほしいなー。
  • テスト手法の概念をTestLinkで説明する - プログラマの思索

    Excel! TestLinkでアジャイルにテストをする - @IT自分戦略研究所で書ききれなかったテスト手法の概念についてメモ。 【元ネタ】 脱Excel! TestLinkでアジャイルにテストをする - @IT自分戦略研究所 TestLinkを運用して気付いたことpart8~みなしバグ、ブロッキングバグ、周辺テスト、そしてクリティカルパス: プログラマの思索 TestLinkを運用して気付いたことpart9~後追いテスト: プログラマの思索 下記の資料にまとめてみた。 ちなみに下記のテスト用語(方言?)はTEF関西のNakaさんから教わった。 【1】ブロック、ブロッキングバグ、みなしバグ、みなしOK、周辺テストの概念 上記1枚目で、Ver2.0のカート削除1のテストケースでテストに「失敗」したとしよう。 その場合、カート削除2のテストは、カート削除1のバグに依存して必ず失敗するから、

    テスト手法の概念をTestLinkで説明する - プログラマの思索
    katzchang
    katzchang 2009/10/26
    こちらも。
  • チケット駆動開発の運用例part3 - プログラマの思索

    チケット駆動開発の運用例を見つけたのでメモ。 【元ネタ1】 [tech]チケット駆動開発 - Kazumi007の日記 特徴は下記の通り。 ・開発環境は、CVS+Jira。 ・タスクはチケットを切り、CVSコミット時は必ずチケットNoを入力する。 ・Jiraの柔軟なワークフロー管理機能を使って、SW開発全体のタスクを管理する。 ・Jiraのチケットのサブタスク機能(1レベル下のサブタスクを登録可能)を使い、親チケットはストーリーカード、子チケットはタスクカードのように運用する。 TiDDで良かった点で、「情報がJIRAに集まるため、ますますJIRAに情報が集まるようになった。」という感想が素晴らしい。 インターネットでは、情報をたくさん出すページに情報がどんどん集まる。 JiraがSW開発の情報収集・出力のハブになっている良い運用例。 「ゴールの見えないチケット」「有効期限切れのチケット」

    チケット駆動開発の運用例part3 - プログラマの思索
    katzchang
    katzchang 2009/09/26
  • アジャイル開発のFAQ - プログラマの思索

    アジャイル開発のFAQについてメモ。 【1】アジャイル開発のような繰り返し型開発は、作業やリソースの重複が多くて生産性が低いのではないですか? 【回答】最初のイテレーションは試行錯誤しがちですが、イテレーションをこなすたびに慣れていき、生産性は上がっています。 特にSW開発は常に新技術を取り入れているので、開発者の学習曲線を考慮する必要があります。 アジャイル開発では、開発者の成長を意識的に支援するプラクティスが含まれています。 例えば、イテレーション毎にふりかえりMTを開いてプロセス改善する意識を開発者に植え付けますし、ペアプログラミングで開発者と技術や設計思想を共有するプラクティスもあります。 特に、プロジェクトファシリテーションでは、開発者の成長を促進するプラクティスが多々あるので参考にしてみてはいかがでしょうか? 【2】開発を繰り返すから、コストが高いのでは? 【回答】最初のイテレ

    アジャイル開発のFAQ - プログラマの思索
    katzchang
    katzchang 2009/09/24
    あと、顧客もリリースに慣れるってのが重要だと思う。
  • ドキュメントも構成管理すべきだ - プログラマの思索

    SVNで構成管理する時の良い記事が公開されたのでメモ。 【元ネタ】 Subversionで簡単・確実にファイルを構成管理 - @IT自分戦略研究所 SVNの使い方の記事はネット上にいくらでもある。 しかし、上記の記事で重要と思われる内容は、構成管理や変更管理の考え方を初心者向けに分かりやすく説明している点と、ドキュメント管理に構成管理の考え方を入れるべきだという主張だ。 CMMIの観点では、ソフトウェア構成管理は「変更管理を含むソフトウェアの構成を制御・管理できていること」と定義されている。 この考え方に基づくと、バージョンとは実はプロセスのベースラインを意味する。 つまり、リリース時にバージョン(又はタグ)を付けるタイミングは、開発者から顧客へ、あるいは営業チームから顧客へ、などのように、他者へ成果物を手渡すタイミングと同一なのだ。 構成管理が変更管理と密接に関係する理由は、上記のような

    ドキュメントも構成管理すべきだ - プログラマの思索
    katzchang
    katzchang 2009/09/01
    自分とこはドキュメントから導入を始めた。社内文書も構成管理すりゃいーのにとか思いながら。