今知ってほしいプロジェクトマネジメントのもう一つの世界観 ~予測型と経験型~ - higosophy
主張 ソフトウェア開発prjがなかなかアジャイルにならないのはなぜかなぁと考えてみた。 昨今、エンジニアにおいては、知識としての共有の機会も増えているし、実際に経験済み、習慣化済みになってきているように思う。要は「しっくり」くることが多いのだと思う。 しかしながら、現実のprjが経験型のアプローチ(アジャイル)を取ることはまだまだ少ない。この要因として、エンジニアと協業する他のメンバー、あるいはprjの利害関係者(組織の上層部を含む)が予測型の進め方を望むからではないか、と感じている。 というわけで、エンジニアと仕事をするエンジニア以外の人に伝えたいと思い、書いてみる。そのためにはおそらく、アジャイル開発、スクラムのプラクティスがどうこう、というよりは、プロジェクトマネジメントの世界観として語る方がよいかというのが本稿。エンジニアとして、抽象的な「しっくり」の言語化にもなればよいと思う。最
スプリントに名前を付けると覚えやすいしやる気がでる - しるろぐ
単純に優先順に作業すると、いろいろやりすぎて思い出に残りにくいので、スプリントにタイトルを付けて、特定の何か（機能でもいいし方向性でもいいし）に集中したスプリントバックログを作ろう、みたいな話をする。 スクラムについて軽くおさらい スクラムでは、スプリントと呼ばれる大体1～4週間の短いタイムボックスを繰り返しながら開発を行う（うちは2週間）。 スプリントは、計画 -> 開発/スタンドアップミーティング -> レビューな感じで進んでく。 計画フェース 計画フェーズでは、スプリント期間に何をやるかを計画する。 ユーザストーリーを優先順に並び替えプロダクトバックログを作成する そこからチームがスプリント期間に達成できるユーザストーリーを選択する ユーザストーリーを実現するための作業をタスク化する（スプリントバックログ） スプリントバックログ上の作業を期間内に完了することをチームでコミットする 開
最近の開発フローの改善と、「スプリントおじさん」という取り組み - しるろぐ
ここ最近、自分が見ているプロジェクトの1つで、うまくスケジュール通りに作業が進んでいなかったので、その対策をした。 その中でも特に効果があった2つを紹介する。 背景 簡単にプロジェクトの背景を説明する。 スクラムっぽい開発をしている スプリントの期間は2週間 スクラムマスターはいるが専任ではない すでにリリース済みで運用中のWebサービスである 基本的によくあるスクラムっぽい感じで、2週間というタイムボックスの中にチームが作業可能なストーリーを突っ込んで、ひたすら消化する。 スプリントの最後には、レビューをして、次のスプリントの計画を立てる。 スクラムマスターは、一応自分が担当しているが、専任ではないし、他のプロジェクトも見ているので、注意深くチームを見れていない。 課題 以下のような課題があった。 バグの修正や問い合わせ対応など、計画時に含まれていなかったタスクがスプリント中に増えてしま
Agile Project Management
Proven project management for successful teams With a shared view of team priorities, a process that fosters collaboration, and dynamic tools to analyze progress, your team will deliver more frequently and consistently. Better organization to get focused Keep your team on the rails. Tracker's shared backlog makes priorities clear so the team can stay organized. Easily visualize scope, focus your t
ストーリーポイントに関する雑感 - ふり返る暇なんて無いね
ストーリーポイント見積もり確かになれないと分かりにくいと思うし、ストーリーポイントが何なのかを理解しないでやると"1日かかるものは5ptくらいだ"みたいにいつの間にか規模じゃ無くて工数に変換されてしまう。ストーリーポイントで見積もっている意味が無い。 相対規模で見積もることのメリットってやはり人の作業速度に依存しない見積もりができるってことじゃないかな。僕の1日と君の1日の長さを気にしなくて良い。 特に1イテレーションで達成できるポイントが可視化されるのでチームとしての成長見える。これが、理想日見積もりだと日数*人数の分のストーリーは消化できることは分かるけど、それが当初と比べてどれくらい成長できたか見えない。 チームとしての成長ってけっこうプロジェクトを成功させる重要なファクターだと思う。 とはいえ、実際に良さを実感しないと分かりにくいだけって言うのは分かるし、自分の考えを持っている人に
アジャイルがそんなにダメだと思わない7つの理由 - haradakiro's blog
鈴木雄介さんが、「アジャイルがダメだと思う7つの理由」というすごいブログを書いてくれたので、がんばって返答を書いてみる。どこかでディスカッションできるといいなぁ。 1. 全体スケジュールにコミットできない コミットメントって何だろう。コミットメントは約束なのか。約束であったら、破った場合のペナルティも受け入れるのか？受け入れたところでバッファが巨大になるだけではないのか？そして、そのバッファは見えないところで食い尽くされる。 全体を見えずに計画したところでうまくいくはずはない。アジャイルがタイムボックスで計画、実施を行うからといって、全体を計画しないわけではない。むしろ積極的にやるべきである。 全体を計画する上では、なるべく漏れがないように、実施可能なように最大限の努力をする。ただ、それに時間を掛けすぎるのは無駄だ。そして、神ならぬ人間が計画するのであるから、以下を認めなければならない。
アジャイルがダメだと思う7つの理由 - arclamp
1.全体スケジュールにコミットできない アジャイルはタイムボックス型（一定期間で棚卸しをして、それを繰り返す）のマネジメントをする。だから、全体としての計画は立てられない。「だって、最初に全ての機能を洗い出せないでしょ」というのは分かる、分かるけど全体の計画は立てないといけない。経営者は顧客やVCと全体の計画にコミットしなきゃいけないんだ。そのときに「やってみなきゃ分からない」なんて言えるわけでない。 てか「やってみなきゃ分からない」なんてことは誰でも知っているんだよ。でもさ、それを言わぬが花。大人なんだからコミットメントをしないといけないんだよ。そして、その達成ためには、あらゆる手段を尽くすのです。 2.アーキテクチャ上の無駄が生じる ソフトウェアの構造や構成は工程が進むほどに修正しにくくなり、ずっと残る。だから、アーキテクチャ設計は慎重に全体を考えながらやらなきゃいけない。でも、アジャ
DevOpsアンチパターンとは？
開発担当者と運用担当者が一緒に協力し、迅速に開発、リリース、フィードバックを回すことでビジネスを成功に導いていくという「DevOps」。もともとはFlickrやFacebookなどコンシューマ向けのオンラインサービス企業から登場した考え方ですが、いまではIBMなど企業向けのソフトウェア開発でもDevOpsを用いるベンダが登場してきています。 そのDevOpsで重要なのが、開発も運用も誰もが協力し合うというカルチャーを作り上げていくこと。Webサイト Agile Web Development&Operationsの記事「DevOps Anti-Patterns」では、これをやるとDevOpsが失敗するというアンチパターンを3つ挙げています。 3つのDevOpsアンチパターン アンチパターン1：コミットが“完了”／Committed is “Done” メンバー全員がタスクを終了させるとはど
タスクの書き方 - 終了条件と却下条件で判断を迅速に行う - しるろぐ
2年目の新人が去年1年間を振り返りつつ今年の新人にアドバイスする、という勉強会を社内でやっていて、拙いながらもそこで発表してきました。 いくつかアドバイスしたことがあるのですが、社内の機密情報なども含まれるので、一部だけ取り出してブログ用に書き直したいと思います。 今日のテーマは、タイトルにもあるとおり『タスクの書き方』です。 タスクを書くときに「○○をする。□□ができたらオッケー」という終了条件や、「○○をする。ただし△△になったら不要」という却下条件を書くと、タスクの選択や確認、棚卸しが捗るという話です。 大量のタスクがあると良く分からなくなる 仕事をしていると、次から次にやりたいことが沸いてきて、頭の中だけで整理するのは難しくなってきます。大抵の人は、やりたいことを紙にリストアップしたり、webサービスなどで管理したりすると思います。 しかし、何も考えずにタスクを追加していくと次のよ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
見積りと計画づくりの技術 / estimating-and-planning-technique