アジャイルソフトウェア開発宣言 アジャイルソフトウェア開発宣言ではチームの 4 つの価値と 12 の原則が概説されていますが、これは 20 年近く経った今でも有効でしょうか? 詳細を見る スクラム スクラムでは、製品はスプリントと呼ばれる一定期間のイテレーションで作られます。スプリントは、定期的なリズムでソフトウェアを出荷するためのフレームワークをアジャイルチームに提供します。スクラムの手法が従来のプロジェクトマネジメントに与える影響について学びましょう。
私が初めてeXtreme Programming に出会ったのは確か2000年だと思う。実際に初めてのプロジェクトを実施したのが2001年。それからすでに15年が経過していることになる。そんな長い間アジャイル、そして DevOps の日本での導入に関わってきた。日本のアジャイル導入に関しては全て成功とは言わないが、かなり成果は上げてきたとは思う。だけと、今日は自分の導入ポリシーの誤りに気付いて、新たなステージにいける気がしたので、そのことを共有してみたい。 2002年 尊敬するアリスターコバーンと、XP JUG関西のメンバーと清水寺で。私が写真撮ってたのかなw Alistair.Cockburn.us | Alistair's first trip to Japan sept 2002 日本はアジャイルの導入がこれからという噂を聞いたけど本当? これは、私がマイクロソフトの面接の時に、当時
野中郁次郎先生を一橋大学に訪問、アジャイル、スクラム、創造、マネジメントについてディスカッションする機会を得ました。 先生はもちろん、ナレッジマネジメント、知識創造経営、そして、Scrumという言葉を生んだ、「The New New Product Development Game」という1986年の論文の著者の一人。もう一人は現在ハーバードの竹内さん。一昨年の AgileJapan 2010の基調講演、昨年は、Jeff Sutherland との対談が Innovation Sprint で実現、ハーバードの竹内さんのクラスにJeff Sutherland が呼ばれたりするなど、アジャイル会との交流が進んでいます。 ぼくが持ち込んだ、顧客を巻き込んだ、見える化された職場のワークスタイルの写真なんかを見ながらお話ししていたら、 PDCAって日本人大好きなんだけど、これは本当に欲しいもの、い
The document discusses the traditional "iron triangle" of project management consisting of scope, cost, and schedule. It then introduces the "agile iron triangle" which prioritizes value and adds quality and constraints. The agile approach recognizes that scope, cost, and schedule are constraints, not priorities. It emphasizes that XP (eXtreme Programming) is about enabling social change through t
池田尚史氏に聞くチーム開発の極意 ~「進め、現場のチーム開発 ~チーム開発実践入門」レポート 6月19日、DeNAヒカリエ本社の会議室にてDevLOVEのイベント「進め、現場のチーム開発 ~チーム開発実践入門~」が開催されました。本稿では『チーム開発実践入門』の著者である池田尚史氏(@ikeike443)の発表を中心にレポートします。 イベント開会の挨拶 ~DevLOVEとは DevLOVE主催者である市谷聡啓氏(@papanda)の挨拶をもってイベントが開催されました。DevLOVEは6年続けている開発者向けのコミュニティで今回は170回目の開催とのこと。 HangarFlight 飛行機乗りにとって、空がまだ未知で危険なものだった時代。格納庫に集まってお互いの体験を話し合い、空を知ろうとしました。DevLOVEはまさにそういう場にしようという思想のもと作ったイベントだそうです。デベロッ
KAIZEN platform Inc. は、新しい働き方をいろいろ試してみようという会社でそのひとつにリモートワークがある。リモートワークの良さあるいは良くないところについては、以前に Rebuild.fm の ep.32 でも話した。 ちかごろは、オンラインミーティングのための道具、情報共有のための道具もクラウドサービスがたくさんあるので、その辺を使って工夫すれば一昔前に比べてだいぶリモートワークも現実的になってきている。実際、KAIZEN には大阪からリモートワークしている人とか、最近リモートワークを前提に都内から鎌倉に引っ越したメンバーなんかもいる。 リモートワークとアジャイル開発 HipChat、Google Hangout や Qiita Team なんかを使うことで、日常の会話、ミーティングや情報共有についてはもともと特に困ったこともあまりなかった。特に Qiita Team
ソフトウェアの負債というのは様々なかたちで存在している。技術的負債は広く知られているし、他の形態としては能力的負債とか品質的負債というものがある。ソフトウェアの負債はプロダクトの維持管理コストを増やし、開発者の気持ちを落ち込ませうるものだ。ソフトウェアの負債を扱うためにはいくつかの解決法がある。 Niklas Björnerstedt氏はブログ記事「技術的負債のその他いろいろ」の中で「能力的負債」に触れている。彼はこう定義する。 自分たちのコードベースにあるものと、そのうち実際に自分たちが理解しているものとのギャップ。 ソフトウェア維持管理の手間を低く保つためには、技術的負債と能力的負債のどちらにも注意を払わなくてはならないと、Niklas氏は説明する。 努力しないでいると技術的負債が時間とともに容赦なく増えるのとまさに同じで、能力的負債もまた時間とともに増えていきます。2種類の負債の大き
インセプションデッキとは インセプションデッキとは、プロジェクトの全体像(目的、背景、優先順位、方向性等)を端的に伝えるためのドキュメントです。ThoughtWorks社のRobin Gibson氏によって考案され、その後、アジャイルサムライの著者 Jonathan Rasmusson氏 によって広く認知されるようになりました。 インセプションデッキについては、Jonathan氏のブログ「The Agile Inception Deck」にて説明を読むことができます。 Jonathan氏が作成したインセプションデッキのひな形 インセプションデッキ(Inception Deck)を直訳すると「最初のデッキ(カードの束)」という意味となり、アジャイルプロジェクトにおける「プロジェクト憲章」に近い意味合いを持ちます。 プロジェクト憲章とは PMBOKにおけるプロジェクト憲章(Project Ch
組織に新しいアイデアを持ち込みたいと考えた方がどのように周りを変えていったらいいか、一人称で、パターン形式でまとめられたのが「Fearless Change」です。 Lindaさんとアジャイルジャパン実行委員会の野口さんより承諾をいただき公開しました。快い即答、ありがとうございました。アジャイルジャパンにLindaさんを呼んでくれた、実行委員会のみなさんにも大変感謝しております。 講演内では序盤を中心に有効なパターンを紹介していますが、書籍内で紹介されているパターンはまだまだたくさんあります。概要説明部分を安井さんが翻訳してくれたので、読書会の宣伝を兼ねて資料を作りました => PDF。 Fearless Change: Patterns for Introducing New Ideas 作者: Mary Lynn Rising, Linda Manns出版社/メーカー: Addison
Agile Japan 2011 の基調講演のため、Linda Rising さんが来日予定です。基調講演は日本中のサテライト会場にも中継される予定です。 Linda さんは、企業組織の柔軟な変化について、コンサルティングやコーチングを行っています。その方法は、パターンランゲージを用いて、誰にでも実行可能な方法を記述していく、というアプローチです。コンピュータサイエンスのバックグラウンドを持ち、通信系の大企業で勤務した経歴をもっているせいか、その一人称の語り口、安易に切り捨てない包容力に驚かされます。 InfoQでのインタビュー (2008年) http://www.infoq.com/interviews/Linda-Rising-Fearless-Change "Fearless Change" という本は、彼女と、ビジネスマネジメント系のバックグラウンドを持つMary Lynn Ma
どうすれば小規模なチームでも大きな成果を出せるのか。大きな組織で沢山の量をこなすのは当たり前のことで、あまりクールではありません。少ない人数でも大きな成果を出すには、スピードをあげることと、そのためにも無駄をなくすことがポイントになってきます。 ソフトウェアをつくるための3つの役割で書いた通り、ソフトウェア開発をクラウドのようなサービス提供で続けていくには、プロダクトオーナーとプログラマーがキャッチボールのような形で、仕様と実装をずっと繰り返しながら作っていくのが自然です。 SonicGardenで使っているツールと開発の流れの全体は以下のようになります。大事なことは「動くソフトウェア」の状態を保ったまま、どれだけ回転数をあげていけるか、ということです。そのために、プロダクトオーナーとプログラマの間で待ち時間を減らすために並行して進めるようにするなど工夫しています。 ホワイトボードとMVP
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く