知っていて損はない。アジャイルとウォーターフォールの違い｜株式会社Co-Lift
こんにちは。Co-Liftのミドリです。 さて。 「アジャイル」 と言われると、「（ウヒー…！でたでた開発用語！）」と心の中で思ってたりしませんか？ もしくは、「（新しいK-popアイドルかな？）」とか思っちゃったりしませんか？ 私だけ？ 「アジャイル」も「ウォーターフォール」も、確かに開発用語ではあるのですが、システム開発を生業としていない人も実は知っていて損はない用語です。むしろ、デジタルプロダクトを考える上では、欠かせない用語だったりします。 「これからの時代はDXやでーーー！！！ガハハハ」 「弊社は今期、DXを加速していく所存です」 みたいなことを、もし経営陣や上司が言っていたら、知っておいて損はないと思います。 今日は、それぞれの違いについてお伝えしたいと思います。 「オープン・エンド」な課題と「アジャイル」 Co-Liftでは、「オープン・エンド」な問いを解決するために発展し、
Atomic Scrum 個人の生産性を最大化する方法
デブサミ2021の登壇内容 チーム開発における原則としてScrumは浸透しつつあります。一方で個人単位の行動管理・タイムマネジメントについては方法論が確立されていない状況があります。今回は、Scrumの原則を個人単位の行動管理に適用した上で、実装事例としてNotionを活用した方法を紹介します。
アジャイルの対義語はウォーターフォールではなく未来予知だと思っている - 下林明正のブログ
「アジャイルの対義語はウォーターフォールではありません」というのはよく聞く話だけど、じゃあ何なのか？というと、あまり聞くことはないように感じる。 自分は、アジャイルの対義語は未来予知だと思っている。 なぜなら、もし未来予知ができるのならアジャイルである必要は全く無くなるから。 未来予知に基づいて、一切のムダがない完璧な計画を立てればいい。 そういう意味では、変更の余地が無い巨大なウォーターフォールは未来予知的で、アジャイルの対極にあると思う。 でも実際は、未来を予知することは今の僕らにはできない。台風の進路でさえ、予想することしかできていない。遠い未来ほど曖昧だ。 じゃあ、どうせ未来は分からないのだから計画を立てなくて良いのか？というと、そうではない。台風の進路を予知できなくても、予想することはできている。予想することで事前に備えることができるし、予想のモデルを修正して精度を上げていくこと
Web系企業/事業会社への最高の反面教師: "Spotify's Failed #SquadGoals"を読んで - アジャイルコーチの備忘録
はじめに 以前Scrum@Scaleについて@tyantya41717651さん、@zakky_devさんとディスカッションしましたが、先日お二人と、大規模アジャイルフレームワークであるSpotifyモデルと先日公開された失敗記事(「Spotifyは "Spotifyモデル "を使っていない(Spotify's Failed #SquadGoals)」)についてディスカッションしたのでブログにまとめました。*1 はじめに Spotifyモデルと取り上げた理由 モデルの失敗ではなく、ヒトの失敗 扱える以上の自由や権限を与えた悲劇 1. チームへの過剰な権限付与による、サイロ化の加速 2. 分隊のプロセスの自由さや能力不足による、分隊間協力の困難化 3. 全員での意思決定を追求したことによる、意思決定コストの増大 まとめ Spotifyモデルと取り上げた理由 今回Spotifyモデルの詳しい解
「始めるのをやめて、終わらせることを始める」ことを始めた開発チームの話 / Rakus Meetup Osaka 2020-02-05
Rakus Meetup Osaka #5 の発表資料です。 https://rakus.connpass.com/event/182082/
お客さんがプロダクトオーナーになるべきなのか？ - kawaguti’s diary
プロダクトオーナーが忙しい、プロダクトバックログ書いてくれないって話をよく聞くんですけど、そのあと話を聞いていくと実はプロダクトオーナーは同じ会社じゃないんです、お客さんなんですっていうパターンがちょくちょくあります。 プロダクトオーナーがやる仕事は結構あります。 ビジョンを持ち、いつ誰に何を届けるかを考え、プロダクトバックログに落とし込む なるべくROIを高められるようにプロダクトバックログを優先順位付けする。 直近の数スプリント分は準備完了(チームが着手可能)にする チームと定期的に話し合ってバックログを見直す(リファインメント) すべてのステークホルダーと話す 予算を取る バックログの内容についてチームからの質問を受けつけ、明確化する チームが完成としたバックログ項目の成果物(出荷判断可能なプロダクトインクリメント)の受け入れ判断をする 受け入れた成果物をリリースすべきときにリリース
UX調査を用いてアジャイルプロセスを導く方法 - ポップインサイト
この記事は、User Experience Magazineの許可のもと翻訳したものです。 元記事：How to Use UX Research to Guide An Agile Process 著者：Lai Yee Ho User Experience Magazine, 18(2).2018年4月掲載 要約：このケーススタディは、チームとともにUX調査をアジャイル開発プロセスに組み入れた、著者の実際の取り組みに基づいたものです。改良されたアジャイルプロセスでは、アジャイル開発スプリントの開始時点でUX調査が中心的な役割を果たすこととなり、そうした変化はチームが「どのようなユーザ課題を解決していくか」という点で足並みを揃えるのに役立ちました。さらにUX調査は、サイクルの終わりに、「スプリント中に構築された機能が、意図していたユーザー問題を解決したかどうか」を検証するのにも役立ちました。
フジテレビュー!!
フジテレビが新しく立ち上げたウェブメディア「フジテレビュー!!」のプロジェクトに参加しました。「フジテレビュー!!」は、「そのハナシには、つづきがある」というタグラインのもと、オンエアだけでは伝えきれないテレビの裏側やオリジナルの取材記事などを提供する、総合エンターテインメントメディアです。シフトブレインのチームはスタンダードデザインユニットの鈴木丈とマルコ・ソラッツィのほか、デザイナーの及川と羅、プランナー浦川、プロジェクトマネジャー大竹、というメンバーです。 UIデザインにおいてクライアントから何より強く求められたのは「明快さ」でした。あらゆるデザインは、ユーザーが操作に迷ったり読み間違えたりすることのないように、という視点で決定をくだしています。とくにカラーとタイポグラフィについては何度も繰り返し議論を重ねました。カラーはプライマリカラーとしてネイビーブルー、セカンダリカラーとしてタ
スタートアップとデザインについて
Pinterest, Path, Instagram など、アプリのスタートアップでデザインが重要であると言われるようになってから久しいです。しかし、デザイナーという存在の理解はされているのかというと時々分からなくなります。 考えるきっかけを与えてくれたのが、Wells Riley 氏が公開した「Startups, This is How Design Works」というページ。デザインの全体像が分かる素晴らしいまとめではありますが、デザイナーへの期待値を不意に高めている部分があります。 アプリデザインに絞って考えたとしても、そこで必要とされるデザインは、インタラクション、グラフィック、アーキテクチャ、タイポグラフィ、コーディング、ユーザースタディなど多岐にわたります。これらを総括して「デザイン」と呼ぶわけですが、デザイナーも総括した存在ではありません。インタラクションデザイナーはグラフィ
アジャイル・ユーザビリティ ―ユーザエクスペリエンスのためのDIYテスティング―(樽本 徹也) - ただのにっき(2012-04-23)
■ アジャイル・ユーザビリティ ―ユーザエクスペリエンスのためのDIYテスティング―(樽本 徹也) 知人から「ユーザテストをやってみたいんだけど」と相談されて、「これがいいんじゃないかな、まだ読んでないけどきっといい本だから」なんて答えていたんだけど(ひどい)、やっと裏付けがとれた。いい本です。 ヤコブ・ニールセンが「5人で十分ですよ」と言ってからずいぶん長い時間がたったけれど、不思議なことにいまだにユーザテストを提案すると尻込みするクライアントが多い。まず最初のリクルーティングが心理的なハードルみたいだし、(どんなに手軽さを説明してもなお)すごく大変なことをするような先入観があるらしい。そんなリクルーティングを始め、「5人で十分」な成果をあげられるディスカウント・ユーザビリティを、いかに低コストで(その代わり何回も)実施するためのノウハウに絞ったのが本書。 本書で描かれるユーザテストには
AgileとUXデザインに関するもやもやについて - void chachaki::Blog::Tech
自分でも何でこんなにモヤモヤしてるか分かってないのですが、最近の流れがどうにもうまく消化できず、とりあえず言葉にしてみたいと思います。要旨としては以下を考えています。「チーム」としての働きを考えよう身の丈に合ったサイズ・コスト・スピードを考えよう UXなどの言葉の話UX/UXD/UCD/HCD/おもてなし…などなど、ユーザー体験周りの言葉が少しずつ分断されていってるのも混乱の一因だと思うのです。私は単なるプログラマなのですが、2010年度に産業技術大学院大学の履修証明プログラム「人間中心デザイン」を受講して、その履修修了生を中心に「現場で使えるHCD」をコンセプトとしたhcdvalueというコミュニティを立ち上げている関係上、ざっくり考えてみました。ちなみに、hcdvalue有志で翻訳したUX白書は一般公開されているので読んでもらえるといいかもしれません。(原文・サマリー資料) UXユーザ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
ふりかえりカタログ / Retrospective Catalog
History_of_waterfall_append
LeanUX とこれからの HCD