フィーチャで考えると見えてなかったものが見えてくる - masayang's diary
その１ 最近Agileに切り替えたとあるプロジェクトのリーダーは、こんな事を語ってくれた。 以前は進捗会議の話題が「納期」や「予算」に話が偏る傾向があった。 切替後は、開発されたフィーチャやこれから着手するフィーチャについて議論されるようになった。 →いかに中身を見ないでお金や納期の話をしていたか、ということが浮き彫りになった。 その２ Agile採用を検討しているプロジェクトのリーダー曰く： フィーチャで考えるのは難しい。 ユーザがどんなフィーチャを欲しがっているのか、意外にわかってない。 →フィーチャで考えるという事は、受入れテストの必要条件を考えているのに等しい。そこを曖昧にしたまま包括的に記述してしまう従来型の要求定義だと、受入れテスト〜納品の段階で非常にややこしいことになる。フィーチャで考えるのは大変だが、プロジェクト最終段階でのゴタゴタを前取りしていると思った方が良い。
開発マイルストーン
プロジェクト開発などのスケジュール管理をExcelで簡単かつグラフィカルに作成するマイルストーンは一つの指標です。 プロジェクトでは、達成したい目標へ向かってまずステップごとに段階を分け、計画を立てて実施します。 その結果の検証をして、これをもって修正された新たな計画を立て再び実施を行います。 このようなサイクルでプロジェクトを進めていく上で重要な指標がマイルストーンです。 ツール「開発マイルストーン」は、システム開発などで必要なプロジェクト管理をサポートするためのツールです。 MicrosoftExcelを使用して、簡単に入力でき、かつグラフィカルに表現することができます。 無料で使える工程管理ソフト 「開発マイルストーン」は、MicrosoftExcelが利用できる環境であればどなたでも利用できます。 また、本機能以外にもExcelに備わっている豊富な機
裏プロセスは並行プロセス - プログラマの思索
萩本さんの記事を読んだ感想をメモ。 【元ネタ】 「現状のソフトウェア開発は間違っていないか？」（プロセス編） － ＠IT自分戦略研究所 【1】大規模プロジェクトほど、WF(ウォーターフォール型プロセス)になりやすい。 膨大で複雑な仕様を開発するには、工程ごとに仕様の大枠を決めて、後戻りしないように確定しないと、開発速度は上がらない。 しかし、SW開発には、仕様変更が付き物。 更に、バージョンアップしながらユーザビリティを上げていく戦略が多い。 だから、WFでは、手戻り作業ばかりやって、結合テストで火を噴くパターンが多い。 大規模プロジェクトで一番嫌なのは、イテレーションと言う概念が無いこと。 WFはリリースが最後の１回だけ。 最後にリリースするまで、どう動くのか分からない。 イテレーションと言う開発のリズムが無いから、最後にリリースするまで、延々と残業や休日出勤が続く。 そしてリリース後も
アジャイルごっこ - プログラマの思索
「アジャイルな見積りと計画づくり ~価値あるソフトウェアを育てる概念と技法~」で指摘した「アジャイルごっこ」についてメモ書き。 【元ネタ】 続・書評『アジャイルな見積りと計画づくり』 - TECH-moratorium ： テクモラトリアム DeclineAndFallOfAgile - アジャイルの衰退と凋落 【1】「アジャイルな見積りと計画づくり ~価値あるソフトウェアを育てる概念と技法~」の訳者あとがきに、こんな一節がある。 XPを代表とするアジャイル開発の技術的プラクティスは、開発現場の日々の作業を明らかに改善してくれる。 しかし、その効果はいずれ限界が来る。 結局、プロジェクトのスコープとスケジュールが固定されている状況では、最終的に開発者に様々なしわ寄せが来る。 このように、開発者だけがアジャイルなプラクティスを導入している状況を、木下さん(レビューワー)は「アジャイルごっこ」
ソフトウェア開発の不思議 - Fly me to the Luna
なぜよくあるソフトウェア開発ではきっちり要求を聞いて、かっちり仕様を決めて、その通りにカチカチに固めた開発をしようとするんだろう。 例えばなんですけど、僕がプラモデルをくみ上げるとき、最初から一つ一つきっちり部品を組むと必ず失敗していました。自分が不器用なことももちろんあるのだけれども、間違った部品をはめてしまって外すのに苦労した、なんて思い出ないですか？なのでそのうち最初は緩めに組んでおき、全体的に固まってきたらちゃんと組むという手順が効果的だと気づき、そうするようになりました。世の中ではこれを仮組みって呼ぶらしいです。 いや仮組みくらい、だれだってやってると思うんですよ。最初からうまく作ろうとしたってうまくいかないわけですから。 この「最初からうまく作ろうとしたってうまくいかない」という教訓はソフトウェア開発にも当てはまるって、いろんなプロセスで繰り返し語られているわけですけど、どうも
2009-02-04
Manage It! 現場開発者のための達人式プロジェクトマネジメント 作者: Johanna Rothman,でびあんぐる出版社/メーカー: オーム社発売日: 2008/10/18メディア: 単行本（ソフトカバー）購入: 15人 クリック: 145回この商品を含むブログ (50件) を見る 今日、Manage It!を読了したわけだけど、昨年邦訳が出版された瞬間に読んでおかないといけない本でしたね・・・この業界でPMなのってるやつはとりあえず読んどけ。自分が見てない、見えてないところはかなり書いてあるから。 この本がいっていることは「無理なものは無理」ってのと「信頼」だと思うんだよなぁ。 プロジェクト全体（開始から終了まで）をプロジェクトの最初に見通せるわけないじゃん。プロジェクトを進めていけばいろいろあるし、進めていった結果をより良いものが見えてくることもあるわけで、スポンサー（費用出
Project Proposal
Process impact: This proposal, along with drafts of related documents, will be used by management to determine whether or not to approve work on this project. A clear and precise project plan helps set expectations that will be used later to evaluate the success of the project. TODO: Replace the example text below with text that describes your project. What are the needs or problems that you are t
テーブル設計は実装の後に！：ベンチャー社長で技術者で：エンジニアライフ
株式会社ジーワンシステムの代表取締役。 新しいものを生み出して世の中をあっといわせたい。イノベーションってやつ起こせたらいいな。 「みんなが言ってる」は技術者が口にする言葉じゃないと書いてきました。 私が言ってることで、「みんな」とはおそらく真逆のことがあります。 それは「テーブル設計を（ユーザーインターフェイスの）実装の後に！」ということです。 「そんなことができるわけがない」とバカにされますが、そういう決め付けは思考停止ですよね？ ともかく、眉に唾塗っていただいてけっこうですので、続きを読んでください。 一般的なシステムにおいて、一番手戻りが大きい（波及する箇所が多い）仕様変更はテーブル変更を伴うものです。下手糞な設計で、他に悪影響を与えるのもテーブル設計です。 逆に、テーブル設計が美しく合理的にできていれば、他の工程は非常に楽になります。 では、仕様変更を防ぎ、美しく合理的なテーブル
ITの地殻変動はどこで起きているのか？～チケット駆動開発はなぜ生まれたのか - プログラマの思索
2009年になって、ITの地殻変動がどこに起こっているのか？を考えてみる。 ＃ラフなメモ書き。 【参考】 InfoQ: Martin Fowler氏が語る陥りがちなスクラムの落とし穴を避ける方法 InfoQ: 複数のアジャイルチームでのバージョン管理 チケット駆動開発 … ITpro Challenge のライトニングトーク (4) - まちゅダイアリー(2007-09-07) 【アジャイル開発の問題点】 1990年代後半から、サーバー＋クライアントの2層方式を基本とするVBアプリからMVCを基本とするWebシステムへのリエンジニアリングがあった。 更に、システムが大規模化して、開発期間が短くなるSW開発の現場。 RUPなど、イテレーティブな開発プロセスの重要性が叫ばれるものの、実際の現場で運用するにはハードルが高かった。 2000年頃出現したXPは、ソフトウェアの歴史の中で、オブジェクト
【公開】KOF2008講演資料「Redmineでチケット駆動開発を実践する～チケットに分割して統治せよ」 - プログラマの思索
関西Ruby会議01＠関西-KOF2008講演資料「Redmineでチケット駆動開発を実践する～チケットに分割して統治せよ」を公開します。 CC Attribution ライセンスとします。 【元ネタ】 チケット駆動開発 … ITpro Challenge のライトニングトーク (4) - まちゅダイアリー(2007-09-07) チケット駆動開発は、まちゅさんが最初に提唱された。 しかし、チケット駆動開発の概念はまだ曖昧で、一部でしか注目されていない。 僕は、Redmineというプロジェクト管理機能を持つBTSがプロジェクト管理をIT化してくれて、プロジェクト運営が大きく変わったことを経験した。 その体験をチケット駆動開発(Ticket Driven Development)という概念へ昇華できないか、考えた内容が上記の資料です。 コメントがあれば嬉しいです。 【参考】 Rubyist
ネットを介した多人数プロジェクトの限界
働く環境が様変わりしようとしている。オフィスだけでなく，サテライト・オフィス，出張先のホテル，移動中のカフェ，自宅へと広がっている。そのためにはオフィスの外からオフィス内のLANにVPNを張って，ファイル・サーバーや業務サーバーにアクセスできる仕掛けを作る必要がある。 多くの場合，社員と限られたパートナ企業の社員が入れるオフィスの中に限定していたイントラネットを，オフィスの外に限定的に拡大したネットワークを構築しているに過ぎない。複数の会社をまたいだプロジェクトが増える中，多くのプロジェクト関係者がアクセスできるプロジェクト専用のネットワークが望まれている。 プロジェクトが発足すると，プロジェクトごとにネットワークが誕生する。プロジェクト従事者は随時出たり入ったりでき，最後にプロジェクトの終了とともに，そのネットワークは消滅する。そのような柔軟な“プロジェクト・ネットワーク”が求められてい
アジャイル開発の恩恵とは - builder by ZDNet Japan
私は最近、IBMのRationalソフトウェアのアジャイル開発プラクティスリーダーであるScott Ambler氏に、アジャイル開発手法の利点について話を聞いた。 Ambler氏は、アジャイル開発がいくつかの従来の手法よりもなぜ優れているのかを説明してくれた。また、同氏はアジャイル開発に関する伝説を打ち砕いてくれ、いくつかの方法論について議論し、アジャイル開発へのスムーズな移行を行うためのアドバイスをくれた。 --アジャイルがいくつかの従来の手法よりも優れているのはなぜだと考えていますか。 アジャイル開発の主な恩恵は、品質、規律、ビジネス上の利害関係者と密に連絡を取りながら作業を進められること、定期的に機能するソフトウェアを提供できることなどに焦点を当てられることです。これは、単にわれわれが現実世界からベストプラクティスを取り入れたものであり、われわれは積極的にものごとを改善しようとしてい
DeclineAndFallOfAgile - アジャイルの衰退と凋落
DeclineAndFallOfAgile - アジャイルの衰退と凋落 目次 この文書について アジャイルの衰退と凋落 最近の状況 Scrum の役割 Scrum の誤用 君のやりかたは間違っている 真っ最中での失敗 アジャイルの衰退と凋落 この文書について "The Decline and Fall of Agile" の日本語訳です http://jamesshore.com/Blog/The-Decline-and-Fall-of-Agile.html 推敲歓迎: 誤訳, タイポ, 訳語の不統一, そのほか... James Shore アジャイル運動の衰退や凋落について話すのはおかしなことだ. 今やとても人気があるものなのだから. けれど本当のところ, ここ数年のアジャイル運動は、衰退の途にあると私は思う. 最近の状況 自分の商売がここ数年で変化していることに私は気がついた.
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Best Open Source To-Do Lists Software 2024
プロジェクトの進め方と各フェーズでの成果物についてまとめ
さらに分かっておきたいトランジスタの種類 − ＠IT MONOist