アジャイル開発を習得したいなら。スクラム開発対応のプロジェクト管理·ScrumDo MOONGIFT
ScrumDoはアジャイル、スクラム開発に対応したプロジェクト管理。Django/Python製。 ScrumDoはPython/Django製のオープンソース・ソフトウェア。アジャイル開発が徐々に使われるようになっている（社内開発中心だが）。アジャイル開発では、ユースケースをストーリーという単位にして管理する。一つのイテレーションの中で一つまたは複数のストーリーをこなす形だ。 ストーリー作成 一つのイテレーションを終わった段階で複数の機能が開発、テスト、結合されているのでそのままリリースすることさえできる。それを繰り返して開発を進めることで徐々に機能や品質が高まっていく。そんな開発を実現するためのプロジェクト管理がScrumDoだ。 ScrumDoではストーリーを作成し、その中にタスクを追加する。そしてそれをイテレーションの中に組み込んでいく。イテレーションを行った結果はバックログとして
やどりぎ@NET: trac + TracBurndownプラグインでスクラム開発のすすめ
ソフトウェア開発手法とその管理システムには様々な選択肢がある。私もこれまで色々試行錯誤してきたのだが、今は、tracとバーンダウンチャートを追加するプラグインであるTracBurndownプラグインでスクラム開発という環境が気に入っている。 この環境を導入したきっかけは、転勤で勤務地が変わったことである。 これまで、東京でチームを組んでソフトウェア開発をしており、その仕事を引き続き仙台で行うことになったが、今までの開発プロセスだと不都合が出始めた。 タスクカードを使った「かんばん方式」とスクラムをベースにした開発プロセスを組み合わせて使っているのだが、物理的に開発拠点が分離してしまい、タスクカードが使いにくくなってしまったのである。 いいタイミングなので、周囲の評価が高いので試してみようと構築していたtracにバーンダウンチャートのプラグインを導入して、全面的に移行することにしたという訳だ
Ruby on Rails製のアジャイルプロジェクト管理·Simply Agile MOONGIFT
Simply AgileはRuby on Rails製のフリーウェア（ソースコードは公開されている）。アジャイル開発の基本になるのが、イテレーション単位の開発であったり、ストーリーベースの機能組み立てだ。こうしたやり方はウォーターフォール型と全く異なるので、慣れないとなかなか難しい。 有料Webアプリケーションとして提供されている 書籍などを読んで全て理解してからはじめるのも良いが、実際のプロジェクトはそんな暇もないくらい突き進んでいく。そこでプロジェクト管理を使って体感しながら進めてみるのはどうだろう。その一つ、Simply Agileを紹介しよう。 Simply AgileはRuby on Railsで作られたプロジェクト管理で、ソースコードは公開されているがWebサービスとして有料で利用することもできる。プロジェクトを作成し、イテレーションを作り、登録したストーリーを選択して実際の開
レバレッジメモ: アジャイルレトロスペクティブ - 西尾泰和のはてなダイアリー
レトロスペクティブ=ふりかえり 場の設定: 目標・アジェンダの確認、参加しやすい雰囲気作り データ収集: 客観・主観両方のデータを共有し「共通の理解」を作る アイデア出し: 「共通の理解」を吟味 TODO決定: アイデアに優先度をつけ、やることを決める 終了: TODOの実行方法の決定。レトロスペクティブのレトロスペクティブ 振り返るための質問 いまどこにいる？ どうすればもっとうまくできる？ 後悔を断ち切るために解決すべきことは？ 望んだ人間になっているか？ 自分の望んだような影響を他人に与えているか？ これからなにをしたらいいのか？ 自分の強みをうまく使えているか？ 場の設定 最初に各人に声を出させるべき。「ずっとしゃべらないでいい」という思い込みを取り除くため。 目標。たとえば「繰り返される作業をカイゼンする」 会議を生産的に保つための約束と価値観のすり合わせが必要。 データ収集 客
スクラムの祖父語る「開発者は知的体育会系であれ」 － ＠IT自分戦略研究所
アジャイル開発を行う技術者が集まるイベント「アジャイルジャパン2010」レポート。「体験しよう！ 考えよう！ 行動しよう！」をテーマに、さまざまな角度からアジャイルを考察したイベントの模様を、前後編に渡ってお届けする。 前編｜1 2｜次のページ 「開発者の皆さん、行動する中で考える『知的体育会系』であってください」 4月9日の「アジャイルジャパン2010」で、「スクラム開発」の源流を生んだ一橋大学大学名誉教授 野中郁次郎氏が基調講演を行った。テーマは「実践知のリーダーシップ スクラムと知の場づくり」。 ソフトウェア開発のリーダーは、考えるだけの思索家であってはならない。体を動かすだけの実践家でもいけない。実践しながら徹底的に考え抜く「知的体育会系」となって、「よりよいもの」をどこまでも追求してほしい。 「知識経営」の生みの親であり、「スクラム開発」の祖父でもある野中氏がITエンジニアへ向け
2010-03-25 - m_pixyの読書日記
23日（火）に開催された匠塾オープン講座に参加してきた。 http://www.takumistyle.net/takumijuku/ps-012.html 先にmixi日記に書いてたのを、ちょっとだけ書き直してこちらにも。gdgdと、そして長文。 今回の中心のテーマは「ビジネスアジャイル」。 ビジネス価値向上に直結することをやるのがアジャイル開発だということから考えると、二重定義な気もするんだけど、かと言ってじゃあその辺の部分を考えることなくただアジャイル開発をやっていればお客様の価値の向上につながるかってことにも確信が持てないし、っていう僕個人の疑問とか思いに直結していそうなテーマだったのもあって参加した。 いろいろと思うところはあったんだけど、感想として一番大きなところは 自分がなんとなく思っていたことが言語化されてうれしい。 でもなんとなくもやもやが残っている。 と言ったところかな
アジャイルと"ユーザ中心設計"の調和
原文(投稿日：2010/03/17)へのリンク UX のスペシャリストである Anthony Colfelt 氏はアジャイルについて，それが単独では不完全なものであることを論証するとともに，ユーザ中心設計のアジャイルへの統合の可能性とあるべき姿に関して，詳細かつ興味深い検証を行っている。 ビジネス の要件定義支援という課題の解決手段として，果たしてアジャイルが適当であるのかどうか。Colfelt 氏の メッセージ はそれに疑問を呈するものだ。 アジャイルそれ自体は，状況の変化に柔軟に対応する手段として有効なものです。しかしアジャイルが，より大きな課題である「ビジネス自体が要件を定義できない」ということの解決手段として考案されたものであるか，という点には疑問が残ります。確かにアジャイルによって，開発チームがこの課題に対応するのは容易になります。しかしそれで問題が解決するわけではなく，ほとんど
実験駆動開発 - ポストアジャイルの手法
原文(投稿日：2010/02/25)へのリンク TDDとBDDは今や、広く使われているソフトウエア開発技術だ。しかし、単にBDDやTDDに従っているだけではビジネス機会を逸したり、もっと悪いときにはビジネスに悪影響を及ぼしてしまう。TDDとBDDには解決できないふたつの問題がある。すなわち、どのようにして開発したアプリケーションの使用を評価するのか。そして、どうやって顧客からフィードバックを得るか。 ユーザを調査する従来の方法は決して正確な結果にはならない。アプリケーションの提供者も顧客も多大な時間を必要とし、先入観にとらわれてしまう。Nathaniel Talbott氏はRubyConf 2009でのプレゼンテーションで次のような考えを発表した。すなわち、開発時におけるTDDと同じような方法でビジネスもフィードバックを得るべきだ、という考えだ。 (画像はLabnotesから) ソフトウエ
アジャイル開発向け顧客チェックリスト - GeekFactory
大企業, SIerただ僕が顧客ならば動くソフトウェアを確認しながらウチの業務プロセスにフィットするかを確かめながら進めたいと強く思うので、そのメリットを価値に変えるストーリーがあればいいと思うんだけど、自分たちの手でシステムを進化させる文化が根付いていない所には｢なにそれ？おいしいの？｣という響かない提案になると非常に思うので、やっぱ内製だろって思ってしまう今日この頃です。http://d.hatena.ne.jp/gothedistance/20100212/1265907956id:gothedistanceさんの釣り力には本当に感嘆します。タイトルにアジャイル開発とか入れておきながら、結論は内製で締めています。読者を流行語でget()して自分の論説にforward()するとは、実に素晴らしいエンターテイメントです。と、無茶いってごめんなさい。アジャイル開発の本質は顧客が主体性を持つこ
アジャイル開発のステータスを出力する·Scrum Sprint Monitor MOONGIFT
Scrum Sprint MonitorはWindows用のオープンソース・ソフトウェア。アジャイルに限らないが開発のステータスは常に更新されていないといけない。バッチでまとめて変更を行うと、手戻りの発生や状況の変化によってステータスが大きく左右されるようになってしまう。 プロジェクトのステータスをグラフ化 そこで常時更新されるステータスをみんなで見られるようにしようというのがScrum Sprint Monitorだ。マイクロソフトの開発管理ツールTeam Foundation Serverと連携し、そのステータスをビジュアル化するソフトウェアだ。 ユーザストーリーやバックログ、作業時間などを円グラフで表示する。さらに開発者ごとのグラフやバーンダウングラフも描画できる。現在のスプリントの状況がはっきりと掴めるようになるだろう。 設定ソフトウェア Scrum Sprint Monitorの
朝会のアンチパターン
この文章は、Twitterでちょっと盛り上がった朝会のアンチ・パターンについて、勝手にまとめ、補足したものです。 朝会のあり方については、M・ファウラー氏の「朝会のパターン：立ってるだけじゃないよ」や、オブジェクト倶楽部の「プロジェクトファシリテーション実践編：朝会ガイド」(PDF)を参照してください。 運営に関するアンチパターン 座ってやっている フォース 報告が詳細になりすぎている。時間がかかりすぎている。そもそも場所がない。 対策 立って開催することを呼びかける。 ただし、諸事情でどうしても立ってできない場合は、なるべく短くなるように全員が心がける。 シーンとしている フォース 朝会全体に威圧的な雰囲気、または陰鬱な雰囲気ができている。プロジェクト進行がうまくいっていない。 対策 朝会を行う意義をもういちど全員で確認する。 その他 朝会以前にプロジェクトの建て直しをはかる。 誰も他人
スクラムブートキャンプ 〜 今からスクラム/アジャイルをやってみようという人のための道しるべ - kawaguti’s diary
スクラム／アジャイルを学ぶためのおすすめ書籍を並べておきます。 (09/11/30 スクラムチェックリストを追加、09/12/01 アートオブアジャイルデベロップメント追加、10/02/26 スクラムガイド、スクラムマスタ研修を追加、10/02/27 プランニングポーカーの記事を追加 10/03/20 今村さんのスクラム概要を追加 10/04/07 Scrum in 5mins 追加) 拙作、PublicKeyにも掲載していただいた 10分でスクラム Scrum in 10mins 20110118 scrum 10 mins View more presentations from kawaguti 拙作、スクラム入門 Scrum in 5minutes 20100323 Scrum5minsView more presentations from kawaguti. InfoQ: 塹壕
第1回 社会人初プロジェクトがアジャイルだった
本研究所では、アジャイル開発を素材に、より良いシステム開発のあり方を求めていく。モデリングや設計などを学ぶことも大切だが、開発手法そのものを見直すことは、より良いシステムを作るだけではなく、開発を担当するチームが成長し、個人の満足度も高まると考えられる。第1回は、2008年4月に新社会人となった研究所長の私が、なぜアジャイルと出会い、どこに楽しさを感じているかをお伝えします。 みなさん、初めまして。森下・アジャイル研究所の所長を務める森下真衣です。2008年4月に新社会人となり、元KDDIのCIO（最高情報責任者）だった繁野高仁さんの情報システム総研で働くことになったことが、アジャイル開発との出会いでした。 私は実業務として、ウォーターフォールによる開発を経験したことがありません。ただ、学生時代にはウォーターフォールを参考にして開発していました。“ものづくり”の楽しさを感じてはいましたが、
Agileでやってるけどデスマったｗ
Agileでデスマになったのでそのログです。 この後同じことを繰り返すと馬鹿なので、まだデスマ中だけど、問題点と反省点を書いておこうと思う。 こういうのは渦中にやっておかないと終わった後だと「大変だけど終わって良かったね」で終わってしまいがちなんだよね。 これを読まれている方は反面教師にしてください。 契約と総生産量の関係性 期間と費用が決まっている場合、総生産量には当然上限がある。生産量はチームのベロシティが分かっていれば、ストーリーポイントに換算できるので、開発開始時点で、総生産可能ストーリーポイントについては明示すべきだった。土日出て頑張れ！とか残業して頑張れ！とかいうのはAgileを知らない証拠。 上記に関連して、プロダクトバックログにストーリーを追加することが出来るのは、プロダクトオーナーの権利なのだけれども、優先度高としてストーリーを追加したところで、バーター可能なストーリーが
Kanban vs Scrumを訳しました。 - Fly me to the Luna
InfoQ Japan 2009で講演されたHenrik Kniberg氏の「Kanban vs Scrum」の翻訳をid:wayaguchiさんと共に行いました。Henrik氏は「塹壕より Scrum と XP」の著者としても有名で、最近はカンバンについても色々話されているナイスガイです。 原本(Kanban vs Scrum) Kanban Vs Scrum日本語版View more documents from Hiroki Kondo. 自分はこの資料を訳すために下記の本を読みました。 アジャイルソフトウェア開発 (The Agile Software Development Series) 作者: アリスター・コーバーン,Alistair Cockburn,株式会社テクノロジックアート出版社/メーカー: ピアソン・エデュケーション発売日: 2002/08/30メディア: 単行本購
アジャイル開発のボトルネック | Social Change!
「お金なら出しますから、４ヶ月のところを２ヶ月で作ってくれませんか？」 システム開発で、顧客からこう言われた時、どうするか？ SIerの経営者や管理職であれば、飛びついてしまうんじゃないだろうか。私だって飛びつきたい。確かにエンジニアがいるなら、もしくは、集める目処が立つなら、ありがたい話かもしれない。XPでも、「リソース・スコープ・品質・時間」のパラメータで、品質以外は変動可能としている。 ということは、リソースがなんとかなれば、時間を短くする、もしくは、時間を変えずにスコープを増やすことができるのだろうか。人月という単位で考えれば、計算上は出来るかもしれないが、実際には難しいと言わざるを得ない。それはなぜか。ボトルネックは、プログラムを作る速度か、それとも、仕様を決めて受け入れる速度か。 冒頭の台詞は、開発側にこそボトルネックがあり、コストさえかければスピードアップできると考えているか
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
ストーリーポイントは複雑さや時間と関係があるか？
ScrumGuide日本語訳 | ワイクル株式会社
ふりかえりを改善するためのルール
アジャイルの本質的な要素