監訳者まえがき
「アジャイルソフトウェア開発の概要はわかったので、具体的な事例を知りたい」 アジャイル開発をテーマにした講演や研修に出かけていくと、この質問によく出会います。さまざまな立場の人たちと長らくこの問答を続けることで、わかってきたことがあります。それは、ひとくちに「事例」といっても、質問者が知りたいことは「プロジェクト実績」や「実際に起こった個々の出来事」に留まらないということです。この問いに込められている、質問者が本当に知りたいことを私なりに書き下せば次のような感じです。 日々のソフトウェア開発の現場で、 実際に起きる個々の出来事について、 アジャイル開発の知識を踏まえたうえで、 自分は都度、どのような意思決定を下していけばよいのか？ この質問の核心は「未体験のことへの不安」だと私は捉えています。リーン原則は開発プロセスについてのメンタルモデルであり、カンバンはワークフローの設計ツールです。ス
[#agile] 「リーン開発の現場」を読んで その１ - 引き取り的な仕組み - - ソフトウェアさかば
今年度上半期のイチオシの本は、スクラムの歴史を含めてわかり易く解説した「アジャイル開発とスクラム」と現場のイメージをわかせてくれた「SCRUM BOOT CAMP THE BOOK」でした。下半期のイチオシの本はその２冊の特徴を併せ持つ「 リーン開発の現場」でしょう。 リーンのムダのなさ リーンとは「ムダのない」という意味です。リーンのルーツであるTPS（トヨタ生産方式）では、当時の大量生産との対比からジャスト・イン・タイムと呼ばれていました。 ジャスト・イン・タイムとは、今風に言うとオンデマンドと呼んでも良いかもしれません。必要なものを必要な分だけ開発し、ムダな在庫を減らす事でムダな工賃や倉庫が不要になります。 （このムダをソフトウェア開発で言うならば、ユーザビリティや性能、技術的な課題を確認せずに横展開してしまって生じる、大量の手戻りをイメージすると良いでしょう）。 TPSでそれを実現
![[#agile] 「リーン開発の現場」を読んで その１ - 引き取り的な仕組み - - ソフトウェアさかば](https://cdn-ak-scissors.b.st-hatena.com/image/square/cb3189f8cb55f68fc5c2b0270b2e8657e0d2eb43/height=288;version=1;width=512/http%3A%2F%2Fsakaba.cocolog-nifty.com%2F.shared-cocolog%2Fnifty_managed%2Fimages%2Fweb%2Fogp%2Fdefault.png)
「リーン開発の現場」はアジャイルサムライの再来となるか - プログラマの思索
ヘンリック著「リーン開発の現場 カンバンによる大規模プロジェクトの運営」の翻訳がついに出版されました。 藤原さん、市谷さん、お疲れ様でした。 ざっくり読み直した感想をラフなメモ書き。 ネタバレを含んでいるので、読んでない人は注意。 【1】内容はとても読みやすいです。 スウェーデンの公共システムという大規模プロジェクトに対し、アジャイル開発を適用した事例のお話。 カンバンを使って、アジャイル開発を補強している。 内容がとても実践的なので、何となくアジャイルサムライの本を予感させる。 「リーン開発の現場」のカンバンは、XPやスクラムで出てくるタスクボードとは違う。 「リーン開発の現場」のカンバンは、機能ボード、フィーチャかんばんだ。 (但し、タスクボードに相当するタスクかんばんも出てくる) つまり、開発者の作業(タスクカード)を管理するタスクボードではなく、ユーザ観点で機能(ストーリーカード)
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
