アジャイル開発プロジェクトにおける古典的な失敗パターンのメモ

  • 2013.10.31 Thursday
  • 01:40

日経コンピュータで連載されている天野勝さんの「アジャイル開発、実践の勘所」に書かれていた、
アジャイル開発における古典的な失敗パターンが凄く勉強になったので、自分メモ。
(雑誌内容そのまま掲載はさすがにアレなので、要点のみに編集)

■失敗パターンその1
間に合わせ仕事
  • イテレーションないで、無理やり完成させようとして品質悪化。
  • 次のイテレーションにも影響し、修正に時間がかかり新規機能追加が遅れる。
  • どんどん、技術的負債が膨らんでしまう。
対処方法の例
  • ふりかえりで、問題点を把握。
  • 作業の省力化や、スコープ見直し。
  • そもそも、朝会などで早期に問題点発見を心掛ける。


■失敗パターンその2
イテレーションの延長
  • 期間内で完了しなかった為、イテレーション期間を延ばしてしまう。
  • その結果、フィードバック回数が減ってしまう。
対処方法の例
  • 慣れないうちは、イテレーションの期間を延ばさない。
  • スクラムでは、イテレーション途中でのゴール変更を禁じている。
  • イテレーション期間を3日間など短くするのも一案。
  • (慣れないとタスク作りにも時間が取られてしまうので、計画を建て易い期間とする)
  • 慣れてきたらイテレーション期間を1週間より延ばすなど行っても良い。


■失敗パターンその3
巻き込み不足
  • 品質チェック担当のメンバーがアジャイル開発に対して知識不足。
  • 品質チェック担当が、既存審査基準からの変化に対応できず、リリースできない。
対処方法の例
  • プロジェクト初期から、品質チェック担当にも参加を促す。


■失敗パターンその4
情報の揮発(きはつ)
  • 情報が更新されず、新機能追加時に見当がつかない。
  • 分析に余計な時間がかかってしまう。
対処方法の例
  • プロジェクト区切り毎に、保守用ドキュメントを用意する
  • (アジャイルはドキュメントを作らないという勘違いがまだ多い)
  • 自動化テスト環境を用意し、システムを振る舞い的に理解しやすいようにする。
  • システム担当メンバーをある程度固定化し、そのまま運用保守まで担当することで、引継ぎによるコストを減らす。


あとパターンに含まれていませんでしたが、失敗しやすいものとして、
  • メンバーがアジャイル経験が未熟のうちにメンバーを分裂させて、アジャイルチームを増やしてしまう。
  • アジャイル経験者をリーダのポジションに就けると、メンバーが指示待ち態度となってしまい、互いに助け合うというチームにならない。

失敗の根本にあるのは、互いに助け合うという気持ちが足りない時に発生しやすい。
チームメンバーが役割に拘らず、互いに補完しあう、自律的に動くチームを作る事が大切であると締められています。

 

スポンサーサイト

  • 2017.11.25 Saturday
  • 01:40
  • 0
    • -
    • -
    • -
    コメント
    コメントする








        
    この記事のトラックバックURL
    トラックバック