アジャイルチームにおけるコードレビュー - Sean_SF’s blog
@daipresents さんが「アジャイルなレビューをサポートするツールを5つ」というブログ記事を書かれていました。 コードレビューによりコードの品質を改善することは知られていますが、@daipresents さんのチームのように実際にコードレビューを行っているチームはそれほど多くないと思います。 アトラシアンにおいては、基本的に全てのコードをレビューしています。その方法やヒントなどを説明したブログを以前にいくつか公開しておりますので、参考までに抜粋して下記します。 アジャイルチームにおけるコードレビュー - パートII コードレビューを行う際に留意すべき点として以下の9つを挙げています。 軽量に保つこと 強制しないこと 細かく管理しないこと 非同期のレビューを奨励すること コードレビューを通して、興味深い発見、構成、設計上の決定を積極的に共有すること - チャンピオンになりましょう コ
知らないと損する完全無料アジャイル開発ガイド | Act as Professional
知っているようでよくわかっていないアジャイル開発。こんなの海の向こう側の話でしょ？って諦めるのは、もう昔の話。どんどんアジャイル開発は日本の現場で取り入れられているのです。改めて学ぼうアジャイル。 1. アジャイルソフトウェア開発 – Wikipediaアジャイルソフトウェア開発には、複数種類の手法があることを学ぼう。具体的には スクラム (1986) Crystal Clear エクストリーム・プログラミング (XP) (1996) Adaptive Software Development ユーザ機能駆動開発 (FDD; Feature Driven Development) Dynamic Systems Development Method (DSDM) (1995)などである。 2. Scrumを10分以内で知ることができる資料や動画 | Ryuzee.comアジャイルの一つの手
永和システムマネジメントの新しい受託契約がすごく面白い - ただのにっき(2010-11-11)
■ 永和システムマネジメントの新しい受託契約がすごく面白い 今日は永和が話題をかっさらったねー。「新しい契約形態での受託開発サービス」。 アジャイルと受託開発の相性の悪さには定評があって、なにも作らないうちから納品物・納期をきっちり決める従来の契約形態だとアジャイルな開発がうまくできないというのが最大の課題だったわけだけど、それを開発費用は受託側の持ち出しにして、運用時(アジャイルなので継続的に開発が入る)に細く長く回収するという新しい契約スタイルを打ち出した。 この手の話になると「そもそもアジャイルで受託という発想がいけない、欧米では開発はインハウスがあたりまえ」みたいな頭の悪い舶来信仰が飛び出たりするわけだけど、社外のプロフェッショナル集団が必要なときに必要なものを素早く開発してくれる受託が絶対的に悪いことなんてあるはずがない。永和は、受託開発に対するこだわりがあるんだろうなぁ。そうい
新しい契約形態での受託開発サービス ｜ 永和システムマネジメント
近年、大変注目を集めているソフトウェア開発手法に「アジャイル」があります。 アジャイルはお客さまの組織やビジネスの変化に素早く対応することが可能な開発手法です。 しかし、ソフトウェア業界での受託型の請負契約は要件定義が完了してから開発見積り・契約するというやり方が当たり前となっており、お客様にアジャイルのメリットを実感頂くのが難しいという課題がありました。 これまでの受託開発における一括請負型の契約では納品時に費用を全額お支払いいただくというビジネスモデルをとってきました。 このサービスではこのビジネスモデルから脱却し、開発したシステムを初期費用0円で提供します。その後、お客さまにはサービス利用料という形で月々お支払いいただきます。 サービスがお客さまに価値を提供するのは納品した瞬間ではなく、お客さまがサービスを利用しているあいだ継続的にです。 このことから、お客さまがサービスを利用してい
楽天で角谷さんのお話を聞いた - 未来のいつか/hyoshiokの日記
解読アジャイルソフトウェア開発というタイトルでお話をしていただいた。*1 アジャイル開発の本質を角谷節で1時間あまり独演会してもらった。 Demystifying Agile Software DevelopmentView more presentations from Eiwa System Management, Inc. . ともかく映像を観てほしい。約1時間ちょっと、そしてその後に続く質疑応答も一緒に。 ソフトウェア開発における受託開発という立場ではない、もう一つのソフトウェア開発の現場が、自分のサービスを自分で作るという立場だ。 受託開発の場合はユーザー企業（発注する側）と開発する企業（受託する側）とがあって、時として敵対関係に陥る。一方の利益が他方の損というゼロサムゲームである。 自社開発の場合は、社内にユーザ部門と開発部門があったとしても、最終的にはユーザ部門の利益と開発部
Re: アジャイルって受託開発との相性が最悪な気がする - tsuge development page
前書き 現役アジャイラー（？）を自称する立場として釣られてみるぜっ。 http://d.hatena.ne.jp/gothedistance/20100212/1265907956 「アジャイル」について 多分id:gothedistanceもわかっていると思うんですが、アジャイルはマニフェストなんであって具体的な手法ではないです。 代表的なアジャイルとしてeXtreme Programmingモデルを例にとると、イテレーションプランニングって項目があります。 簡単に言うと開発側は2週間ごとに形にしよう、顧客は次の2週間でほしい機能を決めようってやつ。 XPは改訂が多すぎてこの手の文書の参考にしにくいんですが、細かい事はこの辺見てください。 http://www.objectclub.jp/community/XP-jp/xp_relate/whatisxp-j/ 今回の記事による「アジャ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
20110118 scrum 10 mins
Pomodoro - 時間管理へのアジャイル的アプローチ