ベロシティ Deep Dive。スクラムにおけるベロシティのアンチパターンと適切な使い方とは（前編）
開発プロジェクトにおいて、開発スピードを測る尺度としてよく使われるのが「ベロシティ」です。このベロシティによって示される数字を適切に扱い、開発に活かしていくにはどうすればよいのでしょうか。 そのことを詳しく株式会社アトラクタ 吉羽龍太郎氏のセッション「ベロシティ Deep Dive」が、1月に都内で開催されたアジャイル開発の代表的な方法論であるスクラムをテーマにしたイベント「Regional Scrum Gathering Tokyo 2024」で行われました。 吉羽氏のセッションの内容をダイジェストで紹介しましょう。 本記事は前編、中編、後編の3つに分かれています。いまお読みの記事は前編です。 これから「ベロシティ Deep Dive」ということで「ベロシティ」についてお話をしていきたいと思います。 ベロシティを使っているっていう方、会場にどれぐらいいますか？ （手が挙がる） 結構多いで
【2024年版】プロジェクト管理システム・ツール おすすめ10選！脱エクセルでスムーズな工程�・進捗管理
ブログプロジェクト管理【2024年版】プロジェクト管理システム・ツール おすすめ10選！脱エクセルでスムーズな工程�・進捗管理 こんにちは。マニュアル作成・ナレッジ共有ツール「NotePM」ブログ編集局です。 企業がひとつの目標に向かって効率的かつ、生産的に取り組むには「プロジェクト管理」が不可欠です。従来のプロジェクト管理では、エクセル（Excel）で課題管理や進捗管理をされている方も多いと思いますが、プロジェクト管理ツールを導入する事によってさまざまなメリットがあります。 この記事では、プロジェクト管理ツールのメリット、おすすめツールなどをご紹介します。また、プロジェクト管理で活躍する「ITツール」を以下でまとめていますのでご一読ください。 【2024年版】社内wikiツール おすすめ15選（有料・無料） 【2024年版】ナレッジ共有ツール タイプ別おすすめ 10選 プロジェクト管理ツ
日本にアジャイルが普及しづらい本当の理由〜不確実性に向き合うマネジメント論〜 - Qiita
はじめに こちらの記事は、技術評論社に寄稿させていただいた「エンジニアリング組織論への招待」をご紹介するための文章です。Qiitaにも再掲しておきます。 アジャイルって何だ？ 「ウォーターフォールよりもアジャイルのほうがいいのか？」そんな言葉をIT企業の経営者から聞くことがあります。2000年代の後半くらいから、日本国内においてもアジャイル型の開発プロセスが注目を浴びて、多くの企業が実践するようになりました。 ところが、世界各国に比べて日本のアジャイル型開発の普及率は依然として低く、理解度も進んでいません。流行っているからやってみようと始めた企業も流行りが変わると今度はリーンだとか、今度は○○だといったように新しい方式を導入してみては失敗するところも珍しくありません。 アジャイル開発の専門家ですと名乗る人の話を聞いてみても、それが何なのか、けむにまかれたような説明をされてしまい、いまいち納
asanaのBoard Layoutでカンバンとスプリントの運用を始めてみた - tehepero note(・ω<)
2016 - 12 - 20 asanaのBoard Layoutでカンバンとスプリントの運用を始めてみた プロジェクト 開発 asana 表題の通り、asanaのBoard Layoutでカンバンとスプリントの運用を始めてみました。 動機 JIRA に疲れてしまった JIRAは社内で用意してもらってるオンプレだが、ネットワーク的に閉じられてしまうため他の サードパーティー のサービスとの連携がつらい といったとこです。というわけで今回はasanaを導入してみることにしました。 asana asana.com asana（アサナ）とはプロジェクト管理ツールで、15人までは課金しないで利用できます。ウチもまだ課金はしてないけど、機能解放したくなったら課金すると思う。 基本的な考え方 Organization: asanaを利用する組織。基本的に ドメイン 単位になるので、Organizati
長く使えるプロジェクト管理ツール厳選レポート2017
こんにちは。デザイナーのいしかわです。プロジェクト管理ツールマニアです。 理想的なプロジェクトマネジメントに向けて、これまでにプロジェクト・タスク・情報共有・進捗管理などに関するツールを30以上試してきました。その中から特におすすめしたい厳選ツールを7つ紹介したいと思います。 プロジェクト管理ツールを乗り換えるのは大変なので、できるだけ長く使い続けられるものを見つけたい！という気持ちで本気で評価しましたが、あくまでも自分で使ってみた感想になるので、人によっては合う合わないがあると思います。プロジェクト管理ツールの選定の参考になれば嬉しいです。 ※本エントリー更新時点での情報になりますので、機能や価格などの情報は異なる可能性があります。 ※2016/2/21 Asanaを追加しました ※2016/9/4 各ツールの最新情報をチェックし内容を更新しました ※2017/1/13 各ツールの最新
GitHub Project機能が強化されたのでZenHubから移行することを検討してみた | feedforce Engineers' blog
こんにちは!新卒エンジニアのtsubです! 本日Appleから新型のMacbook Proが発表されたということで早速ポチりました。Touch barのハックにワクワクしております。 そして同じく本日GitHubでProject機能が強化されました。 Introducing Projects for Organizations 私が所属しているチームではZenHubを利用しています。GitHubのProjectはZenHubのBoardに近い機能です。 できることなら余計な拡張など入れずにGitHubを純正で使いたいため、今回も移行を検討してみました。 前回の移行検討のおさらい 知っての通り、GitHubのProject機能は以前からリリースされています。 リリース当時にも移行を検討しましたが、その時は見送りという形になりました。 弊社エンジニアの @yukiyan が検討してくれた記事は
BacklogチームがScrumを始めてみた話 | 株式会社ヌーラボ(Nulab inc.)
私達Backlog開発チームでは2016年1月から現在まで約3ヶ月、アジャイル開発手法のScrumに取り組んでいて、それなりに成果がでているように思います。理想的に上手く行っているという程ではありませんが、その試行錯誤の様子について書くことにしました。Scrumに興味がある方の参考になれば幸いです。 ※なお、私達の製品であるタスク管理ツール「Backlog」とScrum用語の「バックログ」が紛らわしいので、製品のほうはアルファベット、Scrum用語のほうはカタカナで表記しています。 もくじ 発端 目的 準備段階 第1回計画ミーティング 見積もり スプリントでの作業範囲決定 最初期（1回〜3回） すぐに発生した問題 最初の頃の感想 試行錯誤期（4回〜現在） 専門家に意見を聞いた 1週間スプリント ポイント見積もり・ベロシティ ケーキ 詳細見積もりによる精度向上 助けたこと／助けられたこと 実
開発の見積もりとスケジュール管理 - クックパッド開発者ブログ
こんにちは。会員事業部の丸山です。 エンジニアが開発を開始する時にはタスクの見積もりとスケジュールを作成行って、実装を進めていくと思います。 しかし1ヶ月を超えるような規模の開発をする場合、なかなか予定通りの期日に終わらなかったりすると思います。 そして大抵の場合、増える方向になりますよね。 今回はそういうことにならないために、私が気をつけていること・実践していることをいくつか紹介したいと思います。 見積もりとは まずは「見積もり」とは何なのかを正しく理解したいと思います。 一般的には「見積もり」＝「全タスクとその工数を洗い出す」というものだと思います。 しかしここで以下のことに気をつける必要があります。 見積もりとスケジュールとコミットメントは違う 見積もりとはあるタスクがどれだけの工数(規模)なのかを算出することです。 対して、スケジュールとはあるタスクがどれだけの工期(期間)なのかを
プレイドが採用したタスク管理ツール8選 | PLOG
プレイドでは、CTOの柴山が常に海外のサービスに目を光らせていることもあり、 新しいサービスやツールを積極的に取り入れて開発に生かしています。 今回は、その中でもタスク管理ツールに焦点をあてて、 プレイドの開発環境を初めて紹介していきたいとおもいます。 現在採用している管理ツール 1,GitHub issue イシュー管理ツール https://github.com/ 多くの企業が採用している「GitHub issue」。 もはや説明の必要がないと言ってもいいツールでしょう。 プレイドでも、いわずもがなのタスク管理のベースとなっています。 ソース、コミットと紐付いているので開発のリズムが取りやすいところが採用の決め手です。 2,Codetree リスト、カンバン管理ツール https://codetree.com/ 「GitHub issue」に足りない一覧性を提供してくれる「Codetr
マイクロソフト、軽量なプロジェクト管理ツール「Office 365 Planner」をプレビュー公開
マイクロソフトはチームのコラボレーションを促進する軽量なプロジェクト管理ツール「Office 365 Planner」のプレビュー版を公開したと発表しました。 Office 365 Plannerは、プロジェクトに相当する「プラン」を作成するごとに1枚の「ボード」画面が作成され、チームで共有されます。ボードには、「カード」の形で情報が貼り付けられます。 下記はOffice 365 Plannerを紹介したブログ記事「Introducing Office 365 Planner」から、マーケティングキャンペーンの画面です。マーケティング予算のグラフ、広告の画像など、さまざまなカードが貼り付けられています。 カードにはそれぞれドキュメントや画像が含まれており、カードにはその内容を分かりやすく示す画像が表示されます。カードはカテゴリごとに縦方向に整理されて表示されます。 またOffice 365
ガントチャートの功罪 〜 新規事業で工程表を作ることに意味はあるか？ | Social Change!
「納品のない受託開発」を通じて、新規事業におけるソフトウェア開発を手伝わせて頂いていることもあり、そこで得た知見を活かして新規事業の審査員のような仕事をさせて頂くことがあります。 そこで審査のために提出された資料の中にあるガントチャートや工程表を見るとき、いつも違和感を感じていました。この記事では、ガントチャートが新規事業においては有効ではないという気付きについて書きました。 ガントチャートは決められた工程の管理をするのに最適 ガントチャートや工程表は、あらかじめ完成品が見えており、工程がはっきりしたものを「製造」していくときに非常に役に立ちます。どの工程にどれくらいの工期がかかるのか見えるようにすることで全体の計画が把握できます。 ガントチャートを有効に使うためには、きちんと工程を分解できること、とりかかる工程の順番がはっきりしていること、それぞれの工程にどれくらいの期間がかかるのか見積
Redmineはプロジェクトを横断して使うべきか否かという議論の感想 - プログラマの思索
Redmineはプロジェクトを横断して使うべきか否かという議論をTogetterにまとめた。 過去の僕の経験を踏まえながら、Redmineの運用スコープはどこまでなのか、を振り返ってみる。 ラフなメモ書き。 【元ネタ】 Redmineはプロジェクトを横断して使うべきか否か - Togetterまとめ 【1】当初は、メンバー3人で、短期間の受託開発案件をこなしていた。 その時、Redmineを導入して、Redmineの機能を一つずつ試しながら、アジャイル開発の実現方法を習得していった。 少人数のメンバーで1個のチームだけだから、イテレーションごとにRedmineの運用ルールを軌道修正して、アジャイル開発のプラクティスを1個ずつ試していけた。 一番の発見は「イテレーション・リリースバージョン・マイルストーン一致の原則」と「プロジェクトとブランチ一致の原則」だった。 「イテレーション・リリースバ
複数人でのプロジェクトマネジメントに速攻で同期できる「かんばん」を使えるサービス「Taiga」
トヨタが考案した「かんばん方式」は、生産計画に応じて必要なものを必要なときに必要なだけ供給でき生産効率が向上するため自動車の製造に限らず製造業一般に普及し、現在ではプログラムマネジメントの手法の一つとして広く採り入れられています。そのかんばん方式を使って複数人で取り組むプロジェクトをオンライン上でマネジメントできるサービスが「Taiga」です。 Taiga.Io | Agile, Open Source, Free Project Management System https://taiga.io/ ◆アカウント登録 上記サイトページの下にある「SIGN UP」をクリック。 TAIGAのアカウント登録画面になるので、ユーザーネーム・公開ネーム・メールアドレス・パスワードを入力したら「SIGN UP」をクリック。 無事、サインアップが終わるとこのようなサインイン画面になります。なお、複数の
夏サミ 2014 『KDDIのAgile&DevOpsへの挑戦と戦果』聴講メモ #natsumi - べにやまぶろぐ
今回は業務都合で残念ながら午前の部は参加できなかったのでセッションは午後から。結局今回はずっと B ルームにいたので主なテーマはアジャイルと DevOps でした。 というわけで最初のセッションは こちら です。 「KDDIのAgile&DevOpsへの挑戦と戦果」 川上 誠司 氏〔KDDI〕 アーサー・C・クラークの三法則 「高名だが年配の科学者が可能であると言った場合、その主張はほぼ間違いない。また不可能であると言った場合には、その主張はまず間違っている。」 => 年配の開発者(=上司)とも読み替えられる WF 開発の限界を感じていた Ray L. Birdwhistell によれば言語コミュニケーションで伝わるのはせいぜい35%程度の情報（３回ホップすればおよそ5%まで減衰してしまう）。 ５年で 10 億かけたシステムをハードウェア EOSL 起因で移行(Linux のポーティング)
アジャイルをスケールするための方法を探る
アジャイルをスケールするのはアジャイルコミュニティにとって大変なことだ。スケールするとはどういうことなのか。どのように実現するのか。フレームワークや手法はどのようなものがあるのか。アジャイルをスケールすることに挑戦するのは、問題の兆候となる場合もある。小さなチームから組織全体のアジャイル導入へ移行する自然な成長の場合もある。 このスケールの問題に対処するための手法はたくさんある。そして、どのような状況でどのような手法を使うかについて多くの混乱がある。 Richard Dolman氏とSteve Spearman氏は異なるスケール手法を紹介するウェブサイトと比較に使えるメトリクスを公開している。 彼らはこの比較サイトを作成した理由を次のようにいう。 コミュニティに次の3つを提供することが目的です。 可能な限り客観的な条件を加えた流行のアジャイルスケーリングフレームワークを比較するメトリクス。
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
大規模開発チームのマネージメント奮闘記 - Speaker Deck
Trelloに対抗、Microsoftの新たなプロジェクト管理ツール「Planner」が正式ローンチ | TechCrunch Japan
Redmineの運用が大規模化していく上での課題～@Will_meaningさんとのやり取り
re:workstyle
アジャイル移行におけるマネージャの役割