タグ

ソフトウェア開発に関するiori_oのブックマーク (5)

  • Amazon.co.jp: 新装版 リファクタリング―既存のコードを安全に改善する― (OBJECT TECHNOLOGY SERIES): Martin Fowler (著), 児玉公信 (翻訳), 友野晶夫 (翻訳), 平澤章 (翻訳), 梅澤真史 (翻訳): 本

    Amazon.co.jp: 新装版 リファクタリング―既存のコードを安全に改善する― (OBJECT TECHNOLOGY SERIES): Martin Fowler (著), 児玉公信 (翻訳), 友野晶夫 (翻訳), 平澤章 (翻訳), 梅澤真史 (翻訳): 本
    iori_o
    iori_o 2014/06/23
    ほうほう...(Kindle化リクエストを押しながら)
  • スクラムにおけるイベントと出席者

    みなさんこんにちは。@ryuzeeです。 スクラムにおけるイベントはスプリントプランニング、デイリースクラム、スプリントレビュー、スプリントレトロスペクティブの4つがあります(スプリント自体もイベントですが他のイベントの入れ物なので除外しました)。 また責任としてはプロダクトオーナー、スクラムマスター、開発者、そしてそれ以外のステークホルダーに分けられます。 誰がどのイベントに出席するべきなのかについて、マトリクス化された資料が存在しなかったので、作成してみました。なお、イベントではありませんが、プロダクトバックログリファインメントを参考までに入れました 以下補足です。 プロダクトオーナーのデイリースクラムへの出席出席しません。 デイリースクラムでやるべきことは開発者がスプリントゴールを達成できそうか確認し、必要なら再計画のきっかけにすることです。 開発者がスプリントゴールの達成にリスクが

    スクラムにおけるイベントと出席者
  • スタートアップにおけるソフトウェア開発の無駄をなくす大事な3つの考えかた | Social Change!

    資金も人も少ないスタートアップが大手企業に勝つためには、大手と同じことをしていては勝つことができません。大手にできないことをしてこそスタートアップは生き残ることが出来るはずです。もし仮に投資を受けて大手のような振る舞いをしたところで、そもそも基礎的な体力は違う訳で息切れしてしまうことは目に見えています。 大手企業とスタートアップの大きな違いは、大手企業は資金や人を沢山もちすぎているということです。それは正面から戦ったら強みになるでしょうが、新規事業においては弱点にもなりえるのです。 沢山の人や資金を動かすとしたら、必ず無駄が産まれます。長過ぎる会議や総花的な意見まとめなど大企業のオペレーションには多くの無駄があります。小さくて小回りの利くスタートアップが同じように振る舞う必要はありません。 ITを活用するスタートアップにおいて、ソフトウェアを作るという文脈の中でも、大手企業とは違う戦略を採

    スタートアップにおけるソフトウェア開発の無駄をなくす大事な3つの考えかた | Social Change!
    iori_o
    iori_o 2012/07/10
    "「単位を小さくすること」"これが下手なとこが多い気がする。あと、解決したい問題は既に解決されてることが多いので、調べると作らなくていいことがわかったりする。
  • - eXtreme Programmingの魅力を探る

    (株) 永和システムマネジメント 平鍋 健児   Kenji HIRANABE 作成日:第4版 2001,8/10 第3版 2001,1/16 第2版 2000,10/21 初版 2000,10/10 エクストリームプログラミングは,Smalltalker として有名な Kent Beckらによって 提唱されているソフトウェア開発プロセス(開発工程)である. 正式にはエクストリームプログラミング(eXtreme Programming), 略してエックスピー(XP)と呼ばれる.この記事でも,以下 XP と呼ぶことにする. Kent Beck は,'99年に "Extream Programming Explained - Embrace Change" という書籍を著した.これは "EC " とも呼ばれ,XP のバイブルともなる. この記事では,この "EC" を基礎に XP

    iori_o
    iori_o 2012/06/28
    XPのスライドみたので、改めてここも読む。
  • ソフトウェア開発におけるムダ | Ryuzee.com

    みなさんこんにちは。@ryuzeeです。 Alan Shalloway氏のWastes of Software Developmentが良い記事でしたので、抜粋・意訳にてご紹介します。 僕のトレーニングではいつもトヨタ生産方式の話やStandishのレポートの話をしています。 7つのムダのうち特に作り過ぎのムダをなくすことはとても重要で(もちろんほかも重要)、これがないと頻繁に継続的に顧客に価値あるフィーチャーを届けることはできなくなるからです。 さらに開発のプロセスの中で、常にどこにムダがあるのかを考えて改善していくことはチームに課された責任でもあります。 例えば思いつく限り以下のようなものはムダです。 使わない機能たくさんのオプション設定読まない仕様書読まない報告書やたらと体裁にこだわった文書更新されない文書目的のない会議決定事項が守られない会議遅いPC小さいディスプレイ行動の監視目的

    ソフトウェア開発におけるムダ | Ryuzee.com
    iori_o
    iori_o 2012/06/19
    "問題の多くは、多くの作業をし過ぎていることに起因している。"
  • 1