Sqwiggle が良いという話、またはリモートでアジャイル開発をどう進めるか - naoyaのはてなダイアリー
KAIZEN platform Inc. は、新しい働き方をいろいろ試してみようという会社でそのひとつにリモートワークがある。リモートワークの良さあるいは良くないところについては、以前に Rebuild.fm の ep.32 でも話した。 ちかごろは、オンラインミーティングのための道具、情報共有のための道具もクラウドサービスがたくさんあるので、その辺を使って工夫すれば一昔前に比べてだいぶリモートワークも現実的になってきている。実際、KAIZEN には大阪からリモートワークしている人とか、最近リモートワークを前提に都内から鎌倉に引っ越したメンバーなんかもいる。 リモートワークとアジャイル開発 HipChat、Google Hangout や Qiita Team なんかを使うことで、日常の会話、ミーティングや情報共有についてはもともと特に困ったこともあまりなかった。特に Qiita Team
資料公開 Scrumの概要 (2013年の開発トレンド先取りセミナー)
2013年2月1日に日本マイクロソフトさんで行われた「2013年の開発トレンド先取りセミナー」で、Scrumの概要について話をしました。その際の資料を公開しておきます。あんまりいつもと代わり映えしない資料ですが、アタマの方に大事なことを書いておいたのでそこだけはチェックしておいてください。 まぁ正直なところ、Scrumが開発トレンドを先取りしているかどうかは微妙だと思ったのですが、今日ご参加頂いた方の中でアジャイル開発に取り組まれている方は数名しかいなかったので、日本だとまだまだこれからなのかなぁ。 個人的には、アジャイル開発、継続的デリバリー、DevOpsあたりは日本で早く当たり前になってくれるといいなぁと思っています。 なお、DevOpsについては、2013年2月号の日経SYSTEMSにDevOpsでよく使うツール群の話を書きましたので、ご参照いただければ幸いです。他にも各社のDevO
こんなプログラマはアジャイル出来ますって言ったらアカンやろ - メソッド屋のブログ
最近、とある機会があって、いろんなアジャイルが出来るといってくるベンダーさんとあう機会があるけど、正直「おい！どの口がアジャイル出来るって言ってるねん！」って思う事がむっちゃくちゃ多い。 今は確かにアジャイル開発ブームで、世間では引き合いも多いらしい。いろんなベンダーの営業さんが、「うちもアジャイルできます」って言って営業してはるけど、マジでちゃんと自社でできるか調査してから営業してほしい。私はアジャイルを１０年以上やってるけど、元々は「この方法やったら、お客さんにホンマにええアプリを届けれるんちゃうか？」と思ったところから来ている。 それが、今や猫もしゃくしもアジャイル出来ますとか言って、ろくにアジャイルも出来へんのに売りつけて、結局効果がでなくて、「やっぱアジャイルなんかアカンやん」ってなるのがむっちゃくちゃ嫌なのだ。 これって数十年昔のオブジェクト指向ブームと一緒やん。当時のオブジェ
長いデイリースクラムを防ぐかなり簡単な方法
みなさんこんにちは。@ryuzeeです。 Stuck in an overlong Agile stand up? Try the two hands ruleが良い記事なので抜粋・意訳にてご紹介します。 デイリースクラムは15分以内で行うことが決まっています。 また話す内容も「昨日やったこと」「今日やること」「困っていること」の3点について話すことになっており、長くなるような話や個別の相談事項は別の機会で必要なメンバーで行うことになっています。 一方で、デイリースクラムがなかなか終わらない（聞いた例で一番ひどいのは毎日1時間かかっているらしい…）とか、関係ない話ばかり出て他人事のようになってしまい、単なる報告をして他人の話を聞かないといった問題を良く聞きます。 これらを解消する簡単な方法として二人挙手ルールを紹介します。 アジャイルチームで仕事をする際、デイリースタンドアップミーティング
アジャイルレトロスペクティブズ - 強いチームを育てる「ふりかえり」の手引き : 小野和俊のブログ
『アジャイルレトロスペクティブズ』読了。献本感謝。 GoF本がデザインパターンの教科書であり、XP本がソフトウェア開発の手法に関する教科書だとすれば、本書はチーム開発における「ふりかえり」の教科書であると言ってよいのではないだろうか。 本書では、「ふりかえり」に関するパターンが50近く紹介されているのだが、一つ一つがとても実用的かつユーモラスにまとめられている。 本書で紹介されている方法はゲーム的で、模倣可能で、隠れてしまっている改善へのヒントを引き出すものとなっている。 以下、おもしろかったものをいくつか、コメントを交えて。 ■ アジャイルレトロスペクティブなチーム まずいきなりインパクトがあるのが、アジャイルレトロスペクティブなチームの会議の例。一見何ともない普通の会議に思えるが、この箇所だけ見ても、明確なゴールと時間の設定、冒頭に全員に発言させる点など、参考になる点がいくつもある。
テスト自動化について5分で分かるまとめ
みなさんこんにちは。@ryuzeeです。 テスト自動化について簡単に教えてほしいと言われることが多いので、以下にまとめました。 テスト自動化/テスト駆動開発についてXPのプラクティスの中で、最も単体で導入しやすいプラクティスの１つであるこのプラクティスのみで１冊の本が書けるくらい奥が深い基本的な方法失敗するテストを書くできる限り早く、テストがパスするような最小限のコード本体を書くリファクタリングをする適用範囲通常では、独立性の高いクラスやファンクションへの適用が良いGUIや分散オブジェクト、自動生成されたコード、DBのスキーマに関するテストは導入が難しい既存システムにおいて、テストが準備されていない場合に、部分的に導入するのは難易度が高い。したがって新規プロジェクトの初期から導入することが望ましい問題点開発者が仕様を誤解していた場合、誤解に基づくテストコードが作成されるため、誤解の検知は保
マイクロソフトにおけるアジャイル開発はこんな風に進められている － Publickey
マイクロソフトの代表的なソフトウェアは、数千人を超える開発者、数十万のソースコードファイル、数千回ものビルドを繰り返して開発される大規模なものだといわれています。 マイクロソフトのエバンジェリスト長沢智治氏は、こうした大規模な開発プロジェクトがマイクロソフト社内でどのように行われているのか、プロジェクトチームの組成から実施計画、進捗管理、バグレポートなど、その裏側を紹介するセッションをいくつかのイベントで行っています。 そこで明かされている内容は、パッケージソフトの開発だけでなく、SIerでの開発プロジェクトでも参考になる部分が多いと思われ、いつかレポート記事として紹介したいと思っていました。 今回、以前に行われたセッションビデオの存在を長沢氏ご本人から教えていただいたので、開発プロセスに関する部分にフォーカスした記事としてまとめました。 記事での内容は主に、「Microsoft Tech
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
7462