現代のAgile開発が抱える課題 - プログラマの思索
チケット駆動開発でAgile開発を初めて実践できて、Agile開発の長所や短所が色々分かってきた気がする。 今の時代にAgile開発はとても優れていると思っているが、乗り越えるべき課題はまだまだある。 その課題も、時代の変化によって、より難しいレベルまで要求されているように思う。 2000年代に現れたXPを代表とするAgile開発は、その利点は広く知られてきたが、適用の限界や短所について従来から指摘され続けてきている。 その課題についてまとめてみる。 #考えたことをラフなメモ書き。書きかけもある。 【1】Agile開発はプロジェクト管理が弱い アジャイル開発でプロジェクト管理、そしてプロセスを管理する部分が弱いという指摘は従来から言われていた。 確かに、PMBOK、CMMIなどの観点から見れば、Agile開発はプログラミング重視で全体的なプロセス設計がなされていないように思える。 だが、S
アート・オブ・プロジェクトマネジメントを読み直してTiDDを補強する - プログラマの思索
「アート・オブ・プロジェクトマネジメント」を読み直して、チケット駆動開発を運用した経験から、そうだよ！と何度も頷くところがあった。 ラフなメモ書き。 【元ネタ】 「 アート・オブ・プロジェクトマネジメント」の検索結果1 - 脱・下流エンジニア (仮) 「 アート・オブ・プロジェクトマネジメント」の検索結果2 - 脱・下流エンジニア (仮) 【12章 リーダーシップが信頼に基づく理由】 「表明」とはコミットメント、約束を意味する。 メンバーが表明することによって、小さな約束が積み重ねられて、一つのシステムが完成する。 チケット駆動開発では、チケットファーストの原則に表明の概念が組み込まれている。 プロジェクトで発生する全ての作業は、チケットに起票してから開始する。 WBSから起こされたタスクも、突発的な事件によって発生したタスクも、まずチケットに起票する。 そのチケットには、開始日と終了日、
電子書籍の作り方 - プログラマの思索
iPod touchで電子書籍を作って読む方法が分かったのでメモ。 【元ネタ】 hikariworks::blog ? Stanza iPhoneアプリで手元に図書館が [ipod touch]さっそく、Stanzaをいれてみた | たまには人柱も悪くない 書類をstanzaでiPhoneに移植：Winged Dogの本棚：So-netブログ EPUBを作製してStanza Desktopで見てみた ? NODE 科学、技術、サブカル ニュース iBooksが待ちきれず「EPUB」を自作する - unakami - builder by ZDNet Japan EPUB形式で作成した電子書籍を、iPhoneやPCのStanzaで読んでもらう方法 - RyoAnna’s iPhone Blog 【ツール】 Stanza: a Revolution in Reading | Lexcycle
TracのscrumプラグインAgilo: プログラマの思索
小川 明彦, 阪井 誠 : チケット駆動開発 日本のソフトウェア開発の現場で生み出された「チケット駆動開発」という概念を、数多くの実例を元にモデル化・体系化を試みた最初の本。 小川 明彦, 阪井 誠 : Redmineによるタスクマネジメント実践技法 Redmineによるチケット駆動開発の実践技法に関する最初の本。アジャイルなソフトウェア開発への適用方法、TestLinkによるテスト管理手法についても言及。 清水 吉男: 「派生開発」を成功させるプロセス改善の技術と極意 組込システム開発をベースとして、ソフトウェア開発特有のスタイルである派生開発、特にXDDPについて解説した世界でも稀な本。既存製品を保守するのではなく継続的に機能追加していく昨今の開発では、派生開発特有の問題を意識しなければならない。XDDPはプロセス論だけでなく、要件定義などの上流工程の品質改善にも役立つので注意。 Le
アジャイル開発の最後の弱点 - プログラマの思索
テスト工程のマネジメントは、ソフトウェア開発の上流工程におけるプロジェクトマネジメントよりもはるかに難易度は高い。 TestLinkを使ってみると、Redmineの運用よりもはるかに難しい。 一つでもバグが出るたびにブロックが発生して、前進できないのだ。 ブロッキングバグをストッピングバグとも呼ぶ事実を今夜初めて知った。 テストでは、ブロッキングバグ修正の優先順位付けがとても重要。 ブロッキングバグが直れば、ブロックした大量のテストケースを再開できるからだ。 そして、テストにもクリティカルパスがある。 プロジェクト管理の基本はクリティカルパスの管理だから、テスト工程のそれを見つけて、意思決定を間違えないように管理するのが凄く大事。 テストと品質保証はアジャイル開発の最後の弱点。 チケット駆動開発によって、SW開発のタスク管理やワークフロー管理はスムーズになる。 しかし、テスト工程では、チケ
TiDDとWFとScrumとLeanの違い - プログラマの思索
開発プロセスの違いについて良い記事があったのでメモ。 【元ネタ】 [Agile]WFとScrumとリーンの違い | Ryuzee.com WFの弱点は「計画に依存しすぎているので、計画が間違っていたらリスクが高い」「プロジェクトの終了直前のデプロイまで、何の価値も実現できない」点にある。 実際の現場では、結合テストで火を噴いてビッグバン統合に失敗する症状に全てが言い尽くされていると思う。 このWFを繰り返し型開発へ変形した場合、確かにリスクは減るが、最大の弱点は「ボトルネックが発生してしまい、それを制御できない」点にある。 全ての作業の遅れが積もり積もって、バッファを食い潰すのだ。 TOCのクリティカルチェーンの話を思い起こさせる。 Scrumではイテレーション単位に、Plan・Build・Test・Reviewが並行で動き、リリース前にReviewとDeployが行われる。 つまり、実装
【公開】第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さんのやり方が良いと思う。 思い出してみたら、下記の
チケット駆動開発とアジャイル開発の密接な関連 - プログラマの思索
小川 明彦, 阪井 誠 : チケット駆動開発 日本のソフトウェア開発の現場で生み出された「チケット駆動開発」という概念を、数多くの実例を元にモデル化・体系化を試みた最初の本。 小川 明彦, 阪井 誠 : Redmineによるタスクマネジメント実践技法 Redmineによるチケット駆動開発の実践技法に関する最初の本。アジャイルなソフトウェア開発への適用方法、TestLinkによるテスト管理手法についても言及。 清水 吉男: 「派生開発」を成功させるプロセス改善の技術と極意 組込システム開発をベースとして、ソフトウェア開発特有のスタイルである派生開発、特にXDDPについて解説した世界でも稀な本。既存製品を保守するのではなく継続的に機能追加していく昨今の開発では、派生開発特有の問題を意識しなければならない。XDDPはプロセス論だけでなく、要件定義などの上流工程の品質改善にも役立つので注意。 Le
チケット駆動開発を日本発のアジャイル開発へ発展させるには？ - プログラマの思索
さかばさんの記事を読んで考えたことをメモ。 【元ネタ】 [TiDD] 小規模開発の難しさを考える: ソフトウェアさかば チケット駆動開発 … ITpro Challenge のライトニングトーク (4) - まちゅダイアリー(2007-09-07) アジャイル開発は元来、小規模で変化の激しいプロジェクトが向いていると言われてきた。 しかし、XPが出現して10年も経つというのに、現場の実践例は非常に少ない。 ネット上でアジャイル開発の情報がこれだけ溢れていて、開発者も興味を持っているのに、事例になかなかお目にかからない。 情報処理試験の勉強でも、プロセス改善のセミナーでも、繰り返し型開発の重要性が叫ばれているのに、事例は非常に少ない。 その原因は、単純にアジャイル開発を実践できる技術力が足りないからだと思っている。 テスト駆動開発を実践するには、JUnitを使いこなさねばならない。 常時統合
チケット駆動開発が進むべき道 - プログラマの思索
さかばさんのBlogにTiDD(チケット駆動開発)の分析が書かれているのでメモ。 【元ネタ】 必然から生まれたチケット駆動開発 - XP祭り関西2009 その３-: ソフトウェアさかば TiDD：チケット駆動によるアジャイル開発法: ソフトウェアさかば TiDD：チケット駆動開発: ソフトウェアさかば [TiDD] チケット駆動開発とXPの共通点: ソフトウェアさかば [TiDD]チケット駆動開発と見える化: ソフトウェアさかば [TiDD] チケット駆動開発によるフロントローディング: ソフトウェアさかば [TiDD] プラクティスから方法論へ: ソフトウェアさかば TiDDとアジャイル開発に強い関連性があると色んな観点から分析されている。 TiDDはまだ定義すらない曖昧な概念であり、プロセスですらない。 今後進むべき方向は、方法論やベストプラクティス集を定義することだろう。 僕はTiD
TestLinkのFAQ - プログラマの思索
TestLinkを運用する時のFAQをまとめたみた。 TestLinkは癖があるために運用しにくいと思うので是非参考にして欲しい。 【元ネタ】 【公開】ETWest2009講演資料「TestLinkでアジャイルにテストする」: プログラマの思索 簡易マニュアル - TEF有志によるテスト管理システムTestLink日本語化プロジェクト 連載：きちんと学びたいテストエンジニアのためのTestLink入門｜gihyo.jp … 技術評論社 TestLinkCnvMacro 【テスト計画】 【1】TestLinkをインストールしましたが使いこなせません。TestLinkはSW開発のどの工程で運用すれば効果的ですか？ 【回答】 TestLinkを運用する場合、結合～受入テストで導入するのが良いでしょう。 TestLinkは手動のテストを管理するためのツールなので、自動化しやすい単体テストよりも、業
RedmineとTracの機能比較 - プログラマの思索
RedmineとTracの両方でチケット駆動開発を運用してみて、色んな気付きがあった。 以下メモ書き。 【比較対象】 ・Redmine0.8.0 ・Trac0.11.1.ja 【元ネタ】 脱Excel！ Redmineでアジャイル開発を楽々管理 － ＠IT自分戦略研究所 【1】複数プロジェクトの扱い RedmineがTracよりも機能が優れている点の一つは、複数プロジェクトに対応していること。 Tracはプロジェクトに親子関係を入れることができないため、特に大規模プロジェクトではチケット駆動開発を実践しにくいだろうと思う。 複数プロジェクトを作りたい状況は、二つある。 【1-1】開発チームが複数のサブチームに分かれていて、それぞれでタスク管理したい場合。 RedmineやTracを運用してみると、一つのプロジェクトでメンバーが5人以上だとチケットが乱発されたり、放置されやすくなるようだ。
【公開】KOF2008講演資料「Redmineでチケット駆動開発を実践する～チケットに分割して統治せよ」 - プログラマの思索
関西Ruby会議01＠関西-KOF2008講演資料「Redmineでチケット駆動開発を実践する～チケットに分割して統治せよ」を公開します。 CC Attribution ライセンスとします。 【元ネタ】 チケット駆動開発 … ITpro Challenge のライトニングトーク (4) - まちゅダイアリー(2007-09-07) チケット駆動開発は、まちゅさんが最初に提唱された。 しかし、チケット駆動開発の概念はまだ曖昧で、一部でしか注目されていない。 僕は、Redmineというプロジェクト管理機能を持つBTSがプロジェクト管理をIT化してくれて、プロジェクト運営が大きく変わったことを経験した。 その体験をチケット駆動開発(Ticket Driven Development)という概念へ昇華できないか、考えた内容が上記の資料です。 コメントがあれば嬉しいです。 【参考】 Rubyist
TestLinkを運用して気付いたこと - プログラマの思索
TestLinkをテスト仕様書代わりに運用し始めて、メーリングリストで使い方を聞いたり、自分で色々試してみた。 色んな気付きがあったのでメモ。 【1】数千、数万のテストケースをTestLinkへインポートするには、下記のExcelマクロでXML出力して、TestLinkのXMLインポート機能を使う。 このツールのおかげで、既存のテスト仕様書からTestLinkへテストケースをコンバートするのが非常に簡単になった。 TestLinkCnvMacro TestLinkへテストケースを全てインポートして一番驚いたのは、わずか数人のプロジェクトですら、テストケースが1千ケースを越えていることだ。 但し、ここでのテストケースは単体テスト、結合テストのどちらも含んでいる。 今の感触では、20人月規模のプロジェクトならば、TestLinkへインポートするテストケース数は1万ケースを越えるだろう。 つまり
プログラマの思索: アジャイル開発は構成管理ツールが必須条件だ
「Trac入門 ――ソフトウェア開発・プロジェクト管理活用ガイド」を何度も読み直している。 下記のBlogも読みながら、ソフトウェア構成管理について考えたことを書く。 【元ネタ】 ケント ベック氏のアジャイル開発における開発支援ツールの役割についてのホワイトペーパー ソフトウェア構成管理方針の策定（変更管理編） バージョン管理とソフトウェア構成管理の関係 【1】アジャイル開発は変更管理プロセスに強い 変更管理プロセスが弱いとトラブルが多いという話を聞いたことがある。 ITシステムは変更に起因するインシデントによって、必ず変更が起き、それが遠因となってトラブルが起きやすい。 例えば、OSやソフトのバージョンアップなど。 つまり、今まで「あるべき姿」で稼動していたのに、ある時点で「おかしくなった現在の姿」へ方向が変わり、時間が経つにつれて、ギャップが生じる。 このギャップがトラブルだ、と。 だ
XPを実現するCaseツールは？→Redmineだ！ - プログラマの思索
JaSST関西2008で出た質問。 アジャイル開発を現場で使っているが、イテレーションが短くて多いから管理しにくい。 イテレーションを管理できる良いCaseツールはありますか？ XPJUG関西代表の細谷さんは立場上曖昧に答えたけれど、僕の回答は、Redmineを使って下さい、だな。 RedmineこそXPを実現する開発インフラです。 Redmineでチケット駆動開発を実践すれば、XPの計画ゲームを実現できます。 と。 Redmineを2ヶ月使ってみて、プロジェクトリーダーの本来の仕事である、タスクの優先順位付けやリスク管理に時間を費やせるようになった。 【1】もう一度おさらい。 Redmineでプロジェクト作成後にまず設定するものは下記の通り。 1-1.バージョン マイルストーンと同値。 XPのイテレーションに相当する。 1-2.カテゴリ システムの機能別の単位。 XPのストーリーカードの
プログラマの思索: バージョン管理できないプロジェクトの成果物は信用できない
「バージョン管理が原因だとしたらかなりヤバイよ三菱東京UFJ」「三菱東京UFJのトラブルの原因が日経コンピュータに載ってます」の記事を読んだ感想を書く。 【1】デグレ発生が意味するもの 三菱東京UFJのトラブルの原因は下記の通り。 かいつまんで書くと「テストは充分にしていたが、バージョン違いのモジュールを本番リリースしてしまった」ということのようです。 上記の記事を書いた人は、事件の重大性が分かっているのだろうか？ 本番リリース時にデグレが発生したという事実は、下記の意見と全く同じ。 つまり、下記の記事のように、プロジェクトの成果物全てが危険な状態にあるのではないか？という事実を示唆させるからだ。 ところが、デグレやバージョン相違は違います。最新バージョンでないものを使って修正した結果、直したはずのバグや仕様変更が落ちたり、リリースするファイルを間違えてしまったりするのは手続きを遵守でき
プログラマの思索: Redmineを使って気づいたこと
日々の新規開発をRedmineのチケットで進捗管理して気づいた点があったのでまとめてみる。 【1】ロードマップを見ると、進捗率が逆に下がる場合がある 下記のロードマップになるようにチケットを登録したと仮定しよう。 ◆ロードマップ1：5月1日現在 進捗：0％ #1 機能Aの開発（新規） #2 機能Bの開発（新規） #3 テスト（結合テスト）（新規） すると、普通は、0％→33％→66％→100％ と進捗率が上がって終わるはず。 ◆ロードマップ1：5月5日現在 進捗：100％ #1 機能Aの開発（終了） #2 機能Bの開発（終了） #3 テスト（結合テスト）（終了） しかし、テストでバグが上がったり仕様変更が入った時、バグ報告をチケットに登録すると、下記のようになる。 ◆ロードマップ1：5月6日現在 進捗：42％ ← 終了3件/全7件だから。 #1 機能Aの開発(終了) #2 機能Bの開発(終
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
