フィーチャーチーム
フィーチャーチームとは？ フィーチャーチームは、”組織の既存の枠やコンポーネント等にとらわれず、多くの顧客 のフィーチャーを1つずつ完成させる長寿命のチーム” です。フィーチャーチームは、大規模開発でアジャイル開発を実践するために必要不可欠です。フィーチャーチームがなければ、（その代わりに、コンポートネットチーム、コード所有権に基づく、もしくは１つの機能に基づくグループ、アナリストグループ、プログラマグループ、テストグループ等に分類）あなたの組織は、結果的に逐次的開発サイクル（ウォーターフォール, ...）となり、非常に多くの無駄を生み出したり、部分最適化を行います。フィーチャーチームは、多く無駄を取り除くと同時に、変化と挑戦を求めます。 フィーチャーチームのすること？ フィーチャーチームは大きなプロダクト開発で長期間、活躍します。例えば、テレコムシステム（Ericsson）やコンパ
アジャイル界隈研修の感想まとめ
自社会場で開催したりして、それなりの回数を参加したり聴講したりした経験があるので、なんとなくまとめていきます。 Jeff Patton, 認定スクラムプロダクトオーナー研修VOYAGE GROUP会場で4-5回くらいは開催してる。会場係としてお手伝いしつつ、内容をなんとなく聞いている。 印象に残ってるのは、プロダクトオーナーは開発者に対して、いろんな手段を使って実現したいもののことを伝えるのが仕事だということ。ドキュメントだけ書きゃいいってもんじゃないし、かと言って会話すりゃいいってわけじゃない。やり方はそれぞれの関係性によるが、とにかく、伝えるというのが大事らしいぞっていう。 研修の進め方も面白くて、毎回ちょっとずつ違いがあって、改善してるんだなーっていう印象がある。 手法の一例として彼はユーザストーリーマッピングというものを提唱していて、そのトレーニングもある。いろんな人に感想を聞くと
最高の成果を出す「アジャイル＋ウォーターフォール開発」
毎日打ち合わせをすることに抵抗を感じる開発者もいる。では、アジャイルソフトウェア開発を採用している組織はどのようにプロジェクト管理の改善を図っているのだろうか？ かつてITチームは、話はよく聴くが、ユーザーの期待に応えられないとやゆされていた。従来のウォーターフォール開発では、ITチームは長い時間をかけて顧客と擦り合わせをし、プロジェクトの正規の仕様書をまとめ、そこから通常はさらに12カ月かけて、顧客が同意し承認した内容に従って機能を実装する。 注：本記事は、プレミアムコンテンツ「Computer Weekly日本語版 2013年5月15日号」（PDF：無償ダウンロード提供中）に掲載されている記事の抄訳版です。 しかし、12カ月のうちにビジネスの状況は変わり、プロジェクトの仕様がビジネスのニーズに合わなくなることは日常茶飯事。紙やPowerPointスライド上では素晴らしく思えたアイデアは
スクラム実践入門の紹介 - HsbtDiary(2015-03-18)
■ スクラム実践入門の紹介 2013年末から1年くらい執筆やら編集やら取りまとめやら続けていたスクラム実践入門が本日発売開始しました。 この本は 2013年末くらいに同僚のあんちぽくんと一緒に自分たちがソフトウェア開発をする時に役に立つ本を書こうと @inao さんに提案したのがきっかけです。git log -p --reverse の1コミット目はこれ commit 710fc0c8cd065ceb24904a6f26bf21ac22d9ddf2 Author: SHIBATA Hiroshi <shibata.hiroshi@gmail.com> Date: Sun Dec 15 02:26:33 2013 -0800 Initial commit diff --git README.md README.md new file mode 100644 index 0000000..5a
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
