アジャイルチームのアーキテクトのための10の助言
原文(投稿日：2010/09/14)へのリンク Microsoft AustraliaのソリューションアーキテクトであるTom Hollander氏は、TechEd Australiaでアジャイルチームにおけるアーキテクトの役割と題したプレゼンを行った。 氏はこの場でアジャイルチームを率いるアーキテクトとして氏が行っていることについて議論した。 アーキテクトの役割について話すとき、氏が指すのは“ソリューションアーキテクト’、つまりアプリケーションのアーキテクトだ。エンタープライズアーキテクトやある種の専門家(例えばメッセージングやインフラなどの専門家)を指してはいない。 氏のチームは、最後に2、3日のコード凍結を行う、安定した4週間のイテレーションプロセスで、毎日のスタンドアップミーティングや毎日のビルドと自動テストが伴う継続的統合を実践している。氏のチームでは次のような役割を採用している
Research Exploring The Current State of Software Practices
Research Exploring The Current State of Software Practices I have been performing survey-based research pertaining to various issues within the IT community. I’ve made the data available to others so that they can evaluate it, and hopefully share their findings, with others. In fact, this site was an early adopter of “open data” strategies. I also have some advice to share about surveying the agi
アジャイルな開発プロセス導入にあたって検討すべきこと - Ryuzee氏の講演資料から -：森崎修司の「どうやってはかるの？」：オルタナティブ・ブログ
3/19（金）のTech Fieldersセミナー「Agile Day 2 - ペアで参加し、セッションとワークショップを楽しもう！」の講演の1つに表題の講演があったそうだ。講演資料がここで公開されている。全体とりまとめをされている長沢氏のエントリにも紹介がある。IBMエバンジェリスト玉川氏、すくすくスクラムの今村氏の講演とワークショップで構成されたそうだ。 講演資料にはプロセスを変える際に検討すべきこと、準備すべきことが書かれている。これからアジャイルな開発プロセスを導入しようとする方だけでなく、アジャイルに限らず開発プロセスの変更や新しい方法を導入するとき一般にも、通用する内容というのが私の印象。 私が興味深いと思ったことは以下のとおり。 現状がうまくいかないからといって、目的を明確にせず、プロセスを変えたり、技術・技法を導入しようとしない。 導入に際して組織のトップへの働きかけと現場
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
