ウォーターフォール型開発プロセスの有効性 - 勘と経験と読経
牛尾さんのブログで問題提起している「私はソフトウェアの専門家としてお答えすると、ウォータフォールは何のメリットも無いというのが私の意見である」という件について、自称ソフトウェア開発の専門家として考えたことを書いてみる記事。近しい各方面から意見を聞かれるので面倒なのでブログにまとめている側面もあるのだけれど。結論を先に書くと、計画駆動とアジャイルの扱いはバランスを重視。WFがメリットが無いというのは言いすぎだと思っている(課題はある)。 こちらも合わせて読んだ 日本でアジャイルが流行らない理由 - @ledsun blog 事業会社をIT会社に転生させることが、これからのSIerのミッション - GoTheDistance そもそも批判されるようなWF型プロジェクトは実在するのか 本件に限らず批判されがちな「ウォーターフォール型開発プロセス（以下WFと記述）」だが、実際のところ皆さんそれぞれ
「技術的負債だらけのチームで技術マネージメントしてみた」資料が素晴らしい - プログラマの思索
「技術的負債だらけのチームで技術マネージメントしてみた」の公開資料が素晴らしいのでリンクしておく。 【参考】 akipiiさんのツイート: "すごく良い資料。RT @yassan168: #kichijojipm 発表資料upしました。誰かの役にたてば良いのだけど。connpassにもUPしています。＞技術的負債だらけのチームで技術マネージメントしてみた https://t.co/3R25aUnI4S" 前任の仕事を引き継ぎしたら、下記の問題があったらしい。 技術的負債込みで引き継いでしまった、という例は、本当によくある。 (引用開始) １年前の状態 ・すべてがメールベース ・ドキュメントはほぼ無い ・最強の属人化。個人のパワーで乗り切る ・技術に関心が無く誰も行動しない ・暫定スクリプトが今も元気に本番稼働中 ・ソースには、ほぼコメント無し ・hoge.pl.(日付) 形式のソース管理
ブルックスの法則 - Wikipedia
ブルックスの法則（ブルックスのほうそく）は、「遅れているソフトウェアプロジェクトへの要員追加は、プロジェクトをさらに遅らせるだけである」という、ソフトウェア開発のプロジェクトマネジメントに関する法則である。 これは1975年にフレデリック・ブルックスによって出版された著書『人月の神話』[1]に登場した。 根拠[編集] ブルックスによれば、この法則が成り立つ主な理由は以下の通りである。 新たに投入された開発者が生産性の向上に貢献するまでには、時間がかかる ソフトウェアプロジェクトは、複雑な作業である。また、新たにプロジェクトに参加した人は、仕事に取りかかる前に、まず開発の現状や設計の詳細などを理解しなければならない。つまり、新たに人員を追加するには、その人員を教育するために、リソースを割かなければならないのである。したがって、人員の増加がチームの生産性に与える効果は、短期的にはマイナスになる
リーン・ソフトウェア開発と、アジャイルチームの先の話。組織のアジリティへ - kawaguti’s diary
４月にリーン・ソフトウェア開発の提唱者、メアリー・ポッペンディークさんと、パートナーでありソフトウェア技術者でもありプロ級の写真家でもあるトム・ポッペンディークさんの夫妻をお迎えして、(たぶん)日本初の有償研修をオーガナイズします(会社として)。 メアリー・ポッペンディーク「Leaders' Workshop (リーダーのためのワークショップ)」 4月9日〜10日 (同時通訳付き) 研修ハイライト => PDF リーン・ソフトウェア開発の「リーン」は、トヨタ自動車の生産方式を研究した北米の科学者がつけた名称です。リーンは贅肉(ムダ)が取れた状態をさすそうです。日本では工場における「ムダとり」の活動が有名です。メアリー・ポッペンディークさんは、トヨタ生産方式やその成立に大きな影響を及ぼしたデミング博士の手法を研究し、ソフトウェア開発の分野でそれを活かせるよう、３冊の本にまとめています。 リー
「アジャイルの現状と未来、次に来るもの。～リーン開発への展望～」Agile Japan 2010基調講演から
「アジャイルの現状と未来、次に来るもの。～リーン開発への展望～」Agile Japan 2010基調講演から アジャイル開発手法として知られるXPやスクラムは、国内で徐々に浸透し始めています。しかしアジャイルをさらに推し進めて企業レベルでアジャイルを活用したり、あるいは企業自身がビジネスをアジャイルに回すためにはどうすればよいのでしょうか。 4月9日と10日の2日間開催されたイベント「Agile Japan 2010」。2日目の基調講演に登壇したAlan Shalloway氏は「アジャイルの現状と未来、次に来るもの。〜リーン開発への展望〜」（What Is Next In the Agile World）と題し、企業をマネジメントする視点からのアジャイルについて講演を行いました。 Shalloway氏の講演は、アジャイルについてよく言われる「プロジェクトではうまくいくが、会社レベルで展開し
高速で無駄のないソフトウェア開発を実現するための7つのポイント | Social Change!
どうすれば小規模なチームでも大きな成果を出せるのか。大きな組織で沢山の量をこなすのは当たり前のことで、あまりクールではありません。少ない人数でも大きな成果を出すには、スピードをあげることと、そのためにも無駄をなくすことがポイントになってきます。 ソフトウェアをつくるための３つの役割で書いた通り、ソフトウェア開発をクラウドのようなサービス提供で続けていくには、プロダクトオーナーとプログラマーがキャッチボールのような形で、仕様と実装をずっと繰り返しながら作っていくのが自然です。 SonicGardenで使っているツールと開発の流れの全体は以下のようになります。大事なことは「動くソフトウェア」の状態を保ったまま、どれだけ回転数をあげていけるか、ということです。そのために、プロダクトオーナーとプログラマの間で待ち時間を減らすために並行して進めるようにするなど工夫しています。 ホワイトボードとMVP
リーン・ソフトウェア開発 (pdf)
トヨタ カンバン方式に学ぶ ITシステム開発・管理への適用と実践技法 山田正樹 / メタボリックス masaki@metabolics.co.jp 2004.09.03 2. リーン・ソフトウェア開発 1 Lean Software Development トヨタ生産方式に学んだソフトウェア 開発方法論 (プロセス) アジャイル・プロセスの一つ メアリー & トム・ポッペンディーク 航空機メーカや3Mなどでの経験を持 つ 2 %&'()*+"# 例えばGMは 1982年にGM-10プロジェクト開始 1989年にBuick Regalとして販売開始 ホンダ 1986年に同じマーケットを狙ってAccordプロジェクト開始 1989年に販売開始 ホンダは 1/2の技術作業量 1/3の開発時間 同程度以上の品質 3 !"#$ GM ホンダ シーケンシャルな 製品開発プロセス コンカレント エンジ
リーンソフトウェア開発の新刊が出ました。：An Agile Way：オルタナティブ・ブログ
Mary/Tom Poppendieck のリーンソフトウェア開発シリーズの第三作、 Leading Lean Software Development: The Results Are Not the Point の訳が、依田光江さん訳、智夫さん監訳で出ました！ 『リーンソフトウェア開発と組織改革』 ぼくは、第一作、第二作とお付き合いさせていただいているので、ぜひとも、と査読をさせていただきました。以下は、私の「推薦の言葉」（日本語版に寄せて）です。 もしあなたが、自分の会社のソフトウェア開発を革新したい、できれば会社組織全体を顧客価値の創造に向けて変革したい、と思っているなら、この本はあなたのための本だ。さらに、最近聞くようになった「アジャイル」という言葉に関心があるならばなおさらだ。本書には、アジャイル開発を組織の中でどう位置づけ、推進して組織を変革し、それを顧客と経営の価値につなげ
アジャイル開発/見積もり方法 - TOBY SOFT wiki
2020-06-02 Comments/Subversion/TortoiseSVNメモ/コミットしたログメッセージが編集できない 2020-03-31 ゲームを作る上でのバッドノウハウ/十字キーがボタンとして認識される 2019-11-12 Comments/Wiki/PukiWiki/スパム(spam)を防止する方法 2019-11-01 Delphi/XML/Delphi付属のXMLライブラリ 2019-08-27 Comments/SaGa2 秘宝伝説/モンスター一人クリア 2019-07-11 Comments/git/git rebaseを元に戻す方法 2019-06-08 VBA/関数呼び出し時に「オブジェクトが必要です。」というエラーが出る 2019-03-07 Comments/PhotoShop/「下のレイヤーとグループ化」はどこいったの？ 2019-02-06 Rub
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
