タグ

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

  • さくさく要件定義(リレーションシップ駆動要件分析RDRA)セミナーの感想 #RDRAセミナー - プログラマの思索

    さくさく要件定義(リレーションシップ駆動要件分析RDRA)セミナーに行ってきた。 要件定義の考え方がすごく参考になった。 感想をラフなメモ書き。 【元ネタ】 さくさく要件定義(リレーションシップ駆動要件分析RDRA)セミナー - アジャイルウェア | Doorkeeper 要件構造の見える化 #RDRAセミナー: ソフトウェアさかば リレーションシップ駆動要件分析による実践的な要件定義手法の記事のリンク: プログラマの思索 【1】要件定義の問題。 いつまで経っても、システムの全体像が見えない。 大量のドキュメントばかりで、肝心のシステムが説明されない。 分析と言う名の転記作業ばかりで、要件定義が完了しない。 では、どうすればいい? 要件定義、要件分析では、個人作業は非効率。 レビューと修正反映の繰返しでは、要件定義書の品質は上がらない。 その場で皆で合意を積み上げて進める方がいい。 ステー

    さくさく要件定義(リレーションシップ駆動要件分析RDRA)セミナーの感想 #RDRAセミナー - プログラマの思索
    holypp
    holypp 2015/01/29
    これはすごい
  • 期日が間近のRedmineチケットをメールで通知する - プログラマの思索

    期日が間近のRedmineチケットをメールで通知する方法が公開されていたのでメモ。 【元ネタ】 Twitter / iktakahiro: こんな簡単にできるんかい! | 期日が間近のチケットをメールで通知する(リマインダ機能) | Redmine.JP http://redmine.jp/faq/issue/send_reminders/ … 期日が間近のチケットをメールで通知する(リマインダ機能) | Redmine.JP 【1】チケットの期日がもうすぐなのにまだ完了していない場合、担当者に通知して、対処を促すようにする運用をしたい時がある。 その時、Redmineの場合、下記のコマンドが使えるらしい。 (引用開始) 【期日が3日以内に到来するチケットを通知】 ※例えば実行した日が5月27日であれば、期日が5月30日以前(30日も含む)に設定されているチケットの一覧を通知。 rake

    期日が間近のRedmineチケットをメールで通知する - プログラマの思索
    holypp
    holypp 2013/01/29
    これはよいですね
  • DOAとOOAの違い - プログラマの思索

    @hatsanhatさんにDOAの質問をしたら、とても参考になる回答をもらったので、僕の理解の範囲内でまとめてみる。 #間違いがあったら後で直す。 【参考】 モデラーとは:アーキテクト360 review 生産管理・原価管理システムのためのデータモデリング- Ynishi Bussiness Logs Domain Logic and SQL - Ynishi Bussiness Logs (1)リレーションシップはキーという「証拠」があるから引ける OOAでは、クラス同士の関連は簡単に引ける。 クラス同士の関連はビジネス上の制約から発生するけれども、それを表現するのは多重度ぐらいしかない。 コンポジションと集約の違いはOOAではあいまいに表現されやすい。 実際、クラス図で関連がコンポジションなのか制約なのか、を意図的に明示するモデラーは少ない。 また、関連クラスは分析モデルで表現されるだ

    DOAとOOAの違い - プログラマの思索
    holypp
    holypp 2012/12/10
    これみてUMLモデリングの本質買ってきた。
  • RedmineがVer2.0でRails3へ移行予定 - プログラマの思索

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

    RedmineがVer2.0でRails3へ移行予定 - プログラマの思索
    holypp
    holypp 2012/04/28
    「現状維持は後退」を彷彿とさせる。Ruby1.9やRails3に対応するという困難を乗り越えて、それでようやく現状維持なんだよね。対応しない(文字通りの現状維持)としたら、それは明らかな後退。何事もこういった感じ
  • 請負契約がソフトウェア開発者を苦しめている - プログラマの思索

    IT業界仕事していて、何故かデスマーチプロジェクトに数年に1回はぶち当たる。 デスマーチに陥る原因は技術力の不足やプロジェクト管理の能力不足などがあるけれども、IT業界で一般的な請負契約そのものに根原因があるような気がしている。 請負契約が日のソフトウェア開発者を苦しめているのではないかという仮説について考えたことをラフなメモ書き。 【元ネタ】 Twitter / @akipii: 日のソフトウェア開発者を苦しめている根源に請負契約があるという仮設を考えてる。平鍋さんや倉貫さんが試しているアジャイルな契約は請負契約のアンチテーゼと考えると分かる気がする。 Twitter / @akipii: @mr_amichan 請負契約の制約条件は開発者の想像以上にソフトウェア開発者に厳しいのです。請負契約である限り当のアジャイルな開発でないと体験してます。それをうまく説明したい。 Twit

    請負契約がソフトウェア開発者を苦しめている - プログラマの思索
    holypp
    holypp 2012/03/15
    こういう経験ないんだけど、多いのかな>現場には入ればいきなり内部設計や開発を任されて、その後のテストでバグ出ししていかないといけない。そして、テストが追われば、自分の首が切られることを知っている
  • チケット駆動開発が進むべき道part4~チケット駆動開発がもたらした新しい観点 #tidd - プログラマの思索

    チケット駆動開発が従来のどんな問題を解決して、どんな新しい観点をもたらしたのか、考えを整理してみる。 【元ネタ】 Twitter / @akipii: ツールの背後にあるチケット駆動開発の意義を汲み取って欲しい。RT @yusuke_kokubo 自分が管理してメンテナンスするならRedmineだけど自分が使う側だったらTracでもJIRAでもなんでもかまわない。ちゃんと使えれば Twitter / @akipii: #redmine ツールの背後にあるチケット駆動開発が従来のどんな問題を解決して、SW開発にどんな新しい観点を提示したのか?を汲み取って欲しいのです。 【1】SW開発の難しさは、結合テスト以降の障害管理ではっきり現れてくると思う。 WF型開発であれAgile開発であれ、ある程度動くモジュールに対して、機能を追加して品質を向上していくプロセスは、そう簡単なものではない。 そもそ

    チケット駆動開発が進むべき道part4~チケット駆動開発がもたらした新しい観点 #tidd - プログラマの思索
    holypp
    holypp 2011/08/24
    最近Redmineを使ってるっていうプロジェクトを良く聞く。個人的にはここまでやりたいんだけど、なかなか難しいね>「Tikect First」「No Ticket, No Work」「No Tikcet, No Commit」という運用ルール
  • MS Projectを使いこなせない理由 - プログラマの思索

    普通は、MS Projectをどれだけ使いこなしているか、でプロマネのスキルが分かる。 ラフなメモ書き。 【元ネタ】 MSプロジェクトは使いこなすな! - メイクミラクル ~大逆転~ タイム・コンサルタントの日誌から : Excelで工程表を書いてはいけない MS-Projectとかイナズマ線とか | kozawa のたまに気になること Microsoft Office : これならわかる!! Microsoft Office Project 2003 【MS Projectの代替ソフト】 プロジェクト管理の選び方と使い方&プロジェクト管理×15 at Cool Coding Microsoft Projectの代替ソフトウェアとしてプロジェクト管理が可能でガントチャート表示もできるフリーソフト「OpenProj」 - GIGAZINE 開発マイルストーン OpenProjを使ってみた:

    MS Projectを使いこなせない理由 - プログラマの思索
  • 複数のRuby環境構築はrvmかpik - プログラマの思索

    Ruby1.8.6と並列に、Ruby1.9やJRubyを使いたいと思う時がある。 複数のRuby環境構築の方法が分かったのでメモ。 【元ネタ】 pikで簡単、複数のRuby環境構築! ? 梨木を読む Ruby/Windows7で1.8と1.9環境を同居させる - 俺の基地 RVMで複数のRubyを使いこなす - Capsule RVMで複数のRubyを管理 Rubyの複数バージョンを共存させるgem。rvmとpikについて - holyppの日記 事の発端は、RedmineのXLS export pluginを入れたら、意味不明なエラーが出たこと。 gem install spreadsheet も設定したのに何故だろうと思ったら、Ruby1.8.6からv1.8.7へアップグレードすると解決した。 Redmine - XLS export plugin - Redmine とはいえ、Rub

    複数のRuby環境構築はrvmかpik - プログラマの思索
    holypp
    holypp 2011/04/13
    Rubyベストプラクティスを読むとrvmしたくなりますね。redmine入れるときに大変お世話になったblogなので、トラバに感激。
  • イテレーションはSW開発で何故重要なのか? - プログラマの思索

    バージョンのないRedmineプロジェクト~TiDD初心者が陥りやすい罠が思いのほか評価されていたので、理由を再考してみる。 以下、ラフなメモ書き。 【元ネタ】 アジャイルはなぜ失敗するのか?~教科書には載っていない反復型開発の3つの掟(1/4):企業のIT・経営・ビジネスをつなぐ情報サイト EnterpriseZine (EZ) バージョンのないRedmineプロジェクト~TiDD初心者が陥りやすい罠: プログラマの思索 チケット駆動開発の質はバージョン・ファースト: プログラマの思索 牛尾さんが書いているように、イテレーションはAgile開発で最も特徴的な概念だ。 その発想はすぐに理解できるが、実際に実践してみると、そんなに簡単に運用できるものではない。 何故、イテレーションを実際のSW開発に運用するのが難しいのだろうか? 僕の数少ない経験上、イテレーションを実際の開発プロセスに実装

    イテレーションはSW開発で何故重要なのか? - プログラマの思索
  • バージョンのないRedmineプロジェクト~TiDD初心者が陥りやすい罠 - プログラマの思索

    TiDD初心者が陥りやすいアンチパターンを実際に見つけたのでメモ。 【1】チケット駆動開発の概念に慣れておらず、Redmineタスク管理をまず始めた人に多い特徴がある。 それは、バージョンが設定されておらず、ロードマップが空っぽないし非表示な状態。 話を聞くと、Redmineのバージョンの意味や使い方が理解できないらしい。 だから、彼は、Redmineのチケット一覧画面でタスク管理を実施している。 彼のチケット一覧画面を見ると、スクロールできないくらい、たくさんのチケットが無造作に一覧表示されている。 どうやら、必要なタスクはチケットに登録しているが、彼のチケット管理を見ていると、チケットの納期が意識されていない。 そのチケットはいつリリースするのか?の観点が漏れているみたい。 何故なら、チケットがたくさんありすぎて、どのチケットが必要なのか、チケット一覧画面では分かりにくいからだ。 だ

    バージョンのないRedmineプロジェクト~TiDD初心者が陥りやすい罠 - プログラマの思索
    holypp
    holypp 2010/10/11
    これは嬉しい記事。Redmineのバージョンについて。>TiDD初心者が陥りやすいアンチパターンを実際に見つけたのでメモ
  • Agile開発の肝はイテレーションにあり - プログラマの思索

    Redmineでチケット駆動開発を運用するまで、Agile開発を体で理解できていなかった。 XPを実践したいと思っていても、当のAgile開発は何か違うのでは?と思っていた。 何故、僕はTracではなくRedmineを使ってAgile開発を発見できたのだろうか? RedmineがAgile開発と相性が良いのは、Redmineの「バージョン」の概念がAgile開発の「イテレーション」「スプリント」と自然に一致するからだ。 Redmineでは、バージョンに紐づくチケットが全て完了ステータスになって、進捗率が全て100%になれば、いつでもそのバージョンをリリースできる仕掛けが入っている。 つまり、バージョンをイテレーションと見なせば、各バージョンを次々にリリースしていけば、自然に小規模リリースを実現できる。 小規模リリースこそが漸進型開発、つまりインクリメンタル型開発の最大の特徴なのだ。 Ag

    Agile開発の肝はイテレーションにあり - プログラマの思索
    holypp
    holypp 2010/09/14
    「何故、僕はTracではなくRedmineを使ってAgile開発を発見できたのだろうか?」から、イテレーションの概念が腹に落ちているかどうかという話まで。うちのRedmineはまだVer0.9台だからそろそろ上げないと。
  • 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フレームワーク | エンタープライズ | マイ

    Webプログラミングは何故オブジェクト指向でない?~WicketはWebプログラミングにオブジェクト指向を取り戻す - プログラマの思索
  • 忘れ去られた日本のIT技術~DOAと品質管理 - プログラマの思索

    最近、上流工程のモデリング技術として、DOAを見直している。 その過程で、忘れ去られた日IT技術とその歴史があるように感じた。 考えたことをラフにメモ。 【DOA(Data Oriented Analysis)】 DOAはデータモデリングというモデリング技法、上流工程の設計技術の一つ。 DOAは日独自で発展してきた歴史がある。 椿正明さんのTHモデル。 佐藤正美さんのT字形ER。 渡辺幸三さんの渡辺式DOA。 THモデルは古くは1970年代から発展してきたようだ。 他のDOAも、日で、メインフレーム上の業務システムを開発する経験から育まれてきた。 歴史があるからこそ、DOAを知れば知るほどノウハウがある。 例えば、エンティティにはリソースとイベントの2種類がある。 イベントには必ずタイムスタンプ(日付)が振られて、業務の流れに従ってイベントが変わる。 リソースとイベントの個数を比較

    忘れ去られた日本のIT技術~DOAと品質管理 - プログラマの思索
    holypp
    holypp 2010/07/11
    今回の記事は含蓄が多い。OOAとUMLは日本人にはあわないのか、日本では質が低いのではないかと感じていて。GoFにしてもそう。それらが金のハンマーとは思わないが、知識としてはもう少し、必要だよね。
  • IPAが書いたアジャイル開発の研究会報告書 - プログラマの思索

    IPAが200頁にものぼるアジャイル開発の研究報告を公開していた。 IPAが公開している研究報告は、RubyRailsアジャイル開発などの昨今の話題を日IT業界のエスタブリッシュメントがどんな観点で見ているのか、を知る上で非常に参考になる。 運営委員に平鍋さんや羽生田さんがいて議論に加わっているのが興味深い。 気になる文言をメモ。 【元ネタ】 情報処理推進機構:ソフトウェアエンジニアリング 調査報告書[1.68MB] 研究会報告書[924KB] 成果概要資料[702KB] ・共通フレームについても、改めて見直してみたが、ウォーターフォールを標榜していると誤解されても仕方が無いなと感じた。ウォーターフォールを定義できる辞書を整備して、最後に、段階的や進化的プロセスも説明できるよという書き方になっている。要求定義が不十分であることが、リスクとして扱われている。アジャイルプロセスでは、こ

    IPAが書いたアジャイル開発の研究会報告書 - プログラマの思索
    holypp
    holypp 2010/04/07
    IPAから「redmine」という単語が出たということと、ソフトを一回で作ろる日本は効率が悪いというのが印象深い。
  • TestLinkのベストプラクティス集 - プログラマの思索

    TestLinkでテスト管理を運用してみて、ベストプラクティスを自分なりにまとめてみた。 あくまでも下記は僕が経験したこと、理解できたことに過ぎないので、間違っていたらコメント下さい。 【元ネタ】 脱Excel! TestLinkでアジャイルにテストをする - @IT自分戦略研究所 TestLinkのFAQ: プログラマの思索 テスト手法の概念をTestLinkで説明する: プログラマの思索 TestLinkを運用して気付いたことpart8~みなしバグ、ブロッキングバグ、周辺テスト、そしてクリティカルパス: プログラマの思索 TestLinkを運用して気付いたことpart9~後追いテスト: プログラマの思索 TestLinkを受入テストで運用する方法: プログラマの思索 【1】ブロック テストケースの事前条件が、失敗したテストケースに依存しているためにテスト不能になった状態を指す。 ブロッ

    TestLinkのベストプラクティス集 - プログラマの思索
    holypp
    holypp 2010/02/28
    みなしNG等の概念は大規模開発でもしっかり持っていきたいな。大規模になるほど目に見える「数字」が正義になってしまい見失うものも増える。
  • 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のプロジェクト管理は何故良くないのか - プログラマの思索
    holypp
    holypp 2010/02/09
     excel管理やめますか?定時帰りやめますか?
  • RedmineとTracの機能比較part2 - プログラマの思索

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

    RedmineとTracの機能比較part2 - プログラマの思索
    holypp
    holypp 2010/01/22
    最後の敵はMSProjectだ。
  • Redmineの最後の課題~チケットの親子関係 - プログラマの思索

    Redmine.JP BlogにあるRedmine0.9xの機能の解説が素晴らしい。 Redmine 0.9 新機能紹介(6): プロジェクトのコピー | Redmine.JP Blog プロジェクトのコピー機能を使いたい場面は、以前のプロジェクト設定をテンプレート化しておきたい時だ。 例えば、Ph1のプロジェクトが終わって、Ph2のプロジェクトを開始する時、前回のプロジェクト設定をそのまま使えると楽になる。 特に大規模プロジェクトでは、サブチームのタスク管理の構造は殆ど同一だろうから、テンプレートを引継ぎできると、すぐにタスク管理を始められる。 Redmine 0.9 新機能紹介(7): チケット一覧画面の改善 | Redmine.JP Blog チケットのグルーピングができるようになったのが良い。 これによって、ステータス単位でグルーピングすれば、PFのかんばんと同等の画面になる。 つ

    Redmineの最後の課題~チケットの親子関係 - プログラマの思索
    holypp
    holypp 2010/01/18
    これいれる。>チケットのステータスを変更すると、進捗率を自動で更新してくれる。
  • 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に入れたプラグイン一覧 - プログラマの思索
    holypp
    holypp 2010/01/14
    Tracと違ってredmineにはプラグインをいれていないので、後ほど吟味する。
  • 画面プロトタイプに対する違和感: プログラマの思索

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

    holypp
    holypp 2010/01/13
    作ってみないと本来の要件が分からない時が多い。 紙芝居を見せると、ユーザはデザインやレイアウトに目が向いて、本来の要件とは無関係の議論になりがち。 私はそうは思わない。ただ、顧客次第としか言えない。