アジャイルな契約と請負契約の比較 - プログラマの思索
最近注目されているアジャイルな契約が何故請負契約よりも優れていると思われるのか、考えたことをラフなメモ書き。 理解が間違っていたら後で直す。 【元ネタ】 Twitter / @akipii: その資料が是非見たい！委任契約と請負契約以外の選択肢はあるかな？ RT @haradakiro: アジャイル契約のプレゼン資料つくってたら、ウォーターフォール成立の歴史だけで時間を使い尽くしそうな勢い。 Twitter / @haradakiro: @akipii 発表前なのでちょっとお待ちを、というかまだできていないww 「次のアジャイルソフトウェアプロジェクトに使える10の契約」はご存知でしたか？ http://bit.ly/93lTtB 自分の話は、三者契約によってリスクと責任を分散させる話です。 Twitter / @akipii: @haradakiro 知らないので読んでみます。委任契約と
データベース設計で派生関係は難しい - プログラマの思索
@t_wadaさんが、データベース設計の素晴らしい資料をリンクしていたのでメモ。 下記の資料は、MySQLでソーシャルゲームのDB設計のお話らしいが、データモデリングの設計ノウハウが秀逸。 気になった点をメモしておく。 理解できたことをラフなメモ書き。 【元ネタ】 Twitter / Takuto Wada: 素晴らしい資料。"「スキーマ」「トランザクション」「インデックス」はもっと評価されるべき" / ソーシャルゲームのためのデータベース設計 http://htn.to/PzrnbR 【1】可用性や整合性に関する要求が意外と多い たとえ、SNSやゲームであろうが、課金体系になるとお金が絡むため、ユーザの要求のレベルも上がるし、事業者の責任も大きくなる。 データモデリングはアーキテクチャ設計につながる。 【2】派生関係 データベース設計(DOA)でも、派生関係(継承関係）はオブジェクト指向
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ならダ
チケット駆動開発の運用例part3 - プログラマの思索
チケット駆動開発の運用例を見つけたのでメモ。 【元ネタ1】 [tech]チケット駆動開発 - Kazumi007の日記 特徴は下記の通り。 ・開発環境は、CVS＋Jira。 ・タスクはチケットを切り、CVSコミット時は必ずチケットNoを入力する。 ・Jiraの柔軟なワークフロー管理機能を使って、SW開発全体のタスクを管理する。 ・Jiraのチケットのサブタスク機能(1レベル下のサブタスクを登録可能)を使い、親チケットはストーリーカード、子チケットはタスクカードのように運用する。 TiDDで良かった点で、「情報がJIRAに集まるため、ますますJIRAに情報が集まるようになった。」という感想が素晴らしい。 インターネットでは、情報をたくさん出すページに情報がどんどん集まる。 JiraがSW開発の情報収集・出力のハブになっている良い運用例。 「ゴールの見えないチケット」「有効期限切れのチケット」
要件管理はチケット駆動開発で実装できるか？ - プログラマの思索
要件管理をRedmineやTrac上で試しているが、しっくりこない原因をメモ。 【元ネタ】 チケット駆動開発とTestLinkによる開発プロセスの改善 (Shibuya.trac #4.5) - まちゅダイアリー(2009-09-11) チケット駆動開発は進捗報告作りをどのように解決しようとするか？: プログラマの思索 RedmineへScrumのアイデアを注入: プログラマの思索 まちゅさんは、「チケット駆動開発とTestLinkによる開発プロセスの改善 (Shibuya.trac #4.5) - まちゅダイアリー(2009-09-11)」で下記のようなコメントを残している。 TiDD は開発プロセス全体を網羅するものではない。開発プロセスを補完するもの。 * チケットの粒度が細かいことと、構成管理ツールと密接な関係があることから、アウトプットが明確な領域に適用しやすい。 * 要件定義な
チケット駆動開発のベストプラクティスを収集したい - プログラマの思索
チケット駆動開発を実践して、色々考察してきて、ベストプラクティス集を作りたいと思っている。 理由は、チケット駆動開発とアジャイル開発の密接な関係を明確にして、アジャイル開発を簡単に運用できるノウハウとして公開したいからだ。 僕は、チケット駆動開発には下記4個のプラクティスが最低限必要だと思っている。 但し、XPのプラクティスと同じだがTiDDの言葉で言い換えているものもあるので注意。 １・チケット・ファースト(Ticket First) 【説明】 基本は、プロジェクトの作業はチケットを受け取ってから始める。 チケット無しで作業はしない。 また、SVNコミット時に、チケット無しのコミットも不可。 【効用】 チケットがタスクカード(作業指示書)のため、コミュニケーションロスがなくなるし、作業履歴がチケットのコメントとして残る。 進捗情報は全てチケットに書くから、BTSのチケット集計機能でリアル
チケット駆動開発のFAQ - プログラマの思索
チケット駆動開発についてのFAQをまとめてみた。 他に聞きたい質問があれば、コメントして下さい。 チケット駆動開発のFAQを集めれば、チケット駆動開発を普及させるのに役立つと思うから。 【元ネタ】 チケット駆動開発 … ITpro Challenge のライトニングトーク (4) - まちゅダイアリー(2007-09-07) TiDD：チケット駆動開発: ソフトウェアさかば RedmineとTracの機能比較: プログラマの思索 脱Excel！ Redmineでアジャイル開発を楽々管理 － ＠IT自分戦略研究所 Tracのワークフロー: プログラマの思索 ワークフロー機能のカスタマイズ方法 - かおるんダイアリー そろそろTracのワークフローについて語っておくか - almost nearly dead チケット駆動開発は進捗報告作りをどのように解決しようとするか？: プログラマの思索
プロジェクト管理サーバーのメトリクスは教科書みたいだ - プログラマの思索
プロジェクトが一段落したから、メトリクスを出力してみた。 その時に気付いたことをメモ。 【元ネタ】 プログラマの思索: プロジェクト管理サーバーとは プログラマの思索: アジャイル開発の弱点をプロジェクト管理サーバーが助ける 【各種ツール】 BitNami :: Trac All In One TestLink JP TestLinkCnvMacro StatCVS - Repository Statistics StatSVN - Repository Statistics Tracから、カテゴリ、マイルストーン、解決方法、種類などの観点のチケット集計結果。 TestLinkにあるテスト実績からTestLinkCnvMacroを使って、テストケースの成功・失敗・ブロックの累積グラフ、曜日別・時間別・ピーク時間別のテスト実績、そしてテスター毎の生産性グラフ。 SVNリポジトリやCVSリポジ
XDDPと言う派生開発 - プログラマの思索
初めて、XDDPと言う派生開発の提唱者である清水さんの話を聞いた。 本は2冊読んでいたけれど、自分の理解が不十分だったことに気付いた。 以下、メモ書き。 【1】XDDPの最大の特徴は、SW開発の殆どは機能追加という保守開発である、という認識を前提としたアジャイルっぽい開発スタイルにある。 ソースからリバースエンジニアリングで要求仕様書を作り、ソースをダラダラと修正するのではなく、一気に修正してしまう。 駄目なプロジェクトでは、ソースに手を入れては修正漏れが出て、それを直してはまたバグが出る、といった症状が多い。 影響範囲や修正方法を確実に見極めれずに、ソースに手を入れてどんどん劣化させてしまう最悪なパターン。 清水さんのフレーズで面白いと思ったのは「移植作業は、ソフトウェアでも拒否反応を起こす」という内容。 人体でも、風邪を引いた場合、抗生剤を飲む。 しかし、抗生剤は人によっては免疫機能が
金曜にバグを発生させるコミットが多い - プログラマの思索
小川 明彦, 阪井 誠 : チケット駆動開発 日本のソフトウェア開発の現場で生み出された「チケット駆動開発」という概念を、数多くの実例を元にモデル化・体系化を試みた最初の本。 小川 明彦, 阪井 誠 : Redmineによるタスクマネジメント実践技法 Redmineによるチケット駆動開発の実践技法に関する最初の本。アジャイルなソフトウェア開発への適用方法、TestLinkによるテスト管理手法についても言及。 清水 吉男: 「派生開発」を成功させるプロセス改善の技術と極意 組込システム開発をベースとして、ソフトウェア開発特有のスタイルである派生開発、特にXDDPについて解説した世界でも稀な本。既存製品を保守するのではなく継続的に機能追加していく昨今の開発では、派生開発特有の問題を意識しなければならない。XDDPはプロセス論だけでなく、要件定義などの上流工程の品質改善にも役立つので注意。 Le
チケット駆動開発は進捗報告作りをどのように解決しようとするか？ - プログラマの思索
【1】管理者は、プロジェクトの進捗報告のためのくだらない作業が必要になる。 まず、初期段階で、WBSとして必要な成果物、作業を洗い出す。 そこから、工数を見積もり、MSProjectやExcelでスケジュールを作っていく。 しかし、実際に作業していくと、そのスケジュールの保守は面倒きわまりない。 当初は分からなかったタスクを追加したり、仕様変更で対応すべきタスクを入れたり、実際は不要になったタスクを削除するなどを、逐一スケジュールへ反映しなければならない。 スケジュールで、先行・後行の関係まで考慮したり、工数の標準化などを行おうとすると、もはやExcelで手作業で管理するのはもはや人間の手を超える。 MSProjectでは、そのような作業をアプリでやってくれるが、だからと言って、スケジュール保守が楽になるわけではない。 そのスケジュールを管理者が常に保守し続けなければならない理由は二つある
アジャイルごっこ - プログラマの思索
「アジャイルな見積りと計画づくり ~価値あるソフトウェアを育てる概念と技法~」で指摘した「アジャイルごっこ」についてメモ書き。 【元ネタ】 続・書評『アジャイルな見積りと計画づくり』 - TECH-moratorium ： テクモラトリアム DeclineAndFallOfAgile - アジャイルの衰退と凋落 【1】「アジャイルな見積りと計画づくり ~価値あるソフトウェアを育てる概念と技法~」の訳者あとがきに、こんな一節がある。 XPを代表とするアジャイル開発の技術的プラクティスは、開発現場の日々の作業を明らかに改善してくれる。 しかし、その効果はいずれ限界が来る。 結局、プロジェクトのスコープとスケジュールが固定されている状況では、最終的に開発者に様々なしわ寄せが来る。 このように、開発者だけがアジャイルなプラクティスを導入している状況を、木下さん(レビューワー)は「アジャイルごっこ」
ITの地殻変動はどこで起きているのか？～チケット駆動開発はなぜ生まれたのか - プログラマの思索
2009年になって、ITの地殻変動がどこに起こっているのか？を考えてみる。 ＃ラフなメモ書き。 【参考】 InfoQ: Martin Fowler氏が語る陥りがちなスクラムの落とし穴を避ける方法 InfoQ: 複数のアジャイルチームでのバージョン管理 チケット駆動開発 … ITpro Challenge のライトニングトーク (4) - まちゅダイアリー(2007-09-07) 【アジャイル開発の問題点】 1990年代後半から、サーバー＋クライアントの2層方式を基本とするVBアプリからMVCを基本とするWebシステムへのリエンジニアリングがあった。 更に、システムが大規模化して、開発期間が短くなるSW開発の現場。 RUPなど、イテレーティブな開発プロセスの重要性が叫ばれるものの、実際の現場で運用するにはハードルが高かった。 2000年頃出現したXPは、ソフトウェアの歴史の中で、オブジェクト
プログラマの思索: ツールが開発プロセスを改善する
Redmineでチケット駆動開発(TiDD)を運用して気付いたことは、開発プロセスが大きく改善されただけでなく、従来の開発プロセスの弱点が浮き彫りになったこと。 下記の記事を読んで考えたことを書いてみる。 【元ネタ】 ケント ベック氏のアジャイル開発における開発支援ツールの役割についてのホワイトペーパー 元請SIerがTracのような環境を提供できない３つの理由 - なからなLife 元請け企業が用意すべきもの - T/O 【1】強力な構成管理ツールが無い時代はライブラリアンが独裁者 構成管理の基本は、任意のバージョンのシステムを再現できること。 今時、Subversionのようなバージョン管理ツールの無いSW開発プロジェクトはありえないだろう。 CVSやVSSが無かった頃は、構成管理ツールなど存在せず、構成管理を人手でやるしかなかった。 今でも、Excelなどの設計書はバージョン管理で制
REST思想とHTTPメソッドの関係 - プログラマの思索
RESTの基本的な発想は、HTTPメソッドでリソースをCRUDできるはずだ、というアイデア。 では、HTTPメソッドは、そもそもどんなものなのか？ 「安全なメソッドと冪等{idempotent} なメソッド」でいくつか語られている。 「RESTful Webサービス」で「べき等」という概念が出てくる。 「べき等」とは、同じ操作を何度行っても同じ結果であること。つまり副作用がなく安全であることを意味する。 少なくとも、GETはべき等に使うならば、安全であると言える。 しかし、GETで、リソースの削除や更新を行う時も、実はよくある。 REST思想に従うならば、GETは副作用を起こしてはいけない。 POST、PUT、DELETEがリソースの更新で副作用を起こすように使うべき。 RailsはREST思想を忠実に反映している。 また、Strutsも「http://～/***.do」というURLを見る
システム開発から属人性を排除しようとして失敗する - プログラマの思索
ひがさんの記事「「誰が書いても同じコード」は大事なことなのか」を読んで思ったことを書いてみる。 大手SIerは独自の重量級の開発プロセスを持つ。 それは多分、メインフレーム＋Cobol時代の開発プロセスを最近のオープン系に焼き直したものに過ぎない。 その現場のプロジェクトは大規模で人数も多いから、少数精鋭チームで自由に動くわけにはいかない。 その開発プロセスの意図は、誰が作業しても同じような品質を保つ所に重点を置く。 つまり、属人性を排除しようとする。 だから、できない人もルーチンのような作業までレベルアップするが、できる人は、無駄なドキュメント作成やマネジメント、そして古臭くなったコーディング規約などの運用ルールに縛られている。 彼らのプロジェクトはタンカーのように、一度動き出したら進路を変えるのは凄く難しい。 現在の特にWebシステム開発では、頻繁なリリースによるバージョンアップが多い
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
