アジャイル時代のモデリング: アジャイルチーム拡大のためにはコードの次に何を保つべきなのか
図１．シンプルなスクラム構成 この最小限のフレームワークの中で、チームのインプットとなるのが”ユーザ要求”としての”プロダクトバックログ”です。そして、アウ トプットは”動くソフト ウェア”としてのコード（”製品コード”と”テストコード”）です。 そこには他の設計要素が明示的に現れてはいません。スプリントの中で作られたすべての意図的な設計はチームの財産として実行コートの中に組み込まれるのが 望ましいですが、そこには直接コード化されない情報もあります。スクラムは開発プロセスであり、設計に関しては敢えて何も言及していませんが、設計と設 計活動はチーム内部であいかわらず行われています。 Grady Booch氏は”コー ドは真実ではあるが、すべての事実ではない” と語っています。だから、もしそこにコードで表現又は伝われない情報が残されるとしたら、私達はその情報をどこに格納できるでしょうか？その質
システム品質を左右する「組織体制」「開発スキーム」「マインド」を改善してきたリクルートの苦労を振り返る（組織編）～ソフトウェア品質シンポジウム 2013
システム品質を左右する「組織体制」「開発スキーム」「マインド」を改善してきたリクルートの苦労を振り返る（組織編）～ソフトウェア品質シンポジウム 2013 システムの品質を左右する要因は何か。リクルートテクノロジーズ 執行役員CTO 米谷修氏は「組織体制」「開発スキーム」、そして発注者を含む関係者の「マインド」の3つが大きな要因であると説明します。 9月12日と13日の2日間、都内で開催された日本におけるソフトウェア品質に関する最大級のイベント「ソフトウェア品質シンポジウム 2013」（日本科学技術連盟主催）の特別講演として行われたのが、米谷氏の講演「進化するIT組織と開発スキーム ～リクルートのサービス開発の事例紹介とともに～」でした。 大規模なシステムを迅速、かつ高品質に、という要求が続く現場で、米谷氏が続けてきた試行錯誤の中で得た知見とは何か。講演の内容をダイジェストで紹介しましょう。
ソフトウェアは完成しても価値はない 〜 アジャイル開発は何を解決するのか | Social Change!
「アジャイル開発を、お客さまに導入してもらうにはどうすればいいですか？」 そんな相談を受けることがあります。私はどんな優れた提案も相手にニーズがなければ通らないことを知っています。喉が渇いていない人に水を売ろうとしても売れないのです。そもそも提案する前に、まずはニーズに気付いてもらう必要があります。そして、そのお客さまは、本当にアジャイル開発に対するニーズがあるのでしょうか。 私の考えるアジャイル開発の本質は「アジャイル開発では当初に想定した機能を”全部”つくらない」ことだと考えています。（参考記事：アジャイル開発の本質 〜 アジャイルとウォーターフォールの違いとは） この「全てを作らないことで、変化に対して柔軟に開発していく」というソリューションを求めるニーズがあるのであれば、アジャイル開発のメリットを伝えれば採用されることでしょうし、そういうニーズがなければ、何を言っても受け入れられま
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
