うぃろぅ.log

140字で綴りきれない日々の徒然備忘録

【備忘録】 アジャイル開発発展

うぃろぅです。

vviilloovv.hatenablog.com

前回の続きの内容となります。今日も元気に参りましょう。

今日のテーマ

アジャイル開発 次の一歩

アジャイル開発を知る

  • アジャイル」は俊敏な / 機敏な と訳される
  • 「学習する」ことがゴールといえる
  • ユーザー部門と開発者が協調してプロジェクトを成功に導く、という特徴を持つ
    ウォーターフォールだろうが協調すべきでは
  • 使わない機能は作らないという決断を促すことがある
  • 「短い間隔」で「継続的」にリリースする

「要件が明確」で「要件がすることがなく」、「リリースまでの猶予期間が長い」場合はウォーターフォールが適している。

japanese.engadget.com

これは蛇足なので聞き流してほしいことなのだが、このプロジェクトに携わることになる人は頑張って強く生きてほしい。
エンドがgo.jpはホントに…ね。いや何とは言わないが。

XP

エクストリームプログラミングについてのあれこれ。

ペアプログラミング

ドライバとナビゲーターに分かれ、プログラミングに関係する全ての作業を2人で分担する。

常に会話をしながらナビゲーターが指示を出し、ドライバが作業をする。
一定時間で役割を交代して続けていく。

ペアプロFAQ

Q: 工数が倍になるのでは?
A: 工数は1.2倍程度、期間は0.6倍程度に収まる
これ以上かかる場合はやり方に問題がある

Q: ペアの決め方などコツはある?
A: くじ引きでもなんでもいい

Q: どのような効果があるの?
A: 問題が早い段階でわかる / スキル共有に効果的

開発準備

開発準備段階で利用できる手法を示していく。

計画ミーティング

  • リリース計画ミーティング
    ユーザーストーリーの相対見積もりを行い、ストーリーポイントを決める。優先順位付けも行う。
  • スプリント計画ミーティング
    タスクを洗い出し、理想時間見積もりを行う。

の2種類がある。

dojo.codebot.io

ユーザーストーリーって何よ、ということで。
「どうして」必要で、「何を」するべきなのかを明確に示す、ということがわかりやすく書かれている。読むべし。

相対見積もりと理想時間見積もり

  • ストーリーポイント: 相対見積もり
    基準値を1つ設定し、それよりもどれくらい重いか、どれくらい軽いかを相対的に評価して見積もる。

  • 作業時間: 理想時間見積もり
    作業内容を明確にし、その作業を終わらせるために必要な時間を見積もる。

良いユーザーストーリーの条件(INVEST)

  • Independent
    他のユーザーストーリーと独立していること
  • Negotiable
    交渉可能であること
  • Valuable
    有益であること
  • Estimable
    見積もり可能であること
  • Small / Size Right
    適切なサイズであること
  • Testable
    完成したことを検証可能であること

プランニングポーカー

なんか楽しそう(小並感)。

見積りのためだけじゃなかった! プランニングポーカーが開発チームとプロダクトにもたらす8の恩恵 - Appresso Engineer Blog

複数人で暗黙の理解を洗い出して共有する見積もり方法のこと。

「○○だからこの作業は重い」「××を使えばこの作業は軽くできる」といったディスカッションをすることで適切な見積もりができるということである。リーダー1人で全て見積もるより信頼性が高い気がする。

開発

開発で利用する手法を示していく。

タスクボード

ユーザーストーリーごとに実施するタスクを並べ、ToDoDoingDoneと遷移させていく。

バーンダウンチャート

残作業量を確認し、作業の進捗傾向を可視化するグラフのこと。

www.ryuzee.com

これを読むと全部わかる。すごい。
ちなみに私の会社PC環境だと「アップローダー」という理由でWebフィルタにひっかかるため全く参照できない。かなしい。

ふりかえり

PDCAでの「C」のあたり。

ja.atlassian.com

この手順どおりにやれば上手くいきそう。世の中には丁寧な資料が溢れている…感謝…。

「全員が参加している」ということが大事で、傍観者がいないようにしなければならない。

seleck.cc

解決する方法を話し合うためのフレームワークとして「KPT」がある。上記リンクが詳しい。
確かに問題点がわかったとしても「それでどうすりゃいいのさ」を話し合うことが重要。そりゃそうじゃ。

実践のポイント

  • ゴールは学習すること
    学習したチームは良いプロダクトを提供できる。
  • リリースしてフィードバックをもらう
    リリースしなければフィードバックをもらえず、フィードバックをもらえなければ学習できない。
  • テスト / ドキュメント作成は毎回実施する
    イテレーションごとに全ての作業を完了させる必要がある。マスト。必ず。リリース間隔が短いため品質保証はとても大事。
  • 品質保証の考え方
    戦略的に開発項目を決めることが重要。問題が顕在化した場合全ての見直しを行わなければならない。

まとめ

前回の内容に加え、実際の手法や発展的な内容についての学習だった。

実際にやってみるのが大事だと思う。チャンス探し中。

ではまた。