Scrumを破る話とその補足。Scrumありがとう、そしてさようなら -Scrum 破- #rsgt2017 で発表してた - うさぎ組
2017/1/13 に開催されたScrumのカンファレンスで「Scrumありがとう、そしてさようなら -Scrum 破-」というタイトルで45min話してきました。 スライドを公開するのずっと忘れていて、何度か再演もしているんだけど公開しました。2016年のチームの成果の話です。 speakerdeck.com カンファレンスのイベントページに書いたセッションの概要はつぎです。 Regional Scrum Gathering Tokyo 2017 - Scrumありがとう、そしてさようなら-Scrum 破- | ConfEngine - Conference Management Platform ScrumをScrum Guideに従ってやることから、次のステップに進んだ私がいるチームの事例発表になります。私達は2015年にテストやメトリクスを活用して、プロダクトにもプロジェクトにも透
フィボナッチ工数見積は「完成させます！（徹夜で）」という無理ゲーによる弊害を最小化するプロジェクトマネージメント手法 - ベルリンのITスタートアップで働くジャバ・ザ・ハットリの日記
今まで数々のプロジェクトマネージャーとそのプロジェクトマネージメント手法に翻弄されてきたが、現在の勤め先であるベルリンのITスタートアップで取り入れている手法が歴代の中でも一番マシ。まず工数見積がとても洗練されている。エンジニアが無理やりに「今週中に完成させます！」と言わされて、結局はその約束が守りきれずに翻弄される、というような弊害が最小化できているな、という話。 プロジェクトマネージメントチームのメンバー達はその見積方法を「フィボナッチ」と表現している。 だいたい工数見積なんてものが正確にできる人に出会ったことが無い。複雑なITプロジェクトの全体像を把握して「これをうちのチームで完了するためには＊＊日を要する」なんてピタッと当てたためしがない。絶対にズレる。 エンジニアに向かって「お前さー『今週中に完成させます』って言ったよな？誰だっけ、それ言ったの？オレじゃねーよ。お前だよ。おめーの
「開発をアジャイルで」「でも契約は一括で」と言ってくる顧客がいたらどうすべきか？ - ミッションたぶんPossible
はじめに このブログでは言及してませんでしたが、宣言どおり無事転職して、今年の1月から新宿のSIerで働いています。まぁその辺の話は来月あたりの暇な時にでも書くとして*1、今回は別の話。 ついこの間、その新会社で、PM的役割をこなす社員を対象に開かれた「法務研修」という名のついた社内セミナーに参加しました。内容は、SIerの立場で契約に携わる時にどうすべきか、というもの。SIerあるあるの契約にまつわる揉め事を事例に、それを回避するために何に気をつけるべきか、といったことが扱われました。まぁこれ自体は目新しい内容ではなく、SIerに所属する者なら当然知っておく・気をつけるべきことばかり。再確認という意味では非常に有意義でしたが、それ以上でもそれ以下でも無かったなぁ、というのがオレの率直な意見でした。……研修本編終了までは。 ちょっとこれ大丈夫か、と思ったのは、Q&Aに入ってから。社員の誰か
Microsoft Corporation
Microsoft Learn. Spark possibility. Build skills that open doors. See all you can do with documentation, hands-on training, and certifications to help you get the most from Microsoft products. Learn by doing Gain the skills you can apply to everyday situations through hands-on training personalized to your needs, at your own pace or with our global network of learning partners. Take training Find
バカは進捗が進んでも気づかない：101回死んだエンジニア：エンジニアライフ
いろいろな仕事を渡り歩き、今はインフラ系エンジニアをやっている。いろんな業種からの視点も交えてコラムを綴らせていただきます。 計画と願望は違う 何かしらのプロジェクトが立ち上がると、必ず計画表というのを作らないだろうか。最初に納期が決まっていて、納期までに何をどうしていくかという計画を立てる。Excelでやたら手の込んだ計画表をよく見る。やたらとセルの幅を弄っている割に、色のセンスが悪い。変に見た目ばかり作りこまれていて、更新は全部手動だ。こういうのを見るとプロジェクトの失敗が頭によぎる。 計画は進捗を判断する上で大事な基準になる。事前にしっかりと考える必要があるのだが、過去のプロジェクトで使用した計画をコピペして使う人が絶えない。毎度ながらアホだと思う。考える分の工数を省いた分、早く計画を立てることはできる。素早く計画を立てて頭の良さでもアピールしたいのだろうか。しかし、考えるべき時に考
サイボウズ kintoneチームの「改善」大公開！ 新人も巻き込んだスクラム導入の成果とは？｜ハイクラス転職・求人情報サイト AMBI（アンビ）
サイボウズ kintoneチームの「改善」大公開！ 新人も巻き込んだスクラム導入の成果とは？ 連載「若手エンジニア、どんな活躍してますか？」第4回は「kintone」「cybozu Live」などを運営するサイボウズ編です。「チームワークあふれる社会を創る」を理念として掲げるサイボウズで、若手エンジニアはどんな活躍をしているのか、伺いました。 若手エンジニアのための情報メディア「エンジニアHub」。連載「若手エンジニア、どんな活躍してますか？」第4回は「kintone」「cybozu Live」などを運営するサイボウズ編です。「チームワークあふれる社会を創る」を理念として掲げるサイボウズで、若手エンジニアはどんな活躍をしているのでしょう。 取材に応じてくれたのは、若手プログラマの前田浩邦（まえた・ひろくに）さんと、メンター役だった天野祐介（あまの・ゆうすけ）さん。2人が属するkintone
The Retrospective Starfish – thekua.com@rest
Diagrams are always useful focal points for starting discussions, and that’s one reason I like using the starfish diagram for a retrospective. This particular retrospective technique helps people by getting them to reflect on varying degrees of things that they want to bring up, without having it fit into the black or white category of ‘What Went Well’ or ‘Not So Well’ so I think it scales a littl
マネージャ 2.0: スクラムでのマネージャの役割
企業の世界において、マネージャの伝統的な役割は“指揮統制”として知られるモデルに基づいます。ここでのマネージャの役割は何をする必要があるかを特定し、従業員に詳細な指示を与え、従業員が確実にその指示に従って仕事を完了するようにすることです。このモデルでの従業員は単純に与えられた指示に従い、正しい仕事を正しい方法で完了するためにマネージャの判断と知恵を信じるだけです。 しかし、ソフトウエア開発のような複雑で変化の激しい環境ではこの手法は機能しなくなりやすいです。まず、マネージャがすべての要求の完全な細部まで理解し、従業員の仕事を指導するため正確な指示を出すのは難しくとても時間がかかります。ソフトウエア開発チームの仕事は相互の関連の度合いが高く、複雑に依存し合い、変化や予期しない驚きが頻繁に発生します。ひとりのマネージャがチームのためのすべての基本的な判断を下すことを期待するのは現実的ではありま
Scrum Primer - Short Introduction to Scrum
翻訳 Scrum Primer in Simplified Chinese Scrum Primer in Traditional Chinese Scrum Primer in German (Small file) Scrum Primer in French Scrum Primer in Spanish Scrum Primer in Italian Scrum Primer in Bulgarian Scrum Primer in Korean Scrum Primer in Vietnamese Scrum Primer in Russian (Small file) Currently In Progress: Japanese Thai Korean German Vietnamese This page is open source and contributions i
「アジャイルは死んだ」以降に残るものは何か -リーンソフトウェア開発を再評価し、自工程完結で全体観点で改善する - - Qiita
その結果、自分はすっかり言及の減ってしまったリーンソフトウェア開発や、それらの源流であるトヨタの生産方式、トヨタが現在取り組んでいる自工程完結を評価するのがよいのではないかと思い至った。本稿は、そういうポエムである。 本稿でいうリーン（ソフトウェア）開発とは何か？ 2003年にメアリー・ポッペンディークとトム・ポッペンディークにより提唱されたトヨタ生産方式を源流とするリーン生産方式をソフトウェア開発に適用した原則集。以下を指す。 リーンソフトウエア開発～アジャイル開発を実践する22の方法～ リーン開発の本質 エリック・リース氏のリーンスタートアップやオライリーのリーンシリーズとは異なるので注意いただきたい。 きっかけとしてのアジャイル方法論の違和感：結局、アジャイルでも多くの課題が残る。 「今回のプロジェクトがやりにくいのはウォーターフォールでやっているからだ」、「今回のプロジェクトが適当
スクラムの生みの親が語る、スクラムとはなにか？ たえず不安定で、自己組織化し、全員が多能工である ～ Innovation Sprint 2011（前編）
スクラムの生みの親が語る、スクラムとはなにか？ たえず不安定で、自己組織化し、全員が多能工である ～ Innovation Sprint 2011（前編） アジャイルなソフトウェア開発手法としてもっとも広く使われているのが「スクラム」です。このスクラムは、1990年代半ばにジェフ・サザーランド（Jeff Sutherland）氏らによって提唱されたものですが、その考え方の基盤となったのが1986年に一橋大学の野中郁次郎氏と竹内弘高氏が日本企業のベストプラクティスについて研究し、ハーバードビジネスレビュー誌に掲載された論文「The New New Product Development Game」でした。 1月14日にコミュニティが主催し都内で行われたイベント「Innovation Sprint 2011」は、このスクラムの生みの親と言える2人、野中郁次郎氏とジェフ・サザーランド氏がそれぞれ
あなたのチームのスクラムマスターがうまく作用しない7つの理由
アジャイル開発に取り組むチーム向けのコーチングや、技術顧問、認定スクラムマスター研修などの各種トレーニングを提供しています。ぜひお気軽にご相談ください（初回相談無料） みなさんこんにちは。@ryuzeeです。 7 Reasons Your Scrum Master May Be Underperforming より抜粋・意訳でご紹介します。 うまくいかないスクラムマスターのパターンは以下にあがっている以外にもたくさんありますが、個人的には、スクラムマスターがチームのファシリテーション役や問題の解決役にならずに、指示出し役になってしまっているケースが良くないケースだと思います。 往々にしてそういう場合はスクラムマスターがチームのメンバーよりも社内の役職上立場が上だったりもします。 スクラムで開発する場合、スクラムのロールの帽子をかぶる人は、少なくともプロジェクトの中では役職の帽子は脱いだほう
認定スクラムマスター取得しました！〜研修1日目〜 - スクラムマスダーの日記
11月、大阪で行われた認定スクラムマスター研修に参加しました。 その後のテストにも無事合格し、認定スクラムマスターになることができました。 スクラムを広めるという意味でも、認定スクラムマスター研修について、ブログで共有します。 全部書くと長くなるので、まずは1日目です。 講師：江端一将さん 期間：2016/11/9~2016/9/11(3日間) 参加人数：24名 研修1日目 研修の説明 一番最初に、研修の説明がありました。 認定スクラムマスター研修は、単に研修を受けて、その後のテストに合格すれば、誰でも取得できる資格ではありません。 3日間の研修期間で、江端さんから資格を与えてもよいかの判定をされます。 そして、江端さんから合格をいただければ、テスト受講資格を得て、テストに合格することで、認定スクラムマスターになれます。 昔は、研修を受ければ、自動的にテストを受けることができたそうです。
効果的なデイリースクラムのやり方に関するTips10個
アジャイル開発に取り組むチーム向けのコーチングや、技術顧問、認定スクラムマスター研修などの各種トレーニングを提供しています。ぜひお気軽にご相談ください（初回相談無料） ミーティングの前にタスクのステータスと残り時間を更新すること。これによってチームがどんな状況にあるかに関する最新のスナップショットを持っていることを保証する。ミーティング中に、ボードの更新に時間を使うべきではない 前回のミーティングから変わった点についてしゃべれるように準備しておくこと。チームにとって価値がある共有すべき情報は何なのか？について考えること。すなわちあなたが完了したことについて事細かにしゃべる必要はないということだ。他の人が聞く必要のある情報か、あなたがチームの助けを必要としている情報についてだけで良い 事実を提供することに集中することで話す内容を制限し、会話を簡潔に保ちなさい。ポイントは全員から聞くことだ。
社内でスクラムの勉強会を開催した！ - スクラムマスダーの日記
1ヶ月ぶりのブログです。 先週11/9~11/11は、江端さんが講師の認定スクラムマスター研修に参加してきました。 今まで、アジャイルやスクラムについては、色々と勉強してきたつもりでしたが、学びが非常に多く、一から勉強し直す点が非常に多かったです。 研修の内容は、またブログで紹介したいと思います。 研修で得た学びは、実戦で活かす必要があるので、会社で勉強会をしました。 内容は、アジャイルやスクラムの初心者向けです。 資料 Agile basic from Kentaro Masuda www.slideshare.net 開発フレームワークは、世の中には様々ありますが、どういった経緯で、どういう背景で誕生したのかを把握することは、非常に重要だと思います。 そして、それぞれのフレームワークを「正しく」把握することが非常に大事です。 スクラムマスターの役割として大事なことの1つとして、チームに
Roadmapping software | Atlassian
Use the board view to get everyone up to speed, so team discussions can focus on priorities that you’ve committed to now, next, and later. If you need to share rough dates, use the timeline view. Tailor the story Effortlessly create and publish custom views for different teams and stakeholders. Show ideas aligned to company goals to leadership, or plans for highly requested features to customers.
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Gil Ziberfeld氏に聞く - アジャイルにおける製品計画とその管理
リーンスタートアップと顧客開発とアジャイル開発を一気通貫するッ #devlove #devkan
The Scrum Guide
スプリントプランニングとプランニングポーカーのやり方 | Tech Blog | CRESCO Tech Blog