note

アジャイルまわりで最近学んだこと

More than 3 years have passed since last update.

自己紹介

  • 名前: 伊与田陸
  • ソフトウェアエンジニアを20年くらいやってます。

個人的にアジャイルを避けてきた三つの理由

  • アジャイルという言葉だけが先行してる印象があった。
  • フリーランスとして一人で活動することが多く作れていればなんでも良かった。
  • 新しいものに飛び付かなくなった。

最近アジャイルを勉強するようになった三つの理由

  • スクラムマスターの人がチームに来るはずが・・・。
  • 若い人がスクラムとかアジャイルとかの本を読んでいるのを見た。
  • ボスに本を積まれた。

勉強前にアジャイルに持っていた偏見

  • 管理しないて適当にやるんじゃないか。
  • 見積りを重視しないで結局はぐだくだに

学んでわかってきたこと

アジャイルマニフェストってのがある

  • プロセスやツールよりも、人と人との交流を
  • 包括的なドキュメントよりも、動作するソフトウェアを
  • 契約上の交渉よりも、顧客との協調を
  • 計画に従うことよりも、変化に適応することを

アジャイルチームとは

アジャイルチームとは職能横断的なものあり個々のメンバーの専門分野を越えて機能する。これが成功を後押しする。
プロジェクトへの帰属意識を職能への意識より優先する。
フリーランスには少し耳が痛いところ。

アジャイルが前提としているもの

  • ウォーターフォールしかない時代に辛い記憶
  • より良くしようとする意思
  • 繰り返しながら学んでいく

スクラムってのがあるらしい

スクラムはチーム運営すら属人性を排除し仕組みとして回していくためのフレームワーク。
市場とチームの持つ感情が変化していくことを前提に作られている。
スクラムを組織に根付かせるのは骨が折れそうだがチャレンジしてみたい。

優先順位付けとは儲かる順序

今までは企画担当に毎回確認して作っていた優先順位付けだが、勉強していく中で相対的な重み付けという方法を学んだ。
これを使うとこれまで漠然としていた優先順位を数値として解釈できるようになる。
エクセルやGoogleDocsでシート作ると便利、プロダクトバックログの精査やボスとの交渉に使ってみてるけどとてもいい。Karlさんありがとう。

http://msdn.microsoft.com/ja-jp/library/hh765981.aspx#Weigers

スケジュールバッファは水増しではない

現実世界の不確実性と戦うためにはバッファは必要。
バッファなしを良しとする文化では早い段階で事故が起きてしまう。事故怖いです。

ベロシティの取り扱いに注意

個人単位でベロシティを測定したりトラッキングしない、個人よりもチームとして見た場合の生産性を重視していく。個人攻撃にならないように気をつけたい。

アジャイルはいいものだった

勉強してみるとソフトウェア開発についての様々な知見がまとまっていて楽しい。
先輩達がソフトウェア開発についての悲しみといかに戦っているかどうやって開発しているかを知ることができて本当に良かった。
今後もアジャイルまわりの勉強も続けていきたいと思う。

最後に本を積んでくれたボスに感謝したい。ありがとう @kimiya さん。