スケジュールを見ればマネージャのレベルが分かる - プログラマの思索
@hatsanhatさんから「スケジュールを見ればマネージャがどこまでリスクを見通しているかが分かる」という指摘を聞いて考えたことをメモ。 【元ネタ】 Twitter / @akipii: Redmineによるチケット駆動開発を成功させるには全てのタスクを1人日以下まで分割しきれるかどうかが鍵。詳細レベルまで落とし込めれば作業手順もリリースサイクルもリスクもほとんど見通せているから。スケジュールを見ればPMがどこまでリスクを見通せているかすぐに分かる。 Twitter / @akipii: @dproject21 Redmineもチケット駆動開発も銀の弾丸じゃないんですよね。プログラミングやモデリングでシステム開発をどこまで解決できるか。アジャイル開発は作業を手抜きできると思う人がいるけど結局正攻法しかないんですよね。 【1】Redmineでチケット駆動開発を運用していると、チケットの粒度
ハードなプロセス、ソフトなプロセス - プログラマの思索
さかばさんの記事を読んで思ったことをラフなメモ書き。 【元ネタ】 [#TiDD] チケット駆動開発の開始タイミング - 良いプロダクトはふさわしいプロセスが生む -: ソフトウェアさかば システム開発から属人性を排除しようとして失敗する: プログラマの思索 さかばさんが書かれているように、製造業の会社から派生したSIはハードウェアの開発に憧れて、ソフトウェア工場によるソフトウェア開発の工業化を目指していたように思える。 属人化を廃し、信頼性重視の開発スタイル。 (前略) ソフトウェア開発の歴史を振り返ると、ソフトウェアはハードウェアの開発にあこがれていたと思います。各社が「ソフトウェア工場」を作り、ソフトウェア開発の工業化を目指していました。 工業化における品質とは主に信頼性です。計画された仕様が満たされたかどうか、設計どおりに実現されているか、それが求められます。当初定められた計画通りに
派生開発を成功させるプロセス改善の技術と極意 - プログラマの思索
清水吉男さんの「「派生開発」を成功させるプロセス改善の技術と極意」を読んだ。 気付いたことをメモ。 【1】是正保守と改良保守の違い ソフトウェア保守 - Wikipediaの定義がJISに公開されている。 是正保守は普通の障害修正に近い。 改良保守は、既存の製品に新機能を追加していくこと。例えば、ケータイにカメラやワンセグ、お財布携帯を追加していくこと。 後者はどう考えても保守ではない。清水さんはこの保守を意識して区別している。 おそらく世の中のSW開発の殆どは派生開発である、という指摘は、組み込み製品だけではなく、大規模な業務システムほど同様だ。 だから、継ぎ接ぎだらけで、たくさんの人のパッチが入った複雑なシステムになりがち。 リファクタリングそのものも危険になるから保守性も下がるし、品質も下がる。 そしてこれら保守の特徴は、開発期間が短く見積もり工数が小さいことだ。 2週間とか1ヶ月で
ソフトウェアプロダクトラインと構成管理、ソフトウェアパターンの関係 - プログラマの思索
ソフトウェアプロダクトライン(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) 研究室｜株式会社エクスモーション 組込みシステム開発を現場から支援する「実践型トータ
チケット駆動開発にPSPの概念を持ち込む - プログラマの思索
小川 明彦, 阪井 誠 : チケット駆動開発 日本のソフトウェア開発の現場で生み出された「チケット駆動開発」という概念を、数多くの実例を元にモデル化・体系化を試みた最初の本。 小川 明彦, 阪井 誠 : Redmineによるタスクマネジメント実践技法 Redmineによるチケット駆動開発の実践技法に関する最初の本。アジャイルなソフトウェア開発への適用方法、TestLinkによるテスト管理手法についても言及。 清水 吉男: 「派生開発」を成功させるプロセス改善の技術と極意 組込システム開発をベースとして、ソフトウェア開発特有のスタイルである派生開発、特にXDDPについて解説した世界でも稀な本。既存製品を保守するのではなく継続的に機能追加していく昨今の開発では、派生開発特有の問題を意識しなければならない。XDDPはプロセス論だけでなく、要件定義などの上流工程の品質改善にも役立つので注意。 Le
繰り返し開発の罠 - プログラマの思索
萩本さんがアジャイル開発と反復開発について記事を書かれていたのでメモ。 #以下はあくまでもメモ書きです。 【元ネタ】 アジャイル開発と反復開発の落とし穴 － ＠IT自分戦略研究所 「現状のソフトウェア開発は間違っていないか？」（プロセス編） － ＠IT自分戦略研究所 裏プロセスは並行プロセス: プログラマの思索 「塹壕よりScrumとXP」 TiDDを実践して気付いたことpart3～繰り返し開発の戦略: プログラマの思索 Mercurialによるチケット駆動開発は強力だ！: プログラマの思索 「反復開発は、管理重視型開発」「アジャイル開発は、価値重視型開発」と書かれていて、なるほどと参考になったのと同時に違和感があった。 確かにその傾向はあるけれど、本質はそこだけでは無い気がする。 RUPのような反復開発は、アーキテクチャや品質を作り込むためにプロセスを反復する。 しかし、1回の反復だけで
何故チケット駆動開発はタスクやイテレーションの変更に強いのか？ - プログラマの思索
Redmine.JP | Redmine on Twitterを見ていて、下記の質問は、「何故、チケット駆動開発はアジャイル開発に使えるのか？」「何故、チケット駆動開発はタスクやイテレーションの変更に強いのか？」を示唆するヒントだと直感した。 考えた事をメモ。 #下記はあくまでも一つの参考意見。 【元ネタ】 Twitter / EG: Redmineとかtracとかで「ちょっと気になって ... Redmineとかtracとかで「ちょっと気になってること→対応すべきこと」というレベルアップや「○○バグの修正」と「ソースの全般的な修正」のような規模の違うものをどう扱うのがいいのだろう 上記の質問に対する回答としては、二つあると思う。 一つ目は、タスクの内容に応じてワークフロー(トラッカー)を変えて管理する。 チケット駆動開発の基本ルールは「チケットファースト」。 プロジェクト内部の作業はチケ
ファンクションポイント法による工数見積もりのリンク - プログラマの思索
ファンクションポイント法による工数見積もりをWeb上で検索した結果をリンクしておく。 後で自分で参考にしておきたいから。 【元ネタ】 デブサミ2009「私のコスト見積り20年史から～ファンクションポイントと共に～」講演メモ - アークウェブシステム開発SandBox ファンクションポイント法入門 「やることリスト」に基づく見積もり手法 ファンクションポイント系見積りのメモ - asa nisi masa ファンクションポイント法によるソフトウェア開発規模・工数見積の現状 ファンクションポイント法の利点は、ソース行数ではなくシステムの入出力に着目して工数見積する点にある。 このやり方ならば、ユーザも納得しやすく、プログラミング言語や開発者個人に依存せずに見積もりを提示できる。 しかし、ファンクションポイント法は昔から知られているにも関わらず、計算方法が複雑で、過去の蓄積データがないと精度が悪
メトリクスでソフトウェア品質を見える化する - プログラマの思索
「現場で使えるソフトウェアテスト Java編」を読んで内容がとても素晴らしいのでメモ。 【1】「現場で使えるソフトウェアテスト Java編」の対象読者は、Java開発者。 内容は、Eclipseの下記のテスト用プラグインで、Javaプログラムのテストや品質を解説している。 【本書で解説するEclipseプラグイン】 ・Checkstyle → コーディング規約チェック ・FindBugs → バグパターン検出 ・JUnit → 単体テストの作成/実行 ・TPTP → プロファイリング(非機能テスト) ・djUnit → カバレッジ計測 ・StepCounter → ソースコード行数測定 上記のプラグインのうち、全てを使いこなしている開発者はどれくらいいるのだろうか？ 僕は、Checkstyle・FindBugs・JUnit・djUnitは使った事があるが、TPTPやStepCounterは
コードレビューは緩いペアプログラミング - プログラマの思索
記事は古いけど、気付いたことをメモ。 【元ネタ】 【ITpro Challenge!】「高い生産性を実現する『ハッカーのソフトウエアエンジニアリング』とは」---Google 鵜飼文敏氏：ITpro (前略) 開発もなるべく小さな単位で行う。「設計しつつ実装，こまめにマイルストーンを設定する。小さい単位で動くものを作る。作る順序は後で使うものから。テストしやすさ，デバッグしやすさのために重要」（鵜飼氏）。 既にあるコードを利用して，新たに作らないことも重要だ。「何を作らなくていいか，利用できるか，把握する。持ち駒が多ければ多いほどいい」（鵜飼氏）。 Googleに入って感じたのはコードレビューの有用性だという。「コードレビューはとてもいい。ゆるいペアプログラミングのようなものでお互いのコードをチェックできる。ペアプログラミングは時間が拘束されるが，コードレビューならいつでもどこでもできる」
特徴(Feature)、粗筋(Story)、脚本(Scenario)とチケットの関係 - プログラマの思索
ユースケースとストーリーカードの関係、特徴(Feature)、粗筋(Story)、脚本(Scenario)とチケットの関係についてメモ。 【1】「システム要求、システム要件をどのように書くか？」はどのSW開発手法でもバラバラ。 オブジェクト指向分析(OOA)なら、ユースケース記述書のフォーマットに従って、システム要件や要求、フローを書いて、そこからモデリングしていく。 ユースケース記述書の書き方で一番優れていると思うのは、コーバーン著の「ユースケース実践ガイド―効果的なユースケースの書き方」。 ユースケースの書き方、観点のノウハウが詰まっている。 特に、ユースケースの観点を、アイコン(雲・凧・海水面・魚・貝)で表示して区別するのを推奨しているのは要注意。 ユースケース記述書のサンプルは下記を参考。 ユースケースについて システムユースケース記述 [C02あんしん電話（高齢者] ユースケース
TiDDを実践して気付いたことpart6～TiDDでAgile開発を実践して分かってきたこと - プログラマの思索
Redmineによるチケット駆動開発(TiDD)を実践して気付いたことをもう一度まとめてみる。 TiDDをAgile開発として運用するには、下記の運用ルールが最低限必要だと思う。 １・チケットをXPのタスクカードのように扱う ２・チケット集計結果をXPのタスクボードのように扱う ３・ロードマップをリリース計画のように扱い、小規模リリースを運用する １によって、XPのタスクカードをTiDD上で実現できる。 更に、XPのストーリーカード、ScrumのバックログもBTSチケットで表現可能だから、Agile開発のタスクや要望は全て、TiDD上で実現できるはず。 また、チケットに構成管理情報を付与できるから、成果物の変更もチケットで追跡できる。 ２によって、PFのかんばんをTiDD上で表現できる。 つまり、タスクの作業状態、イテレーションの進捗管理は全て、TiDD上でリアルタイムにモニタリングできる
TiDDを実践して気づいたことpart5～チケット管理システムとは - プログラマの思索
もう3年前の記事になるけど、参考になったのでメモ。 【元ネタ】 wikiとmantisを構築 業務をより効率的に - masahirorの気まま記録簿 Mantisは、BTSだけならばとても優秀なBTSだと思う。 しかし、Wikiが無く、SVNリポジトリと連携できない。 ＃但し、フックスクリプトを作ればSCMと連携可能だし、パッチを当てればWiki機能を追加できる。 RedmineやTracが従来のBTSと異なる特徴や利点は何なのか？ それを明確にできれば、チケット駆動開発(TiDD)が一体何をもたらしているのか、チケット駆動開発の何が画期的なのか、が分かるだろう。 BTSは単なるバグ追跡システムで、基本機能は、Web上でバグを障害報告票で追跡すること。 障害報告票をExcelからWeb化することによって、バグ修正と検証の作業がとてもスムーズになる。 更に、このワークフローがとてもスムーズ
TracのscrumプラグインAgilo: プログラマの思索
小川 明彦, 阪井 誠 : チケット駆動開発 日本のソフトウェア開発の現場で生み出された「チケット駆動開発」という概念を、数多くの実例を元にモデル化・体系化を試みた最初の本。 小川 明彦, 阪井 誠 : Redmineによるタスクマネジメント実践技法 Redmineによるチケット駆動開発の実践技法に関する最初の本。アジャイルなソフトウェア開発への適用方法、TestLinkによるテスト管理手法についても言及。 清水 吉男: 「派生開発」を成功させるプロセス改善の技術と極意 組込システム開発をベースとして、ソフトウェア開発特有のスタイルである派生開発、特にXDDPについて解説した世界でも稀な本。既存製品を保守するのではなく継続的に機能追加していく昨今の開発では、派生開発特有の問題を意識しなければならない。XDDPはプロセス論だけでなく、要件定義などの上流工程の品質改善にも役立つので注意。 Le
TiDDを実践して気づいたことpart2～これがアジャイルだ！と気付いた瞬間 - プログラマの思索
TiDD(チケット駆動開発)が何故、アジャイル開発と密接に関係するのか、経験を思い出して考えてみたことをメモ。 ＃下記はロジカルでないので注意。 【元ネタ】 裏プロセスは並行プロセス: プログラマの思索 チケット駆動開発のモチーフ: プログラマの思索 チケット駆動開発のFAQ: プログラマの思索 【再考】TiDDのプラクティス集: プログラマの思索 ツールが開発プロセスを改善する: プログラマの思索 【1】Redmineでチケット駆動開発を実践して、これがアジャイルだ！と気付いた瞬間は、イテレーションと言うリズムに気付いた時だ。 Redmineのロードマップ画面で、バージョン毎にチケットをアサインした後、バージョンの進捗率が100％になり次第、随時リリースしていった。 すると、開発メンバーはリリース予定のバージョンを直近のゴールと見なして、自然に頑張るようになった。 そして、リリース後にK
チケット駆動開発のアンチパターン - プログラマの思索
チケット駆動開発のFAQ、プラクティス集以外にも、アンチパターンを考えてみた。 以下メモ書き。 【元ネタ】 チケット駆動開発のFAQ: プログラマの思索 【再考】TiDDのプラクティス集: プログラマの思索 【1】チケットのアンチパターン 【1-1】乱発されたチケット よくある最悪なパターンは下記2ケースがあるだろう。 設計、開発、単体テストまでは穏便なものの、結合テストで火を噴き、たくさんのバグ報告があがる。 あるいは、リリース直後には、たくさんの障害報告や問合せが殺到する。 そのままチケットに登録すると、チケットが乱発される。 そして、それらのチケットを精査する工数が開発チームの許容量を超えると、チケットは放置される。 こういう状況はもはや、アジャイルだろうがTiDDだろうがCMMIだろうが、手に負える状況ではない。 【1-2】有効期限切れのチケット・放置されたチケット 終了予定日を過
TiDDとWFとScrumとLeanの違い - プログラマの思索
開発プロセスの違いについて良い記事があったのでメモ。 【元ネタ】 [Agile]WFとScrumとリーンの違い | Ryuzee.com WFの弱点は「計画に依存しすぎているので、計画が間違っていたらリスクが高い」「プロジェクトの終了直前のデプロイまで、何の価値も実現できない」点にある。 実際の現場では、結合テストで火を噴いてビッグバン統合に失敗する症状に全てが言い尽くされていると思う。 このWFを繰り返し型開発へ変形した場合、確かにリスクは減るが、最大の弱点は「ボトルネックが発生してしまい、それを制御できない」点にある。 全ての作業の遅れが積もり積もって、バッファを食い潰すのだ。 TOCのクリティカルチェーンの話を思い起こさせる。 Scrumではイテレーション単位に、Plan・Build・Test・Reviewが並行で動き、リリース前にReviewとDeployが行われる。 つまり、実装
ITILのプロセス関連図 - プログラマの思索
とある勉強会で、クレーム処理でITILの話が出てきたので、整理するためにメモ。 下記のプロセス関連図でITILは全て説明できる。 ITIL：Information Technology Infrastructure Library - Wikipedia ITILのプロセスは、PDCAサイクルで覚えればいい。 但し、起点がPlanの変更管理とCheckのインシデント管理の2パターンがある。 RFC(変更要求)が来た場合、変更管理プロセスで、要求を実現するための計画を作る。 つまり、CAB(変更諮問委員会)がステークホルダーを集めて、例えば、実装方法やリリース作業、そしてレビューやテスト方法、評価などの方針を議論して、決定する。 次に、変更管理で作られた計画に従ってリリース管理で、作業者が対応を行う。 実際は、ソースを修正してテストして、リリースする。 他方、顧客からクレームが来た場合、サポ
チケット駆動開発の運用例part3 - プログラマの思索
チケット駆動開発の運用例を見つけたのでメモ。 【元ネタ1】 [tech]チケット駆動開発 - Kazumi007の日記 特徴は下記の通り。 ・開発環境は、CVS＋Jira。 ・タスクはチケットを切り、CVSコミット時は必ずチケットNoを入力する。 ・Jiraの柔軟なワークフロー管理機能を使って、SW開発全体のタスクを管理する。 ・Jiraのチケットのサブタスク機能(1レベル下のサブタスクを登録可能)を使い、親チケットはストーリーカード、子チケットはタスクカードのように運用する。 TiDDで良かった点で、「情報がJIRAに集まるため、ますますJIRAに情報が集まるようになった。」という感想が素晴らしい。 インターネットでは、情報をたくさん出すページに情報がどんどん集まる。 JiraがSW開発の情報収集・出力のハブになっている良い運用例。 「ゴールの見えないチケット」「有効期限切れのチケット」
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
プログラミング言語の進化はベストプラクティスをサポートするためにある - プログラマの思索