masudaKさんのQlip

  • masudaK

    19ページ

    ピラミッドの鉄則はかなり具体的ですので、自分が何を言いたいかが書く前にわかっていさえすれば、正しいピラミッドのを作ることは比較的容易です。しかし、書く前に自分の考えを明確に認識している人はほとんどいません。うまくいかない原因はここにあります。

    考える技術・書く技術―問題解決力を伸ばすピラミッド原則 考える技術・書く技術―問題解決力を伸ばすピラミッド原則 バーバラ ミント
    masudaK
    9ヶ月前

  • masudaK

    134ページ

    それに、真剣に相対サイズでの見積りに取り組んでいれば、単位が何なのかなんて気にならない。大事なのは見積もったストーリー同士のサイズを、それぞれのあいだできちんと相対的な大きさとして表現できているかどうかなんだから。見積りが相対サイズになっていれば、ストーリーのひとつひとつには過大見積もりや過小見積りがあったとしても、全体としての辻褄は合うはずなんだ。
    見積もりの単位にポイントを採用することには、次のようなメリットがある。
    ・見積もりとは当てずっぽうであることを肝に銘じることができる。
    ・見積もりとは純粋に大きさを測るものだと考えることができる（そのほうが見積り結果の賞味期限が長い）
    ・手早く、気軽に、シンプルに見積もれる。
    さまざまな調査結果からも、このやり方ならうまくいくことがわかっている。

    アジャイルサムライ−達人開発者への道− アジャイルサムライ−達人開発者への道− Jonathan Rasmusson
    masudaK
    9ヶ月前

  • masudaK

    127ページ

    私たちには、次の3つの条件を満たすような見積もり手法が必要だ。
    ・今後の計画を立てられる
    ・見積もりは当てずっぽうだという前提を踏まえている
    ・ソフトウェア開発の複雑さを認めている

    アジャイルサムライ−達人開発者への道− アジャイルサムライ−達人開発者への道− Jonathan Rasmusson
    masudaK
    9ヶ月前

  • masudaK

    120ページ

    フローチャートと、それに対応するざっくりしたペーパープロトタイプがあれば、アプリケーションの中核をなすユーザーストーリーのほとんどを導き出せると思う。ユーザーストーリーの抽出にあたっては、小さくて、具体的な、エンド・ツー・エンドの機能にすることを心がけよう（1日から5日で実装できるサイズを目安にしよう）。もちろん、なかにはもっと大きなストーリーもあるだろう。目安としては、実装に数週間かかりそうな大きさであれば、エピックとして扱う。
    エピックはざっくりとした計画を立てるときには扱いやすい。また、大きなストーリーで、多分やらないといけないんだろうけども、本当に必要なのかはまだ確信が持てないものを括り出しておくにも便利だ。もし主要な機能がエピックになっていたとしても、他のストーリーと同じように扱おう。もちろん、そのエピックを実際に開発することになれば、そのときには複数のストーリーに分割しなきゃ実装はできないだろう。
    ストーリー収集ワークショップでは、一日かけて開催した場合で、ざっくりとしたストーリーを10~40ぐらい書きだせば十分だろう。これぐらいあれば、向こう3ヶ月から6ヶ月ぐらいの計画を立てられる。書きだしたストーリーが数百もあるのだとしたら、それは半年以上先の遠くまで計画を立てようとしているか、詳細に立ち入りすぎているかのどちらかだ。今の時点で優先すべきは幅だ（深さじゃない）。深みにはまって身動きが取れなくなっちゃいけない。

    アジャイルサムライ−達人開発者への道− アジャイルサムライ−達人開発者への道− Jonathan Rasmusson
    masudaK
    9ヶ月前

  • masudaK

    95ページ

    進軍指令が誰から来ているのかがわからない状況ほど現場を混乱させるものはない。＜中略＞チームの向かう先や、仕事の優先度、次のやるべきことについて、異なった思惑を持ったステークホルダーが何人もいて、それぞれがチームに言い寄ってくる状況だとしたら、それはまずい。バスの運転手は誰なのか？そのことをあらかじめはっきりさせておこう。ただしこれは、運転手以外のステークホルダーに発言権が一切ないという意味じゃない。むしろそんなことはあっちゃいけない。ただ、開発チームに語りかける声は一つにしておきたいというだけの話しだ。プロジェクトの今の段階で、誰が決断を下すのかということを確認しておけば、後で起きることになるであろう様々な混乱を防ぐことができる。高くつく手戻りや再調整も避けられるはずだ。

    アジャイルサムライ−達人開発者への道− アジャイルサムライ−達人開発者への道− Jonathan Rasmusson
    masudaK
    9ヶ月前

  • masudaK

    86ページ

    太古の昔より、あらゆるプロジェクトは4つの固く結びついたフォースによって統治されておる。それが荒ぶる四天王、すなわち時間、予算、品質そしてスコープだ。どんなプロジェクトにも奴らが待ち受けており、いつも必ず破壊と混乱を引き起こすのだ。すなわち、
    ・スケジュールは圧縮される
    ・予算は削減される
    ・バグのリストは長くなる
    ・やるべきことは際限なく湧き出してくる

    荒ぶる四天王のパワーは圧倒的だ。しかし、彼らを手なずけることもできる。そのためには、プロジェクトにおいて四天王の一人一人と調和を保ちながらうまく付き合っていく方法を学ばねばならん。

    アジャイルサムライ−達人開発者への道− アジャイルサムライ−達人開発者への道− Jonathan Rasmusson
    masudaK
    9ヶ月前

  • masudaK

    79ページ

    ●プロジェクトの課題を早い段階であきらかにできる。
    リスクについて話し合うべきタイミングは、プロジェクトの開始時点である今こそがふさわしい。爆弾が爆発してからじゃ遅いんだ。解決すべき課題や、プロジェクトの進行を妨げそうな問題があるなら、今ここでみんなに伝えよう。
    ●「いや、その理屈はおかしい」と表明するチャンスである。
    インセプションデッキのあいだに何か「これはちょっとおかしいんじゃないか」と思える話が出てきたら、今がその違和感を表明する絶好の機会だ。
    ●単純に気持ちがすっきりする。
    不安な感情を他の人と分かち合うのは良いことだ。チームの結束を高めるきっかけになるし、苦労話を共有すれば、互いの経験から教訓を学べることもあるだろう。

    ちょっと考えてみればわかると思うが、プロジェクトの開始時点というのはまだ余裕があるだ。この段階で率直に話し合っておいたほうがいい。

    アジャイルサムライ−達人開発者への道− アジャイルサムライ−達人開発者への道− Jonathan Rasmusson
    masudaK
    9ヶ月前

  • masudaK

    75ページ

    だからこそ、技術的な得意分野を早めに表明しておくのは大事なことだ。意味の考えた解決策が完璧であるとか、君がすべての答えを知っているかなんてことは問題じゃない。それよりも、君の提案する解決策に足並みを揃えてくれる適切なメンバーがプロジェクトにいてくれることのほうが大切なんだ。

    アジャイルサムライ−達人開発者への道− アジャイルサムライ−達人開発者への道− Jonathan Rasmusson
    masudaK
    9ヶ月前

  • masudaK

    24ページ

    チームビルディングをうまくやるために望ましいのは、役割に人を合わせるんじゃなくて、人に合わせて役割分担を決めるってことなんだ。

    アジャイルサムライ−達人開発者への道− アジャイルサムライ−達人開発者への道− Jonathan Rasmusson
    masudaK
    9ヶ月前

  • masudaK

    69ページ

    せっかくの努力を水の泡にしないためには、「増やすこと」をやめよう。どんな週間を身につけるときも、それが唯一の秘訣だ。
    一度にひとつに集中して、あなたの全エネルギーをかけて30日間続けよう。

    減らす技術 The Power of LESS 減らす技術 The Power of LESS レオ・バボータ
    masudaK
    9ヶ月前