チケットの粒度 - Mitsuyuki.Shiiba
娘を寝かしつけるのに一緒に眠ってしまったあとに目が覚めて眠れないので明日朝早いので眠くなるといいなぁと思いつつブログ。 チケットの粒度について しばらく試行錯誤してたんだけど、てか、もう2年くらいあーでもないこーでもないってやってた気がする。 のだけど、いったんここかなというところを見つけられたっぽい。エッセンシャルスクラム読んだの大っきい。 スクラムスタイル で開発してるので。ユーザーストーリー中心のバックログなのだけど。 ユーザーストーリーはストーリーポイントを持っていて、リリースプランニングに使っている。 ユーザーストーリーをスプリントバックログに入れるときに、タスクに分割して時間見積もりをする。という感じ。 なのだけど ユーザーストーリーが「リリースできる単位」って考えると大きくなってしまって。より大きい概念が欲しいなーと思ってエピックを使ってみたら、思ったよりユーザーストーリーを
Developers Summit 2014 で「Play2/Scalaでドメイン駆動設計を利用した大規模Webアプリケーションのスクラム開発の勘所」という内容で発表してきました - sifue's blog
あまりにタイトルが長すぎるだろうと各所から突っ込まれ、あまりにも詰め込んだ内容で発表してしまったとちょっと反省しています。 お話としては、現在ニコニコ生放送の内部をPHPからScalaへ書きなおしているよ、というお話でした。 発表内容はこちら。 Developers Summit 2014 「Play2/Scalaでドメイン駆動設計を利用した大規模Webアプリケーションのスクラム開発の勘所」 from Yoshimura Soichiro これらの内容は、これからScalaを使ってWebサイトを構築、運営してみようとしているリーダーさん向けに書いたものとなっています。Play2/Scalaやドメイン駆動設計、またスクラム開発の導入への足がかりにの情報となっていれば幸いです。 こんな雪の中わざわざ聞きに来てくださった皆様、そしてこの書き直しを着想するにあたってお世話になった特にじゅんいちかと
スクラムはもうだめぽよ!新しい開発手法『パワープレイ』をお姉さんが教えてあげちゃう!
2013/3/9 NADECで講演した内容です。 都合上、やったみた結果の一部内容は省きました。 何かあればTwitterで @arimamoto までお願いします (^^)/ Read less
Agile in a nutshell
© Copyright 2009, Rasmusson Software Consulting Jonathan Rasmusson http://agilewarrior.wordpress.com/ Japanese Translation: Kakutani Shintaro (2010-10-21) Original Slides: http://agilewarrior.wordpress.com/presentations/ © Copyright 2009, Rasmusson Software Consulting Changing requirements Adaptive plans Iterative development The Waterfall Horror Feature Show © Copyright 2009, Rasmusson Software C
「ほう・れん・そう」を15分の朝会に置き換える
「スクラム」は、アジャイル開発の手法群の中でも、「チームとしての仕事の進め方」に特化したフレームワークだ。スクラムの知識を応用して、開発チームの日常をちょっとリファクタリングしてみよう。 今回の内容 ●課題： 「ほう・れん・そう」が意外と使いづらい＆時間が掛かる ●スクラムのプラクティス 「朝会」の要素を取り入れる ポイントは4つ。「決まった時間・全員参加・日々の報告のみ・15分」 ほう・れん・そうの苦いわな 「上司とのコミュニケーション時には、常に“ほう・れん・そう”をしなさい」 「報告しろ、連絡しろ、相談しろ」。新人研修で、必ずと言っていいほど教えられるフレーズです。もしかしたら今、教える側の人がいるかもしれません。 「ほう・れん・そう」は、覚えやすいという素晴らしい利点があるのですが、重大な欠陥があります。「いつ／どのくらいそれを行えばよいか」を教えてくれないのです。 「ほう・れん・
Scrum Patterns : スクラムを構成する要素を分解し、組織パターンに対応づける - kawaguti’s diary
組織パターンのジム・コプリエン(James O Coplien)氏と、スクラムの共同開発者のジェフ・サザーランド(Jeff Sutherland)さんが中心になって、スクラムを組織パターンで説明する取り組みがありました。その成果であるパターンの概要を日本語にしてみました。内容に変なところ等がありましたらぜひご指摘ください(GitHubにホストしました)。 原文はこちらにあります。 スクラムパターン概要 スクラムが効きそうにないところを除いたパターン これらのパターンがスクラムそのものだ。2008年6月、スクラムの創立者(訳注:ジェフ・サザーランド氏)と組織パターンの開発者(訳注: ジム・コプリエン氏)が、数名のエキスパートとともに、組織パターンの本に記述されたパターンを、スクラムフレームワークの中で適用する際の、全体像(マップ)を作成した。これらのパターンは、スクラムフレームワークの代表的
はてなブログ | 無料ブログを作成しよう
聖蹟桜ヶ丘へ 今年度の授業が全て終了した。最後の授業はテスト返却とその確認作業の後は特に何をしろとも言われていなかったので、『耳をすませば』の後半、お姉さんと雫が言い争いをする場面を生徒と皆で見た。 この場面。あの場面、お姉さんは雫に「今しなきゃいけないことから逃…
開発者にやさしい環境
ikeike443と申します。このブログの言いだしっぺです。 シャノンに転職してきてちょうど1年になります。前職は業務パッケージソフトの会社に所属していました。 転職してきた経緯などについては、下記のインタビュー記事で話したので、よかったら読んでください。 SaaSの可能性を信じて、新たな道を踏み出したエンジニアの「視点」 で、今回はとりあえず、シャノンに入社してこれは”いいね”と思ったポイントをつらつらと挙げてみます！ アジャイル開発やってるよ 開発方法論としてはアジャイル開発手法の一つ、Scrumを採用しています。 約一ヶ月をひとつのスプリントとみなして、毎月頭にスプリントの計画と見積りをして開発／テストに入ります。 毎朝のミーティングでバーンダウンチャートを確認し、文字通りみんなでスクラムを組んで開発しています。 バーンダウンチャートの作成、プロダクトバックログの管理には、ヌーラボさ
完成の定義のサンプル(1)
みなさんこんにちは。@ryuzeeです。 今日は完成の定義について説明しようと思います。 完成の定義って何？チームとして定めた「出荷可能な製品」を作成するために実施しなければいけないことの一覧です。 例えば、コードを書く、ユニットテストする、統合テストをする、リリースノートを書く、などがそれにあたります。 プロダクトバックログアイテム単位での完成の定義、スプリント単位での完成の定義、リリース単位での完成の定義をすることもあります。 完成の定義はチームの成熟度や時間によって変わっていきますが、完成の定義なくしてのScrumはあり得ません。 詳しくはScrum Allianceの記事も参照してみてください。 また、あわせてHow Do We Know When We Are Done?も読んでおくとよいと思います。 事例 Scrum Allianceの記事から上述の通り、Scrum Allia
オープンソースなScrum管理ツールのTeamTrickを試してみた
moongiftで紹介されていたので早速試してみました。 概要 TeamTrickはRailsで出来ているScrumプロジェクトの管理ツールで、チーム管理、プロダクトバックログ、スプリントバックログ、バーンダウンチャートなど基本的な機能を備えている。 外部へのデータのエクスポートや外部からのインポートには対応していない模様。 日本語は問題なく使えることを確認しています。 入手 本家サイトからダウンロード可能。 Linux用とWindows用が用意されており、Windows用の場合は、バッチファイルを実行することで即起動して使える。Windows版はインストールパスにスペースが含まれていなければ問題なく起動できる（デスクトップに配置すると起動失敗）→他のマシンでは再現しないので、他の問題かも。 機能紹介 とりあえず画面の紹介。 ユーザー登録画面。 ログイン直後。プロジェクトのリストが表示され
プロジェクトふりかえり（プロセス、運用面） - miauのブログ
しばらくブログ更新してませんでしたが、12月頭までプロジェクトが大変だった＆その後燃え尽きてたのが原因です。 リハビリがてら、そのプロジェクトの反省でも書いてみます。長くなりそうなので、まずはプロセスや運用面の話から。 プロジェクトの概要 某サービス会社向けの Web アプリケーション開発 既存システムを置き換える形なので、要件のブレは少ない 今回はフレームワークとして Rails を使用 開発期間は 2009/08〜2009/11 の 4 ヶ月＋α。その前に要件定義や調査は少し実施。 開発メンバは 4 人 1 人（私）は渉外やサーバ構築やデータ移行で時間を取られていたので、開発メンバは実質 3 人。 この 3 人は 全員 Ruby や Rails の経験なし。というか開発経験がない or 数カ月といったメンバばかり。 さらに本来アーキテクトとして入る予定だった私が全然そちらに関われなかっ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
【資料公開】アジャイルな開発プロセスを導入するために考えなければならないこと