ムービングモチベーターズによるモチベーションの可視化 - Qiita
実施手順 事前準備 Management3.0のサイトから １０種類のカード をダウンロードし人数分プリントアウトしてカットし10枚1セットを作っておきます。 プリントアウトできる環境によるかもしれませんが可能ならカラーのほうが10種類が色分けされているので見やすいです。さらに可能ならカードになるような硬めの紙にプリントアウトしたほうが繰り返し使いやすいと思います。 場の設定 進め方にもよりますが十数分から数十分かかりますので会議室などに集まり1人ずつ席について行うのが良いでしょう。 テーマの確認 会社に対するモチベーションなのか、プロジェクトに対するモチベーションなのかなど、テーマによってモチベーションは変わるのでまずはテーマを共有しメンバー全員で認識を合わせます。 カードの並び替え 全員にカードを配り、10種類のカードの並び替えを行います。モチベーションが上がるキーワードを上に、上がら
今知ってほしいプロジェクトマネジメントのもう一つの世界観 ~予測型と経験型~ - higosophy
主張 ソフトウェア開発prjがなかなかアジャイルにならないのはなぜかなぁと考えてみた。 昨今、エンジニアにおいては、知識としての共有の機会も増えているし、実際に経験済み、習慣化済みになってきているように思う。要は「しっくり」くることが多いのだと思う。 しかしながら、現実のprjが経験型のアプローチ(アジャイル)を取ることはまだまだ少ない。この要因として、エンジニアと協業する他のメンバー、あるいはprjの利害関係者(組織の上層部を含む)が予測型の進め方を望むからではないか、と感じている。 というわけで、エンジニアと仕事をするエンジニア以外の人に伝えたいと思い、書いてみる。そのためにはおそらく、アジャイル開発、スクラムのプラクティスがどうこう、というよりは、プロジェクトマネジメントの世界観として語る方がよいかというのが本稿。エンジニアとして、抽象的な「しっくり」の言語化にもなればよいと思う。最
デブサミで、『インパクトマッピング』のお話をしました！：An Agile Way：オルタナティブ・ブログ
Impact Mapping from Kenji Hiranabe 今日、11年目のデブサミにて、「インパクトマッピング」の講演をしました。その資料をアップロードします。 インパクトマッピングは、イギリスの Gojko Adzic (『Specification by Example』の著者)の近刊です。 製品やWebサービスを開発するとき、ビジネス企画の意図をどのように開発に伝えますか？仕様書を書く？それで伝わりますか？ビジネスの変化に追従できますか？ インパクトマッピングは、ビジネス視点と技術視点、さらにはデザイナーという異なる文化をもつ人間どうし会話をするために、目標とそれを達成するための仮説をビジュアルにマインドマップで表現して、企画の意図を共有します。 中心(WHY) = ビジネス目標。 第一レベル(WHO)＝アクター。目標を達成するために、誰に働きかけるか。 第二レベル(HO
受託開発にアジャイルは適用できるか？
3つの大事なこと まず全ての受託開発に適用できるかというと、それは難しいと考えています。 これまでクレイに発注いただいた開発で、次のような案件に適用してきました。 Webサービス スマートフォンアプリ プロトタイプ、研究開発 要件が曖昧だったり、仕様が変わりやすいもの、市場の変化が大きいものなどですね。 次に規模ですが大きくても3，4人で半年から一年程度の小規模な開発が多かったです。 ただこれまでいくつかのプロジェクトを進めてきて、向き不向き以上に大事なことがあるとわかりました。 特に次の3つが進めていくために大事なことと感じています。 クライアントにプロジェクトに責任を持って参加してもらう アジャイルに適した契約にする 開発プロセスを出来るだけ透明化する クライアントにプロジェクトに責任を持って参加してもらう 「クライアントにプロジェクトに責任を持って参加してもらう」とはどういうことでし
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
開発以外でアジャイルを実践する
