Janet Gregory さんの Agile Testing for the Whole Team 研修 に参加した - こまぶろ
※以下の記事は研修の内容を伝えることを意図したものではなく個人的な感想と学んだことを記載したものです。 Agile Testing for the Whole Team 研修 3/1~3/3の3日間で、アギレルゴコンサルティング主催のオンライン研修「Agile Testing for the Whole Team」に参加してきた。 www.jp.agilergo.com 講師は Janet Gregory（@janetgregoryca） さん。『実践アジャイルテスト』の著者の一人で、最近では『Agile Testing Condensed』という書籍も執筆している（こちらについても既にブロッコリーさん（id:nihonbuson） による邦訳がある）。 実践アジャイルテスト: テスターとアジャイルチームのための実践ガイド 作者:リサ クリスピン,ジャネット グレゴリー翔泳社Amazon
カオスに満ちたソフトウェア開発からの脱却 “愛される職場”を作るためにできること Part1
2018年1月11日から13日の3日間、第8回目となるRegional Scrum Gathering® Tokyoが開催されました。スクラムの初心者からエキスパート、ユーザー企業から開発企業まで、立場の異なる様々な人々が集まる学びの場である本イベント。世界中からスクラム開発におけるエキスパートたちが一堂に会し、最新の情報や自身の知見を惜しげもなく語ります。1日目のKeynoteに登壇したのは、『ジョイ・インク 役職も部署もない全員主役のマネジメント』の著者であり、Menlo Innovations CEOのRich Sheridan氏。自身のビジネスマンとしての半生と、自社で取り組んでいる組織づくりの工夫を紹介しました。講演資料はこちら 『ジョイ・インク』著者による基調講演 Rich Sheridan氏：本を執筆する際には、多くの人に読んでもらいたいと願いますが、ビジネス書の表題に「喜び
Mob Programming Startup Manual #MobProgramming #モブプロ
現場でモブプログラミングを始める時、ワークショップをする時の説明に使えるように作成しました。 許諾は必要ありませんのでご自由にお使い下さい！！ （使用した時にTweetしてくれると勝手に喜びます） Updated at 2018/9/3
米Microsoftで働く日本人エンジニアが語る、“楽しく開発”するために必要なこと - ログミーTech
2018年1月11日から13日の3日間、第8回目となるRegional Scrum Gathering® Tokyoが開催されました。スクラムの初心者からエキスパート、ユーザー企業から開発企業まで、立場の異なる様々な人々が集まる学びの場である本イベント。世界中からスクラム開発におけるエキスパートたちが一堂に会し、最新の情報や自身の知見を惜しげもなく語ります。2日目のKeynote「敢えて属人化せよ！ エキスパートの集団こそが最強のチーム」に登壇したのは、Microsoft本社で活躍するエンジニア、河野通宗氏。日本からアメリカへと移った中で感じたカルチャーショックと、その開発環境について語ります。 マイクロソフト本社で働くエンジニア 河野通宗氏（以下、河野）：Microsoftの河野と申します。ふだんはシアトルでAzureサービスを作っているんですけど、今回は川口さんにご縁があってお呼び
開発者の開発者による開発者のためのAgileドキュメンテーション - Qiita
開発者であれば避けては通れないドキュメンテーション。 しかし多くの開発者が嫌がっているドキュメンテーション。 今回はアジャイル型開発（以下、アジャイル）のプロジェクト・チーム開発者における最適なドキュメンテーションについて考察したいと思います。 アジャイルとドキュメント ドキュメントは書かなくて良い？ 日本においてアジャイルはゆっくりだが確実に浸透しています。 7年間アジャイルをしていた私としては嬉しく思う反面、世間には誤った認識が広がっているのもまた事実です。以下はアジャイル勘違い集の抜粋です。 Q. ドキュメントを書かない？ もちろんアジャイルプロセスでもドキュメントは書きます。ただ優先順位が異なるだけです。 ... 最小限の文書化で最大限の効果を狙う、必要にして十分なドキュメント。そうしたドキュメントは一朝一夕に書けるものではありません。 ― ドキュメントを書かない？｜アジャイル勘違
「終わらないスクラム」を終えて得たスクラムの実践に関する5つの学び - RAKUS Developers Blog | ラクス エンジニアブログ
id:radiocat です。9/13に東京オフィスで開催したMeetupに登壇し「終わらないスクラム」というタイトルで発表しました。今回のイベントを通じて、私たちが継続してスクラムに取り組んでいくうえでの様々な気づきを得ることができたので、それらを5つの学びとして記事にまとめてみました。ご参加頂いたみなさま、ありがとうございました。 rakus.connpass.com 発表の概要 発表の前半は私たちのチームが取り入れたアジャイル開発のプラクティスの説明で、今年3月の社内イベントで発表した内容がベースとなっています。それらの概要は以前のブログ記事にまとめていますのでご参照ください。 tech-blog.rakus.co.jp 発表の中盤からは開発を少しずつアジャイルにし、やがてスクラムにチャレンジしていくために私たちが参考にした書籍やネット上の情報を紹介しました。そして後半部分では、現在
「きょん、やっとむ、Ryuzeeらと語るアジャイル開発の本質」参加レポート #densohack - Qakink blog
イベント概要 先日、アジャイルの本質について語るイベントが日本橋で開催された イベントのテーマは「本質を理解しないままのアジャイル開発に挑む危うさ」 アジャイル3怪獣 と呼び声の高い (?!) お三方がアジャイル開発の本質を激辛トークで深掘り 会の後半では、参加者を交えたディスカッション（フィッシュボール形式）も行われた イベント詳細はこちら：https://connpass.com/event/96750/ 登壇者 やっとむさん「アジャイルってなにが美味しいの？」 きょんさん「目的論からのアジャイル～手段を目的化すること～」 ryuzeeさん「アジャイル開発でコールド負けしないための5つのポイント」 感想を一言で言うと タイトル通り、内容が本質すぎて辛かった 終始「ぐぬぬ…」となる胸熱展開のオンパレードでした 「アジャイルってなにが美味しいの？」 by やっとむさん 登壇資料 そもそもア
Agile Failure Patterns in Organizations
TL;DR: Agile Failure Patterns — Why Agile is Simple and Complex at the Same Time Agile failure seems to be increasingly more prominent nowadays despite all the efforts undertaken by numerous organization embarking on their journeys to become agile. The funny thing is: Who would disagree that the four core principles of the Agile Manifesto — Individuals and interactions over processes and tools Wor
Spotifyのスケーリングアジャイル – 部隊、分隊、支部やギルドと共に歩む（Spotifyモデル）
(注)ヘンリックの許可を得てざっくり意訳しました。原文は『Scaling Agile @ Spotify with Tribes, Squads, Chapters & Guilds』です。訳に対するヘルプも歓迎します。Thanks Henrik, this article is great for me. プロダクト開発をしている組織において、多角的なチーム構成を実現するのはいつもチャレンジな作業だ！ 今まで見てきた中で印象に残っている例がひとつある。それはSpotifyだ。Spotifyは3つの都市にまたがって30以上のチームにスケールしているが、アジャイルなマインドセットをキープし続けている。 Spotifyは音楽産業を一変させている魅惑的な企業だ。創業してから6年しか経っていないのに、1500万ものアクティブユーザーを抱え、400万以上の決済が行われている。また、そのプロダクトは「
スクラムで開発チームが自由な取り組みをするには？
みなさんこんにちは。@ryuzeeです。 スプリントをずっと回していると、「いつもスプリントに追われている気がする」「一回立ち止まってゆっくり考えたい」「情報共有ができていない気がするので整理したい」「技術検証をもっとやりたい」「勉強時間をとりたい」といった話を聞くことがあります。 それに対して、どのように対処していくべきか考えてみましょう。 考えられる対応策はいくつもあるので、まずはそれを列挙します（ダメなものも混ざっています） 複数回スプリントを実施したら、1回分のスプリントでは開発チームは好きに活動する（✕）スプリントとスプリントの間に休憩を入れる（✕）フィーチャー開発以外の取り組みを行うスプリントを必要に応じて用意する（△）スプリントのキャパシティを見直して、開発チームが持続可能なペースで働けるようにする（◎）それぞれを順番に見ていきましょう。 複数回スプリントを実施したら、1回分
JS 大規模プロジェクトの管理手法 – ロードオブナイツの実例紹介
どうもこんにちは。 Aiming で東京開発グループのゼネラルマネージャをやっている小林です。 8月に mobage と Yahoo! モバゲー で ロードオブナイツ というシミュレーション RPG をリリースさせて頂きました。 そして、先週、 Yahoo! モバゲー版の PC ブラウザ専用デザインをリリースさせて頂きました。 今回リリースしたものは元々 Unity で作られていた iOS アプリ版 Lord of Knights を HTML5 で書きなおしたものです。 （今は Android 版 もあります） HTML のポチポチゲーをネイティブに移植したというのはよく聞く話ですね。 ですが、逆にリッチなネイティブアプリを HTML5 に移植し、かつスマフォブラウザと PC ブラウザで同じものを動かすなんてのは前例が見当たりませんでした。 技術的ハードルが高かったことに加えて期日がタイ
アジャイル開発で『動くソフトウェア』による開発を始めるために必要な考え方 まとめ | mah365
アジャイル開発においてもソフトウェアを作り始める以上、仕様を決める必要があります。いわゆる要件定義です。ただし、全く新しいものを作る場合と、古いものを新しく置き換える場合とで、やり方を変える必要があります。 新しいものを作る場合 ビジネスモデルはあるものの、それを実現するソフトウェア像はまだはっきりしない・・・新しいものを作る場合には、当然よくあるケースです。 ウォーターフォールとカウボーイスタイル この場合、「全部決めないと開発できませんよ！」というのが一般的ウォーターフォール開発であり、「とりあえず作りながら考えましょうか！」というのがカウボーイスタイルのアジャイル開発です。前者は冷静に考えて不可能（最初から決められたら誰も苦労しない）ですし、後者は手戻りすぎて永遠にローンチできません。 リーンスタートアップスタイル 新しいものを作り始める場合は、リーンスタートアップのスタイルを採用す
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
リモートアジャイル開発ノウハウ集 | Agile Studio
全部門にカンバンが導入された１０の理由と活用事例 「駅すぱあと」はカンバンと秘伝のソースでできて...