アジャイルチームのアーキテクトのための10の助言
原文(投稿日：2010/09/14)へのリンク Microsoft AustraliaのソリューションアーキテクトであるTom Hollander氏は、TechEd Australiaでアジャイルチームにおけるアーキテクトの役割と題したプレゼンを行った。 氏はこの場でアジャイルチームを率いるアーキテクトとして氏が行っていることについて議論した。 アーキテクトの役割について話すとき、氏が指すのは“ソリューションアーキテクト’、つまりアプリケーションのアーキテクトだ。エンタープライズアーキテクトやある種の専門家(例えばメッセージングやインフラなどの専門家)を指してはいない。 氏のチームは、最後に2、3日のコード凍結を行う、安定した4週間のイテレーションプロセスで、毎日のスタンドアップミーティングや毎日のビルドと自動テストが伴う継続的統合を実践している。氏のチームでは次のような役割を採用している
アジャイル開発とクラウド（SaaS）利用の位置づけ、SIerの生きる道
早口の関西弁でつっこみまくって笑いを誘い、でも最後にアジャイル開発とクラウド利用の棲み分けについて「なるほど」と思わせる素敵なライトニングトークのビデオを見つけました。 それはPublickeyでも何度か紹介している9月4日に行われたイベント「XP祭り2010」での、市谷聡啓氏によるライトニングトーク「始まらなかったAgileの話をしよう」です。 アジャイル開発、セールスナントカに敗退す ライトニングトークのあらすじを紹介しましょう。市谷氏がある海岸沿いのSIerにいたころの話。 お客様から「特定の期間しか使わない。できるだけ早く利用したい。ただし仕様は変わる可能性がある」というシステム開発案件の依頼を受け、「これはアジャイルしかないだろう」とお客様に提案。 市谷氏はこの提案で「勝利を確信したなと」。 「ところがこいつが出てきたんですね、黒船ですわ」と思わぬ競合が出現。「具体的に言うとセー
カンバン方式のプロジェクト管理·Digaboard MOONGIFT
DigaboardはPHP製/Webベースのオープンソース・ソフトウェア。タスクは見える形にしなければならない。工場などでそれを行ったのがトヨタのカンバン方式だ。多数の製造業の現場はもちろん、オフィス内でも取り入れていく活動がある。 操作はフローティングウィンドウ上で行う アジャイル開発においても現在のイテレーションにおけるタスクを見えるようにし、共有できるようにする。ホワイトボードに付箋紙を貼って管理していた方法をデジタル化するのがDigaboardだ。 Digaboardは複数のチームを縦軸で分け、その中にプロジェクトを配置していく。そしてプロジェクトごとにタスクを登録し、状況が見えるようにする。タスクに対してコメントを登録したり、誰が取り組んでいるかも分かるようになっている。 全体図 縦軸はステータスであり、作業中なのか次のイテレーションなのか、終わったものなのかが分かるようになって
アジャイル開発を、人はどのようにして学ぶのか。アジャイルの第一人者、平鍋さんに聞いた
「アジャイル開発は、実は本を読んで理解するのがとても難しい」。9月4日に、有志によるアジャイル開発のイベントの基調講演「アジャイル開発の現在・過去・未来」の中で、アジャイルの第一人者であるチェンジビジョン代表取締役社長の平鍋健児氏はこう発言しました。 本を読んで理解するのが難しいのだとすると、アジャイル開発はどのようにして学んでいくのがいいのでしょうか？ 平鍋さんが伝えようとしたことを詳しく聞くために、メールインタビューをしました。 自分で考えることが本質 先日のXP祭りで平鍋さんの講演を聞いたとき、「アジャイルは人づてに伝わっていく」という部分が印象に残りました。また、「アジャイルは、実は本を読んで理解するのがとても難しい」ともおっしゃっていました。とはいえ、アジャイル開発を本や講演などから学び始める人も多いはずです。そういう方々にアジャイルをどう学ぶのがいいのか、というアドバイスを届け
こくちーずプロ - 無料で使えるイベント・セミナーの告知・集客サービス
個人から法人まで幅広い主催者の方にご活用いただいています。 イベント主催者7万人以上 チケット販売520万枚以上
「ウォーターフォール開発」、本当に日本でうまく行っているのか？ | スラド デベロッパー
「Continuous Delivery」というソフトウェア開発に関する書籍の著者、Jez Humble氏によりますと、多くの日本IT企業は大規模ソフトウェア開発プロジェクトでウォーターフォール（Waterfall）な開発手法を取っているのですが、この開発手法は世界中で多くの失敗を引き起こしているにも関わらず、日本ではなぜかうまく行っているそうです（Humble氏のブログ記事）。 /.J諸兄方の職場では、ウォーターフォール開発手法で本当にうまく行っていますか？ また、今使っている開発手法は何ですか？ これは、7月21日に行われたAgile Conference Tokyo 2010でのトークセッションで話題にされたそうで、参加者のレポートやTwitter実況などによると、Humble氏は日本の開発工程に「バグフィックス工程」がないことに驚いたらしい。頻繁なテストやコーディング段階での修正が
Technologic Arts Incorporated | Agile Conference tokyo 2010 終了のご報告
2010年7月21日、秋葉原駅の目の前の秋葉原コンベンションホールで、弊社主催のAgile Conference tokyo 2010が開催されました。 300人の定員でしたが、当日はほぼ埋まっていましたので、かなり出席率は高かったと推察します。 最初は、ThoughtWorks社の Jez Humble 氏による基調講演です。 継続的結合(CI)の概念を越えて、頻繁にデリバリーを繰り返す継続的デリバリー(Continuous Delivery) についてご説明がありました。 デリバリーを早くする為に、Always Production Ready という体制を維持するとのお話がありました。何か変更した場合には、毎回細かくフィードバックを得られるようにすること、かつそれが全員に行き渡ることが大切とのことです。 継続的結合(CI)では、常に非同期でビルドを繰り返し自動化されたテストを走らせ
コンウェイの法則（Conway's Law） - Plan9日記
libtaskが提供するコルーチン。その歴史は古く、マルチプロセス／スレッドが登場する以前の並行システムの実装によく用いられていた。例えば、Simulaとかが有名だが、スラッシュドットに次のような書き込みを見つけた。 Simula開発者Kristen Nygaard氏死去 Anonymous Coward : 2002年08月14日 12時35分 (#145858) 手元の教科書によると，当初はクラスがデータ抽象化にたいへん有効だ，ということは Nygaard と Dahl も気づいてなくて，1972年になってから Hoare が初めて指摘した (Acta informatica, 1(4), 1972)，とあります．SIMULA67 にクラスを導入した理由は，むしろコルーチンをサポートするためだったそうで． へぇ、これは知らなかった。 このコルーチンの生みの親はMelvin Conway
アジャイル開発のスケールアップはアジャイルリリーストレインが鍵を握る: プログラマの思索
「アジャイル開発をスケールアップさせるには何が必要か？」という思索を深めている時に、とてもぴったり来た本が「アジャイル開発の本質とスケールアップ 変化に強い大規模開発を成功させる14のベストプラクティス (IT Architects’ Archive)」だった。 「アジャイル開発の本質とスケールアップ 変化に強い大規模開発を成功させる14のベストプラクティス (IT Architects’ Archive)」の本をざっくり読んでみて、考えたことをメモ。 【元ネタ】 Developers Summit 2010：CodeZine（コードジン） Jazz 日本ユーザコミュニティ - デブサミ2010参加レポート「Agility@Scale(アジャイル開発のスケールアップ)を実現する14のベストプラクティス」 Developers Summit 2010：CodeZine（コードジン） なんかの
Technologic Arts Incorporated | アジャイル開発QIMP研究会 成果報告
株式会社テクノロジックアート（本社:東京都文京区本郷、代表取締役社長:長瀬嘉秀）は、2010年3月5日に開催した「第4回アジャイル開発QIMP研究会」までの全4回の研究会成果を公開いたします。 アジャイル開発QIMP研究会は、アジャイル開発に精通するメーカー、SIer、製品ベンダーの有志の協力により、大規模アジャイルプロジェクトにおける、課題への対応策、課題解決の考え方を検討するという目的で、2009年10月30日に発足し、アジャイル開発に関する様々な具体的検討を開始しました。 現在、日本のシステム開発では、ウォーターフォール型開発が主流となっていますが、目まぐるしく変わるビジネスを支えるシステムも、その変化に追随することが重要です。昨今、一部のシステム開発において、ウォーターフォール型開発がその要求を十分に満たしきれないことが明らかとなり、アジャイル開発への注目が高まりつつあります。ただ
Visual Studio Marketplace
One place for all extensions for Visual Studio, Azure DevOps Services, Azure DevOps Server and Visual Studio Code. Discover and install extensions and subscriptions to create the dev environment you need.
ペアプログラミング - Wikipedia
2人のプログラマーによるペアプログラミング ペアプログラミング（英: pair programming）はソフトウェア開発の手法の一つで、2人のプログラマが１台のマシンを操作してプログラミングを行う手法。 当初は、２人が１台のワークステーションに向かって作業するものだったが、現在では一人で複数台を同時に使ったり、一台に複数台のディスプレイを使うことも多くなり、具体的なやり方は変わっている。 実際にキーボードを操作してコードを書く人を「ドライバ」、もう1人を「ナビゲータ」と呼ぶ。30分ごとか、単体テストを1つ完成させる度に役割を交替するのがよいとされる。また、1日に一度の頻度でパートナーを変えるのがよいともされている。 利点[編集] ペアプログラミングには、以下のような利点があるとされている。上に挙げた項目ほど重要である根拠を示していない。 規範意識の増大。ペアプログラミングでは、個人の作業
マイクロソフトのアジャイル開発支援
在庫限り。人気のSurface Duo 2 が再入荷され、最大 36% OFF 中。ご購入はお早めに。
- 継続的インテグレーション
継続的インテグレーション 原題: Continuous Integration Martin Fowler Chief Scientist, ThoughtWorks Matthew Foemmel ThoughtWorks 「確実なビルドを行う」 -- これはどんなソフトウェア開発プロセスであれ重要なことだ。そのわりには、このことがきちんとされていないことに驚かされる。本論文では、Matt が ThoughtWorks 社でのある大規模プロジェクトにおいて採用したプロセスを紹介する。このプロセスは全社的な広がりを見せつつある。テスト部分も含めて「全てが自動化された」「再現可能な」ビルドを、「日に何度も」行うことに力点がおかれている。このプロセスを用いれば、開発者はインテグレーションを毎日行うことになるので、インテグレーションに伴う問題を減らすことができる。 継続的インテグレーションの恩恵
＠IT：特集 「テスト駆動開発」はプログラマのストレスを軽減するか？
新しいソフトウェア開発技法へチャレンジできるか？ ソフトウェア開発の世界にも日々の進歩がある。そしてその中には、使えばさまざまな恩恵を受けられる技法もある。しかし、それらを現場ですぐに活用できるとは限らない。例えば、1990年代末に生まれ、1つのブームを形成したエクストリーム・プログラミング（XP）という開発技法がある。これは、とても優れた開発技法だと思うのだが、開発プロジェクト単位で、顧客まで巻き込んだ形で使われることが前提となっている。しかし、顧客ぐるみでまったく新しい方法にチャレンジできるかといえば、できないことの方が圧倒的に多いだろう。では、エクストリーム・プログラミングの技法を全部使おうとせず、使うことができる部分だけを取り出して試みることができるかというと、そういうわけにもいかない。エクストリーム・プログラミングは、いくつかのプラクティスと呼ばれる項目から成り立っているのだが、
Always All Ways: [IT] 認定スクラムマスターへの道（その１）
先日のエントリでもご紹介した通り、今まで国内では東京でしか開催されてこなかったScrum Alliance認定スクラムマスター研修が、今年は大阪でも開催される予定である。 ◆ 第一弾： ２０１０年３月１８日、１９日 http://www.scrumalliance.org/courses/20093676-certified-scrummaster ◆ 第二弾： ２０１０年６月１７日、１８日 http://www.scrumalliance.org/courses/20093678-certified-scrummaster 私自身、特に講師のBas Vodde氏やOdd-e社と特別な利害関係があるわけでもないが、せっかくなら大阪でも多くの人が受講し、西日本でも盛り上がって欲しいと思うし、今回だけでなく継続して開催されるようになればうれしいと思う。 そうは言っても、興味はあるけど…とさまざ
第13回 バーンダウン・チャートによるプロジェクト管理の進め方
前回は，バーンダウン・チャートの考え方と，その基となる残時間進ちょくについて解説した。今回は，実際にデイリー・バーンダウン・チャートを使ってどのようにプロジェクトを進めていくかを解説したい。 デイリー・バーンダウン・チャートを作成するのに一番簡単な方法は，作業をタスクかんばん方式で管理することである。この場合，イテレーション初日の時点での見積もり時間の合計がチャートの起点になる。以降は，1日の作業が終了した時点で，「Doing」にあるタスクについて，開発者に「あとどのくらいの時間がかかりそうか」を聞き出してDoingのタスクの残時間を算出する。これにTo Doにある未着手のタスクの見積もり時間を加算したものがその日の残時間計になるので，チャート上にプロットすればよい。イテレーションの途中でタスクが増えたりした場合は，見積もりに時間を上乗せしても構わない。 TRICHORDチームでは，以前は
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Go Replaces Cruise - Aligns Devs, QA, and Ops - DZone Agile
developerscafe.jp
Redmine.JP — Redmine日本語情報サイト
