おまえらｗｗｗｗいますぐリーン開発の現場 カンバンによる大規模プロジェクトの運営見てみろｗｗｗｗｗ – yutarofuji
リーン開発の現場 カンバンによる大規模プロジェクトという本を読んだ感想です。 開発を効率よく進めたいと思っているWebディレクターやプロジェクトマネージャーに読んで欲しい1冊 ご存知の通りWebシステムやソフトウェア開発を行う上でいくつかの開発モデル(生産方式)が存在し、中でもウォーターフォール・モデルという言葉は聞いたことがある人は多いのではないかと思います。 ウォーターフォール・モデルは歴史も長く、色々な現場で採用されて来ました。しかし、万能というわけにもいかず、近年の開発スタイルには合わない部分も多々出てきているようです。そういった実際の現場に携わる人や、現在の開発方法に限界を感じている人に是非読んで欲しい内容となっています。 実例を交えてストーリー仕立てでリーン開発を解説 リーンという概念は知っておいたほうが尚良い この本の特徴は、実際にリーン開発を採用した開発現場の様子がストーリ
トヨタ生産方式とエセトヨタ生産方式の違い
せみやしん @shin_semiya 上層部からの「次はアジャイルでやってよ」という声で始まる 上層部のアジャイルの理解は「早い、安い、うまい」という理解 「アジャイルだから設計できてなくてもいいんでしょう？」 「アジャイルだから仕様変更何回してもいいんでしょう？」 最後にお約束の「ただし納期と仕様はマストだから」 せみやしん @shin_semiya 基本的に形から入る。 イテレーションという短い単位で区切る。一週間単位が多い。 なぜ一週間なのか、とかそういう話はしない。 かんばんというものも取り入れる。 かんばんつくる目的って何？とか考えない。 新しいプラクティスを入れないところは今まで通りやる。 せみやしん @shin_semiya 例えばタスク管理はエクセルシートで行う。 それってほかの作業と食い合わせ悪くね？という話をするのは反逆である。 また、当初に決めた作業を基本的に最後まで
「Team GeekによるFearless Change」@デブサミ2014 2日目を聞いた - tchikuba's blog
さぁ、デブサミ2014も2日目に入りました！ 今日はどっぷり丸1日いろんなセッションに参加予定です。 が、外はまさかの2週連続の大雪という。。 残念ですが今後のセッションも楽しみにしているので是非継続してくれることを願いつつ。。 2日目の朝はサイバーエージェント藤田さんのセッションがあったんですが デブサミはやはりエンジニアよりの話をということで 「Team GeekによるFearless Change」というセッションを聞きました。 ほとんど本の宣伝的なセッションでしたがTeam Geek読んだことあって、素晴らしい本だったので聞いて良かったです。 導入 発表者：ワイクル株式会社 角征典さん twitter: @kdmsnr アジャイル開発を非エンジニアに理解してもらう為のワークショップをやってる 若干お金儲けの為というのも否めない エンジニアはアジャイル開発の為にお金使わないので エン
DojoとKataでRubyを学ぼう
Ruby on Railsでコードを書くにつれて、徐々に高い“Ruby力”が必要なことに気付くものです。では、どうやってRubyによるコーディング能力、“Ruby力”を磨けば良いでしょうか？ Ruby力の限界 Railsを始めてしばらくの間は、「どこまでがRailsのマジックで、どこまでがRubyのおかげなのか」に迷うことがあるかもしれません。Railsでコードを書くにつれて、だんだん自分のRuby力の限界を思い知らされるものです。 私もRailsを始めてから1年ぐらい経つまでは、Ruby力が足りないなと思うことがしばしばありました。でも、どうやってRubyのスキルを上げればいいのかが分かりませんでした。そんな頃、私が住んでいるロンドンから電車で1時間ほどのイギリス南部の町、ブライトン（Brighton）で「Coding Dojo」なるイベントがあると聞き、早速参加してみることにしました。
第1章 現代的プロトタイピングのすすめ～古くて新しい可視化手法（ブルックスからアジャイルまで） | gihyo.jp
運営元のロゴ Copyright © 2007-2024 All Rights Reserved by Gijutsu-Hyoron Co., Ltd. ページ内容の全部あるいは一部を無断で利用することを禁止します。個別にライセンスが設定されている記事等はそのライセンスに従います。
単体テストフレームワーク(xUnit)に関すること - 勘と経験と読経
このブログエントリの言いたいことがわかるようでわからなかったので、整理してみる記事。ドキュメントベースの単体テストとxUnitの類いの単体テストフレームワークの違いに関する私見。ツール(手段)の話ではなく、目的を中心に考えれば良いと思っている。 もし、ドキュメントベースの単体テストをそのまま踏襲したままで、xUnitを導入しようとするならば、もう一度テストの対象や目的を確認してください。xUnitは手段でしかありません。xUnitは小さなプログラムを動作確認するために作られたツールです。 ドキュメントベースの単体テストでxUnitを導入する前に考えて欲しいこと | DevelopersIO ドキュメントベースの単体テスト 例えばこんな「ドキュメントベースの単体テスト」が行われていて、いきなりxUnit類のツールを適用するとかなり混乱すると思われる。 割と「単体テスト」というものを実施するこ
Yahoo! JAPANにおけるアジャイル開発、スクラムへの取組み（後編）
先週の水曜日（10月19日）に、アジャイル開発手法のスクラムを学ぶイベント「Scrum Gathering Tokyo 2011」が都内で開催されました。 スクラムを実際に導入した事例として紹介されたのが「Yahoo! JAPANにおけるアジャイル開発、スクラムへの取組み ～組織と現場から～」のセッションで紹介されたヤフー株式会社の例。 組織としてスクラム導入にどう取り組んだかを紹介した前編に続き、後編では現場の取り組みが紹介されました（本記事は「Yahoo! JAPANにおけるアジャイル開発、スクラムへの取組み（前編）」の続きです。 スクラムの導入に現場はどう取り組んだか？ ヤフー株式会社 R&D統括本部フロントエンド開発1本部開発1部開発1 立木貴洋氏。 続いて、スクラムの導入について、現場でどう取り組んだか、という話です。私は2007年入社の5年目です。今回スクラムマスターを初めて担
Yahoo! JAPANにおけるアジャイル開発、スクラムへの取組み（前編）
先週の水曜日（10月19日）に、アジャイル開発手法「スクラム」を学ぶイベント「Scrum Gathering Tokyo 2011」が都内で開催されました。 スクラムを実際に導入した事例として紹介されたのが「Yahoo! JAPANにおけるアジャイル開発、スクラムへの取組み ～組織と現場から～」のセッションで紹介されたヤフー株式会社の例。 同社は2名の担当者が中心となり、社内セミナーなどでスクラムに興味を持ってもらうことで社内の自主的な変化を促す一方、評価制度や内部統制などの制度を調整する担当役も置くことで制度面での変化も後押しするなど、スクラム導入の具体的な手法が紹介されました。 そのセッションの内容を紹介しましょう。 2名で分担してアジャイル開発の推進を開始 ヤフー株式会社 R&D統括本部プラットフォーム開発本部本部長 志立正嗣氏。 組織の立場から見て、どういう風にスクラムを導入してき
アジャイル開発の現在・過去・未来
9月4日土曜日に、有志によるアジャイル開発のイベント「XP祭り2010」が早稲田大学西早稲田キャンパスで開催されました。イベントは200名以上の参加者が集まる盛況となり、アジャイル開発への注目の高さをうかがわせました。 基調講演では、「アジャイル開発の現在・過去・未来」というタイトルで、アジャイルの第一人者であるチェンジビジョン代表取締役社長の平鍋健児氏が登場。タイトル通り、アジャイル開発の全体と最新動向を俯瞰する、アジャイル開発のイベントでしか聞けない充実した内容となっています。 この記事では、その基調講演の内容を紹介しましょう。 なぜアジャイルが注目されるようになったのか なぜいまアジャイルが注目されるようになったのか？ 何かのビジネスを行う際には、企業が市場を分析して、企画を立て、IT関連のシステムを発注する、といったことが行われる。すると、ITが「仕様通りにできました」と納品してく
ユーザ受け入れテストでレガシーコードと戦っていく
レガシーコードとは、レガシーコード改善ガイドを参考にすると、テストのないコードを指しています。コードだけでなくレガシーなシステムも存在し、レガシーじゃないシステムよりレガシーシステムのほうが多いので、新しい要求への対応と、レガシーコードの改善をうまくやっていくスキルが求められるのではないかと思います。今日は、うまく戦っていく手段について考えてみました。 レガシーシステムでの問題 自動化されたテストのない現場にいたときに、以下の問題に直面しました。 レグレッションテストに時間がかかる 何をもって「ちゃんとテストした」のかがわからない 結果的に、リリース作業時間が長くなり、リリースにかけるコストが大きく膨れたり、テストを網羅しきれず、トラブルが継続的に発生してしまうというダメージを受けてしまいます。 1については、新しく追加した機能のテストはできても、追加した影響範囲まで特定できず、別の所で問
最近もらった本: アジャイルサムライ - steps to phantasien(2011-09-13)
いただきました. ありがとうございます. そして読んでいるうちに, どうも自分はアジャイルへの興味が失せていると気付いた. さいわい "アジャイルサムライ" は良く書かれており 感想はもうウェブ上にたくさんあるようなのでここでは保留し, かわりになぜ自分の関心が失せたのかを説明してみたいと思う. 理由はだいたい二つある気がする. ひとつはしょうもない理由: 私の参加しているプロジェクトはとても大きく, 独自の開発スタイルをもっている. したっぱの自分はそのやり方に口を出す気がなかなかおきない. 時差があり英語も苦手(これはほんと情けなくて泣ける)だからなおさら乗り気でない. 変える気がないものへの関心は薄れる. 二つ目はもう少しマシな理由. 件のプロジェクトはそこそこアジャイル風になっている. おおよそ time-boxed にリリースがあるし, 開発者の自動テストもある. リファクタリン
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
カンバン初心者のための『カンバン・キックスタート』
地図を捨ててコンパスを頼りに進め