Better Meetings, More ValueParabol gives structure to your meetings to get your team talking and moving forward faster
Parabol | Free Agile Meeting Tool for Remote Teams
Better Meetings, More ValueParabol gives structure to your meetings to get your team talking and moving forward faster
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万以上の決済が行われている。また、そのプロダクトは「
Spotify Modelは"アジャイルの涅槃"ではない
Spotifyでは、マネジメントと組織の動きは人を育てることによってチームとアジャイルの実践を支援している。しかし、Spotifyは"アジャイルの涅槃"ではない。継続的に成長し、変化し、新しいチームに分裂するような高い成果を産むチームに達するのは難しい。Spotifyのチームとリーダーシップのコーチを務めるJoakim Sundén氏は、ビジョンを持ち続け、小さなステップを刻みながら向かうことを推奨している。 Sundén氏はSpotifyでのスムーズに進まなかった問題やどのようにその問題を解決しようとしたのかについてLean Agile Scotland 2017で語った。InfoQはこのカンファレンスの模様をインタビューや記事で取り上げている。 InfoQはSundén氏にインタビューし、うまくいかなかったことが製品にどのような影響を与えたのか、Spotifyでエンジニアリングマネージ
われわれはなぜアジャイルに向かうのか
1. Toshihiro Ichitani All Rights Reserved. われわれはなぜ アジャイルに向かうのか Ichitani Toshihiro 市⾕聡啓 開発をアジャイルにしていくために 読むべき最初の⼿引き 2. Toshihiro Ichitani All Rights Reserved. http://about.me/papanda0806 Ichitani Toshihiro 市⾕聡啓 ソフトウェア開発16年 SIer→サービス→受託→起業 仮説検証とアジャイル開発 ギルドワークス株式会社 代表 株式会社 エナジャイル 代表 ⼀般社団法⼈ 越境アジャイルアライアンス代表理事 DevLOVE コミュニティ ファウンダ 0 → 1
Reasons to Estimate During Planning Poker with the Whole Team
A well-established best practice is that those who will do the work, should estimate the work, rather than having an entirely separate group estimate the work. But when an agile team estimates product backlog items, the team doesn’t yet know who will work on each item. Teams will usually make that determination either during iteration (sprint) planning or in a more real-time manner in daily standu
Pragmatic Daveに質問: アジャイルよりも敏捷性
今月前半、アジャイル宣言の共著者であるDave Thomas と Martin Fowlerの2人が GOTOデンマークの一連の会議でパネルディスカッションに参加した。パネルは“アジャイル宣言のやり直し”を中心としていた。これはDaveの最近のブログ記事、『アジャイルは死んだ (敏捷性万歳)』から着想を得たものである。この記事は3月に公開されて以来、興味深いディベートやディスカッションを生み出してきた。 本 Q&A は、Pragmatic Daveとして広く知られているDaveが自身の考えを説明するものである。テーマは、当パネルディスカッション、彼のブログ記事、そして、アジャイルについてあまり重点を置かず、敏捷性の実際的な適用に重点を置くべき時だと彼が信じるようになった理由についてである。 InfoQ: ごく最近までアジャイル関連のイベントに参加してこなかったのはなぜでしょうか？ それは元
「組織パターン」で未来をあぶり出す！
ある日突然、業務知識もない、人脈もない、基礎的な素養もない部署に異動することになったら、あなたならどうしますか？そして、その事業が15年連続右肩下がり業界としたら、あなたは何から手を付けますか？そんなピンチな私の杖になってくれたのは、アジャイルの鉄人たちの教えでした。 業務改善をしたいけれど、どこから手を付けていいかわからないと思っている方に、未来会議というフレームワークとそのダンドリを「XP祭り2014」でお話させていただきました。何かの参考になれば幸いです！
コーディングにおける「深いレベルの『創造』」について - irohiroki's blog 2
12月8日、渋谷で開催されたAgile Samurai Boot Campにサポーターとして参加した。本編の中でも参加者の質問などを通じて学ぶことがあったのだが、今回はその話ではないので割愛する。ただ、そのような経験をできたのは主催の西村直人さん／永和システムマネジメントや会場提供のサイバーエージェント様、スポンサーのCodeIQ様、それから参加者とスタッフの皆さんのおかげなので、この場を借りて感謝致します。ありがとうございます。 さて、事件（私にとってはちょっとした事件だった）は打ち上げ会場の土佐料理店「祢保希（ねぼけ）」で起こった。私の斜向かいには@t_wadaがいらっしゃって、宴会の終盤まではイベントの内容をふりかえったり言語処理系やライブラリの話を聞かせてもらったりしていた。話が途切れたときに思い出したことがあったので、聞いてみた。 最近僕はパターン・ランゲージに強い興味を持ってい
ダメなデイリースタンドアップについて。 - Sooey
ダメなデイリースタンドアップについて。 CarbonFiveのブログにWhy Your Daily Standup Sucks (and how to fix it)といういいエントリがあったので、ポイントを簡単に訳して紹介しておきます。 詳細を話しすぎる 誰かが詳細を聞きたがったら、それはスタンドアップの後で話し合え みんな準備不足 毎日同じ時間にやることがわかっているのだから、準備をしたうえで時間通りに参加しろ スタンドアップの前に記録した作業時間、コミット、作業中のストーリーを確認しておけ 問題解決しすぎ デイリースタンドアップでは状況のアップデートだけをせよ 議論や問題解決をするときではない 合言葉は"take it offline" 障害を取り除こうとせよ スタンドアップの「あと」で障害に取り組め 誰かから「それについては力になれるよ」と聞ければ充分 ホワイトボードをスタンドアッ
リーン開発の現場 カンバンによる大規模プロジェクトの運営 | オーム社eStore(β)
「RPSは、スウェーデンの国家警察機関だ。僕らはそこで、PUSTと呼ばれる新しいデジタル捜査報告システムを開発している」（本文より） 本書は、アジャイルソフトウェア開発手法のひとつであるリーンソフトウェア開発手法を解説した、Henrik Kniberg, “Lean from the Trenches: Managing Large-Scale Projects with Kanban”の日本語翻訳版です。 官公庁の大規模システム開発プロジェクトにおける著者の経験に基づき、理論だけではなく、開発の現場で実際にどのように適用するかを、カンバンシステムを軸にしたプロジェクト進行の様子を描写しつつ、直裁的に解説しています。 リーンソフトウェア開発について、実践的な内容を求めていた方、これから現場へ導入したい方にお勧めの一冊です。 このような方におすすめ リーンソフトウェア開発を実践したいと考えて
アジャイルに限らず開発手法の議論は不毛になりやすい理由 - GoTheDistance
アジャイル開発に対する論争が盛り上がってるので、僕も便乗しまーす。新野さん、秀逸なまとめありがとうございました。 「アジャイルがダメだと思う7つの理由」から始まったアジャイル論争の現時点のまとめ － Publickey 僕も２年半前にアジャイルって受託開発との相性が最悪な気がする - GoTheDistanceという記事を書きました。アジャイル開発ってかなり牧歌的なので、内部ならまだしても外部の仕事を請けてキチンと回すのは難しいのではと書いたら、多くの方が「そりゃそうよ」と反応してくれました。その頃から、これを"ケツカッチン"な仕事で行うのは困難だと感じておりました。コミュニケーションが密に取れないと動けないじゃん。 議論の軸をもっかい振り直すと、アジャイルが確約出来る内容はあくまで人材育成・組織風土形成という不定形なサービスでしかないんじゃないでしょうか？ アジャイルな組織になりたいから
「アジャイルがダメだと思う7つの理由」から始まったアジャイル論争の現時点のまとめ
「アジャイルがダメだと思う7つの理由」という刺激的なタイトルのエントリを、先週木曜日、3月21日にグロースエクスパートナーズの鈴木雄介氏が公開してから、アジャイル開発に関する議論の波紋が広がっています。 おそらく、これだけさまざまなブログを通じてアジャイル開発の議論が活発化したことはこれまで国内ではなかったのではないでしょうか？ ここでは現時点での議論をまとめますが、興味のある方はぜひここを起点にそれぞれのエントリを読んでみていただきたいと思います。 発端は鈴木雄介氏（id:arclamp）のブログarclampにポストされた「アジャイルがダメだと思う7つの理由」というエントリ。以下がその7つの理由として挙げられたものです。 1.全体スケジュールにコミットできない 2.アーキテクチャ上の無駄が生じる 3.コーチって何だよ 4.変化ヲ抱擁スルために固定化している 5.実証主義的な説明に過ぎな
「アジャイルがダメだと思う7つの理由」は所変われば見方が変わる - koeだめ 過去アーカイブ[〜2013-12-14]
アジャイルがダメだと思う7つの理由 - arclampを読み、http://thata.tumblr.com/post/45971492307/7-97に触発されて、ムズムズしてきたので、自分の目線では各項目がどのように見えるのか語りたくなってきました。 どういう所の話か 場所：事業会社で新しい事業を立ち上げて営んでいるところ 事業：一種のB to B to C メンバー：営業面で動く人：3人、コード書いたりクリエイティブ作ったりする人：3人 1.全体スケジュールにコミットできない そのときに「やってみなきゃ分からない」なんて言えるわけでない。 については、「やってみなきゃ分からない」と言い捨てて終わるのは無い*1ですね。なんにも解決しません。 プレゼンテーションの工夫として「やれます(ｷﾘｯ」ということだってありますが、それはそれで、そう言い切って終わるとかももちろんありません。 自分た
![「アジャイルがダメだと思う7つの理由」は所変われば見方が変わる - koeだめ 過去アーカイブ[〜2013-12-14]](https://cdn-ak-scissors.b.st-hatena.com/image/square/48f87ca97e5c9c1b47f8dda5ff18b06f360f4da1/height=288;version=1;width=512/https%3A%2F%2Fogimage.blog.st-hatena.com%2F17680117126976353052%2F17680117126976357023%2F1550818882)
アジャイルがダメだと思う7つの理由 - arclamp
1.全体スケジュールにコミットできない アジャイルはタイムボックス型（一定期間で棚卸しをして、それを繰り返す）のマネジメントをする。だから、全体としての計画は立てられない。「だって、最初に全ての機能を洗い出せないでしょ」というのは分かる、分かるけど全体の計画は立てないといけない。経営者は顧客やVCと全体の計画にコミットしなきゃいけないんだ。そのときに「やってみなきゃ分からない」なんて言えるわけでない。 てか「やってみなきゃ分からない」なんてことは誰でも知っているんだよ。でもさ、それを言わぬが花。大人なんだからコミットメントをしないといけないんだよ。そして、その達成ためには、あらゆる手段を尽くすのです。 2.アーキテクチャ上の無駄が生じる ソフトウェアの構造や構成は工程が進むほどに修正しにくくなり、ずっと残る。だから、アーキテクチャ設計は慎重に全体を考えながらやらなきゃいけない。でも、アジャ
DeNA流Scrumとcommのチームビルディング
Scrum Alliance Regional Gathering Tokyo2013でDeNA貝瀬、高坂、坪田が発表した際の資料です。
いつまで開発のやり方ばっかり語ってるの？ #sgt2013
DOWNLOAD THIS BOOKS INTO AVAILABLE FORMAT (Unlimited) ......................................................................................................................... ......................................................................................................................... Download Full PDF EBOOK here { https://tinyurl.com/y6a5rkg5 } ........................................
アジャイルサムライとは大きく異なるソニックガーデンの見積りと計画作り - give IT a try
はじめに アジャイル開発に興味を持っている人に取っては「まだ読んでなかったの？」といった感じかもしれませんが、先日書籍「アジャイルサムライ」を借りたので、ざっくりと読んでみました。 今回のエントリは読んでみた感想に加えて、ソニックガーデンでの開発スタイルとの比較をしてみたいと思います。 アジャイルサムライ−達人開発者への道− 作者: Jonathan Rasmusson,西村直人,角谷信太郎,近藤修平,角掛拓未出版社/メーカー: オーム社発売日: 2011/07/16メディア: 単行本（ソフトカバー）購入: 42人 クリック: 1,991回この商品を含むブログ (257件) を見る とりあえず最初から読んでみた 1章の内容はアジャイル開発の基礎知識が中心で、読みながら「うん、まあそうだよねえ」と思いました。 14ページの挿絵にある「やり方がたった1つなんてことはないんだ！」「君自身が編み出
高速で無駄のないソフトウェア開発を実現するための7つのポイント | Social Change!
どうすれば小規模なチームでも大きな成果を出せるのか。大きな組織で沢山の量をこなすのは当たり前のことで、あまりクールではありません。少ない人数でも大きな成果を出すには、スピードをあげることと、そのためにも無駄をなくすことがポイントになってきます。 ソフトウェアをつくるための３つの役割で書いた通り、ソフトウェア開発をクラウドのようなサービス提供で続けていくには、プロダクトオーナーとプログラマーがキャッチボールのような形で、仕様と実装をずっと繰り返しながら作っていくのが自然です。 SonicGardenで使っているツールと開発の流れの全体は以下のようになります。大事なことは「動くソフトウェア」の状態を保ったまま、どれだけ回転数をあげていけるか、ということです。そのために、プロダクトオーナーとプログラマの間で待ち時間を減らすために並行して進めるようにするなど工夫しています。 ホワイトボードとMVP
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
アジャイルマネジメントとマインドセット 〜ヒーローを待っていても世界は変わらない〜
アジャイル開発会議で多くの優れた成果が発表される
