REDMINEは「タスクかんばんツール」へ進化を遂げた!! 「かんばん!」第3回連載に「Redmine Backlogs プラグイン」の紹介ページがあるが、そこに掲載された画像に、鳥肌が立った!! ■@IT 「スクラムやるならRedmineと...
これだけモデリング!というコンセプトで、山岸さんが話された5/28の要求開発定例が面白かったので紹介します(山岸さんはリーンモデリングとも呼んでいたがぼくはベタにこれだけモデリング、という日本語が好き)。 情報システム部門目線で見て、どんどん複雑になるアプリケーションの要求や設計を見通しよく「共通合意」を作るための、「軽い」モデリングの必要性が今回テーマです。そうなんです、従来は、「全部書かなきゃだめ」とか「全部メンテしないといけない」とか、「下流を触ったら上流までさかのぼって修正しなきゃ」とか足かせが多かったので、なかなかペイしなかったのですね。だから、「これだけ」モデリングを提案したい、という訳です。 (※6/5 追記: 以下に、当日の資料を公開します。) これだけモデリングとは、 誰が? ー 情報システム部門の人(と開発の人が共に) いつ? ー システム開発の前段階、すなわち「要求開
1.全体スケジュールにコミットできない アジャイルはタイムボックス型(一定期間で棚卸しをして、それを繰り返す)のマネジメントをする。だから、全体としての計画は立てられない。「だって、最初に全ての機能を洗い出せないでしょ」というのは分かる、分かるけど全体の計画は立てないといけない。経営者は顧客やVCと全体の計画にコミットしなきゃいけないんだ。そのときに「やってみなきゃ分からない」なんて言えるわけでない。 てか「やってみなきゃ分からない」なんてことは誰でも知っているんだよ。でもさ、それを言わぬが花。大人なんだからコミットメントをしないといけないんだよ。そして、その達成ためには、あらゆる手段を尽くすのです。 2.アーキテクチャ上の無駄が生じる ソフトウェアの構造や構成は工程が進むほどに修正しにくくなり、ずっと残る。だから、アーキテクチャ設計は慎重に全体を考えながらやらなきゃいけない。でも、アジャ
永和システムマネジメントさんで開催された「第108回 DevLOVE − Play! かんばんゲーム リベンジ」に参加してきました。DevLOVEに参加するのは2010年以来ではないか!@yattomさんの「かんばんゲーム」は、ずっとやってみたかったので夢が1つかないました。 かんばんゲームのルール はじめに言葉の定義としてタスクとかを貼りつける板を「かんばん」に統一。「TODO・DOING・DONE」や「設計・開発・テスト」といったそれぞれを「ステージ」と呼んでます。 このゲームをざっくり説明すると、実際に「かんばん」を使い、タスクを消化していくゲームです。さらに「Eventカード」や「Problemカード」や「Solutionカード」がゲームを盛り上げます。 タスクにはコスト(ストーリーポイント)が書かれているので、出したサイコロの目の数だけ減っていきます。今回は1テーブル5人で、メン
わけあって『リーン開発の本質』を再読しています。る。日本の中でアジャイル開発を、できるだけ管理者の言葉として伝えたかった本です。この本は本当にたくさんの人に読んでほしいなぁ。ここに、そのあとがき、として書いた文章を掲載します。 最後に書いた、 多くの間違った標準化が、「人は本来怠け者でありしっかり働かせるために規則を作らなければならない」とか「人は交換可能である」というメンタリティから発している。もし、組織の文化や方針の中心にこのような考え方があると、もしくは多くの管理者がこのように考えているならば、「決して」リーン活動は成功しない。そうではなく、「人の持つ工夫のモチベーションを活かす」こと、「一人ひとりの人を育てる」ことこそ、マネジメントの中心となるべきだ。「人」の要素はプロセスの中心である。ここをやり間違えてはならない。 日本のソフトウエア業界が、人の持つ知恵と力を大切にしながら、高品
日本のアジャイル10年、人々とコミュニティの私的物語 平鍋健児 (※)この記事は、2011年に書籍『Ultimate Agile Stories』に寄稿したものを転載しています。執筆時点で、『Ultimate Agile Stories - Iteration 2』が刊行されています。(2012/8/15) ぼくが初めてアジャイル、というか、XP、そうエクストリームプログラミングについて知ったのは、2000年の初めだった。ふと目について注文した洋書『Extreme Programming: Explained』がamazon.comから届き、それを週末に読んだのだ。このときに、どんな電流が走ったかは、多くの人の前で語ってきたが、Kent Beck という人物がとんでもなく明快に、そして極端に、人に喜ばれるソフトウェア開発、という視点でプログラミング活動を中心おいて4つの価値と12個のプラ
皆さんの現場では、矛盾を抱えながら開発を進めてはいないでしょうか? 自分たち以外の誰かが決めた、スコープ、期限、コストを守るために、「絶対無理!」と いいながら毎日残業している方もいるのではないかと思います。 ウォータフォールプロセスは、このような矛盾を含んだ開発の代名詞のように語られる こともありますし、その対極の存在としてスクラムなどのアジャイルが語られることが 多いように思います。 私は、開発の矛盾は開発プロセスそのものには直接依存していないと考えています。 アジャイルも開発の矛盾を解消することを目的としているわけではありません。 しかし、組織の構造と開発プロセスの組み合わせが影響する場合はあるのではないかと考えています。 ヒエラルキーを持った組織とウォータフォールプロセスの組み合わせにおいては、 スコープ、期限、コストなどのコミットメントを上位に対して守らなければならない プレッシ
何年か前に、顧客(と元請けの営業)だけがアジャイルに盛り上がった結果盛大に火を噴いて関係者が闇に消えた開発に関わったことがある。立場上そのままは書けないし、適宜フェイクも混ぜていくが、バッドノウハウの一例として紹介するとともに、ウォーターフォールからの脱却という意味でのアジャイルについて書いておきたい。 前提 契約はSI型一括請負、全外注。且つ、アジャイル。 闇アジャイル化の経緯 営業がアジャイルを売り込みたかったという背景があり、「だいたいこれぐらい」で契約が成立(仕様がないのに見積もりだけはあった) その時点で、元請け企業の偉い人たちがこの案件を切り捨てた(応援要請も突っぱねるよう根回しがあった)(まあしかし偉い人はさすがである、経営的な観点では正しい) 全外注は予想されうる責任回避のための手段として決定された(選択権もなかった) 顧客は仕様を決めなくてもなんとかなるのがアジャイルだと
ここ最近の「アジャイル」という言葉の使われ方に違和感を感じています。 年々システム開発のプロジェクトは、短納期化と低コスト化の流れが進んでおり、それによってリスクが増して且つ利益の出にくい状況になりつつあり、多くのシステム開発を請け負うシステムインテグレータは様々な取り組みを進めています。 そして、その一つとして期待されているのが「速い・安い」を実現する「アジャイル開発」だと言うわけです。もはや、まるでファストフードです。 大手システムインテグレータが集まってアジャイル検定を始めるようです。一部引用します。 アジャイル検定の本格運用に向けた、アジャイルソフトウエア開発技術者検定試験準備委員会を設立 近年、ソフトウエア開発では、厳しい経済不況などの影響を受け、ユーザーの要件を確実に、高品質に、より短期間で提供することが求められています。このような環境の下で、注目されているのがアジャイル開発手
みなさんこんにちは。@ryuzeeです。 スクラムをはじめとしたアジャイル開発の見積りでよく使われるのがストーリーポイントです。 ストーリーポイントは研修でもよく聞かれるテーマであるとともに、誤解も多いものなので、今回基本からまとめて解説したいと思います。 なお、文脈の前提として、スクラムでの活用を想定しています。 ストーリーポイントとは?まずは、ストーリーポイントとは何なのかを見ていきましょう。 書籍『アジャイルな見積りと計画づくり ー価値あるソフトウェアを育てる概念と技法』(Mike Cohn 著、安井力、角谷信太郎 訳、マイナビ出版、2009/1/29)の61ページから62ページにかけて、ストーリーポイントは以下のように定義されています。 ストーリーポイントとは、ユーザーストーリーやフィーチャ、その他の作業の大きさをあらわす単位である。 ストーリーポイントを使った見積りではそのような
インセプションデッキが倒せない 1. インセプションデッキが倒せない PRESS START @uedayo 2012 2. Question 質問です 3. What’s the HOTTEST topic in “The Agile Samurai”? アジャイルサムライの中で一番ホットなテーマは? 4. INCEPTION 5. Inception deck, isn’t it? インセプションデッキですよね? 6. Question もう一つ、質問です 7. How many times have you made an inception deck? 何回インセプションデッキを作ったことがありますか? 8. Self Introduction Yoshinori Ueda twitter: @uedayo facebook: http://fb.me/yoshinor
日経SYSTEMS 2012年4月号の特集1が「システムを育てるカイゼン型開発のススメ」ということで、Part4に私も寄稿させて頂きました。ソニックガーデンが今のビジネスモデルを採用した理由について書きました。 「カイゼン型開発」という言葉は、2006年に私がブログで書いたのですが、ようやく時代が追いついてきたのかと感慨深いものがあります。そして、2012年の私たちは既にそこからさらに先に進んでいて、その答えとなる「納品のない受託開発」というビジネスモデルに辿り着いています。 実際に掲載された寄稿記事の方では割とコンパクトにまとめてもらいましたが、こちらではディレクターズカットということで元々に書いた原稿の方を公開します。もし、このブログよりもさっと読みたい場合は日経SYSTEMSを読んで頂くのが良いかと思います。 ソニックガーデンでは「納品のない受託開発」という少し変わったスタイルでの受
アジャイル開発に取り組むチーム向けのコーチングや、技術顧問、認定スクラムマスター研修などの各種トレーニングを提供しています。ぜひお気軽にご相談ください(初回相談無料) みなさんこんにちは。@ryuzeeです。 2012年3月16日に実施されたAgile Japanの大阪メイン会場に登壇させていただきました。 発表の資料を以下に公開します。 会場の外まで立ち見が溢れるくらいの多くの方にお越しいただき感謝するとともに、ご不便をおかけした方にはお詫びしたいと思います。 僕が話した内容は、実は単に実際の現場で、現場を良くしたいと思っている皆さんの胸のうちを代弁しただけです。 アジャイルという単語、スクラムやXPといった手法の名前自体の認知度があがって、ともすればこれらを導入すれば全てうまくいくんだ、と誤解を生んでいるのではないかと感じています。 でも手法は手法でしかなく(したがってスクラムやXPを
アジャイルジャパン公式サイト|Agile Japan アジャイルジャパン 東京サテライト 2012/03/16 Agile Japan 2012 AM #aj12 - Togetter 2012/03/16 Agile Japan 2012 東京サテライト #aj12 #aj12東京 - Togetter オープニング/キーノート/IPAによる報告(UST中継)/東京サテライト オープニング The Surprising Science Behind Agile Leadership 〜 アジャイルリーダーシップの背後にある驚くべき科学について 〜 全体最適のマネジメント改革 〜変えるのは現場ではない、マネジメントである 〜 アジャイルのABCに向けたヒント 〜IPA/SECの調査検討から見えてきたもの〜 上記UST中継に関しては、てっきり『UST中継=会場外でも観られる』と思ってた節があ
みなさんこんにちは。@ryuzeeです。 Marc Löffler 氏が書かれた “5 Signs That Your User Stories Suck” という記事が分かりやすかったので抜粋・意訳にてご紹介しましょう。 以下にあげるようなことは、そもそも「何のためのユーザーストーリーなのか?」ということを考えずにプラクティスとして取り込んでしまっているが故に起こる問題であるとも言えます。 一年半ほど前に、ユーザーストーリーを台無しにする方法について書いた。 それから現在までの間に、ぞっとするようなユーザーストーリーをほかにも見てきた。 それがこの記事を書こうと思った理由だ。 以下にあげるのが、あなたがユーザーストーリーをうまく使えていない兆候のリストだ。 1. ユーザーストーリーが単なるラッパーになっているもしユーザーストーリーがたった1つのタスクから構成されていたとすると、それはユー
鈴木雄介 氏 / 小川明彦 氏 / 吉羽龍太郎 氏 / 大澤俊介 氏 パネルセッションです。チケット管理システムに関する質問に回答する形で進行していました。 まとめ チケット管理システムはツールである。必要に応じて最適なものを選ぶことが大切。 チケット管理システムをすべて比較できるひとは少ない。色々調べて、聞いて、使ってみると良い。 開発の規模が大きくなると導入効果も上がる。 前提として導入するだけじゃなくて、ちゃんとみんなで使うこと、日々改善すること。 コミュニケーションにかかるコストを節約できる。 頻繁な変更への対応、メンバ間、顧客との課題共有がしやすい。 資料が公開されています。あわせてどうぞ。 チケット管理システム大決戦 JIRA vs Redmine vs Trac ユーザーが語る、なぜ私はこのツールを使うのかView more presentations from Sean O
今日は認定SCRUMマスターコース(2日間)の1日目でした。すげー疲れた(ALL英語)けど面白かった。いろいろ考えました。講師の Bas Vodde さんも、わかりやすく、飽きさせず、経験豊富で、とても良かった。(Finland で仕事をしたことがあるそう。北欧か!今は中国で、大企業で Scrum の普及なんかをしている) 終わったあと、いっしょに行った人々と話をしながら、整理。 有料セミナーなので内容はあまり具体的に書きません。 Scrum 原点 The New New Product Development Game (竹内、野中) http://apln-richmond.pbwiki.com/f/New+New+Prod+Devel+Game.pdf リーン 質問: なぜ日本のソフトウェア業界ではリーン(トヨタ生産方式)を活用していないのか? RAD 自己管理 ゴールを狙う 計画通
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く