ユーザーストーリーマッピング - take a keen edge
ユーザーストーリーマッピングを読みました。 ユーザーストーリーマッピングの方法論よりも、とにかく会話する、作るものを減らすことを論じています。 ドキュメントが正義じゃない、バックログを上から消化するのが正義じゃない、というのは私もぼんやりと感じていたことではありましたが、よりはっきりとその感覚が着きました。 ストーリーマッピングを実際に運用するには、本文にもありましたが、外部コーチに依頼するのがよいでしょうね。 以下まとめ。基本的に丁寧語は私の意見とか解釈です。 0章 まず最初に呼んでください 共有ドキュメントは共通理解ではない 本書の中で何度も登場する概念ですが、目的だったり手段だったり、どんな対象であっても、共通理解を得るためには会話が必須である、ということです。「顧客が本当に必要だったもの」の風刺絵は有名ですが、「共通理解を得られていない」状態は本当に容易に発生してしまいます。これを
日本のアジャイルコミュニティとアジャイルについての質問と回答 - ayumi_h’s blog
最近、トロントで『Woman in Agile』というコミュニティが立ち上がり、参加しています。 コミュニティ専用のSlackがあって、そこではインターナショナルに会話がなされているのですが、その中でワシントンにお住まいのアジャイルコーチから日本のコミュニティに関する質問をもらいました。 質問の内容はこちら： What is the agile community like there? how big? how mature? What are some of the unique challenges faced by Agile coaches in Japan? structural? cultural? What industries are heavy into Agile? which ones are not? Finally, is there more integrat
https://link.medium.com/1jsAtPLA6T
デザイン思考は、問題を探索・解決するための方法です。リーンは、私たちの信念を試し、適切な成果につなげる方法を学ぶためのフレームワークです。アジャイルは、ソフトウェアの変化していく状況に適応するための方法です。 デザイン思考は、能力と学習に関するものです。スタンフォードd.schoolのCarissa Carter主任は、デザイナーを高める能力について、素晴らしい記事を書いています。たとえば、曖昧さ、共感的学習、統合、実験などが、その能力として挙げられています。意味を生み出し、問題の枠組みを設定し、潜在的な解決策を探索する、デザイナーの能力が重要なのです。 『誰のためのデザイン？』の著者であるドナルド・ノーマンは「デザイナーは最初のアイデアに満足しない」と述べています。あなたも考えてみてください。最初のアイデアが最高のアイデアだったことはありますか？意味や新しいアイデアが生まれるのは、物事を
Spotify engineering culture (part 1) - Spotify Engineering
Here’s part 1 of short animated video describing our engineering culture. This is a journey in progress, not a journey completed, and there’s a lot of variation from squad to squad. So the stuff in the video isn’t all true for all squads all the time, but it appears to be mostly true for most squads most of the time :o) Here’s the whole drawing: (Tools used: Art Rage, Wacom Intuos 5 drawing tablet
LeSS (Large-Scale Scrum) の概要
1. LeSSの概要 (Large-Scale Scrum) 2016/11/25 Ryuzee.com 吉羽龍太郎 (@ryuzee) 2. LeSS概要 ✤ 大規模用のスクラムフレームワーク。まぁまぁ十分という程度を目指している ✤ 8チームまで用とそれ以上のチーム用(LeSS Huge)の2バージョンがある ✤ LeSSはスクラムなので以下はそのまま適用される ✤ 製品は1つでプロダクトバックログも1つ ✤ 完了(完成)の定義も1つ ✤ スプリントの最後には出荷判断可能な製品の増分を作る ✤ 1人のプロダクトオーナー (スクラムマスターは複数でOK) ✤ クロスファンクショナルチーム ✤ スプリント期間は固定期間 (各チーム共通で同じ日に開始・終了) 3. 歴史 ✤ ✤ CraigとBasによって2005年から開発。多くの事例 ✤ 通信機器 - Ericsson & Nokia Ne
アジャイル開発で『動くソフトウェア』による開発を始めるために必要な考え方 まとめ | mah365
アジャイル開発においてもソフトウェアを作り始める以上、仕様を決める必要があります。いわゆる要件定義です。ただし、全く新しいものを作る場合と、古いものを新しく置き換える場合とで、やり方を変える必要があります。 新しいものを作る場合 ビジネスモデルはあるものの、それを実現するソフトウェア像はまだはっきりしない・・・新しいものを作る場合には、当然よくあるケースです。 ウォーターフォールとカウボーイスタイル この場合、「全部決めないと開発できませんよ！」というのが一般的ウォーターフォール開発であり、「とりあえず作りながら考えましょうか！」というのがカウボーイスタイルのアジャイル開発です。前者は冷静に考えて不可能（最初から決められたら誰も苦労しない）ですし、後者は手戻りすぎて永遠にローンチできません。 リーンスタートアップスタイル 新しいものを作り始める場合は、リーンスタートアップのスタイルを採用す
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
