Ajile Conference Tokyo 2013に参加してきた。
先日行ってきたときのメモ。
丸一日のカンファレンスで、まとめるのに時間がかってしまった・・・。
スピーカーに共通していた話題
アジャイルは難しい。
導入する手法は理解して行わないと効果がない。
ルールを決めてやらないとグダグダになる。
人間の意識を変えるのには、とにかく時間がかかる。
「仕様の変更はガンガンするけど、計画の変更は認めない」っていうスタンスが
アジャイルの導入に壁を作っていると感じた。
あと、動いているものは基本触らないっていう考え方を変えるのも時間がかかりそう。
そして、決裁権を持った人間をどうやって巻き込むかが課題。
アジャイルに精通した人を育成することも課題。
アジャイル開発は手段の一つである。
ウォータフォールだから失敗しているわけじゃない。
どんな課題を解決するのかを明確にする。
課題の優先度、開発メンバー、予算などに応じて、
適応するプロセスを考えることが大事。
プロセスを知るために学習は必要だが、本の鵜呑みはほぼ失敗する。
品質の担保と保守を考えよう
ドキュメントを作らなくて良い、は嘘。
コードを読んでるわかる人が常に確保できるとは限らないし、
ドキュメントがあれば、それだけスタートアップの工数が減る。
本当に必要なドキュメントを精査することと、手間をかけずに作成できるように工夫する。
自動生成できたら、企画開発に集中できる。
あと、テストの自動化はやはり必須の流れ。
継続的かつ、素早くかつ、高品質なものをリリースするためには、
テストの質を落とさずに時間を短縮しないと無理。
となると、テストの自動化は一つの答えで、テスト駆動開発が注目されるのは自明。
典型的なアジャイル失敗パターン
メンバーがコミュ障である場合
開発チームが一丸となって、連携プレイをすることが重要。
コミュニケーションがとれないと破綻する。
そもそも見積もりが無謀である場合
アジャイルだろうとウォータフォールだろうと、不可能なものは可能にならない。
仕様を固めてみたら、工数が倍必要なのが発覚しちゃうとか、笑えるけど笑えない。
変更を受け入れる時間が計画に入っていない場合
「アジャイルはガンガン変更していく」っていう部分だけを持ちだすパターン。
追加・修正・削除は全て工数がかかるという事は、都合よく忘れてる。
決裁権を持った人がこれをやると、Go Go デスマーチ。
アジャイル導入の目的がない場合
解決する課題が不明確なまま、アジャイルの手法を持ち込むパターン。
目的や状況によって、手法を適切にチョイスしないと効果は出ない。
(適切にチョイスするには知識と経験が必要)
品質計画が決まってない場合
ガンガン変更するし、修正の工数も計画に入れたけど、
品質の担保を考慮してないパターン。
アプリは落ちないけど動作がクソ重いのは許容するの？？
テストやレビューも計画に入れないと、皆が不幸になる。
心に残ったこと
・変化することが必要なのではない。生き残ることが必要。
・マネージメントとは、成果を出させる能力である。
・アジャイルはとても集中力が必要。３ヶ月も続けるかなり疲れる。
・プロジェクト計画を立てた後に予算を決める。
・「縦割り社会」「トップダウン予算」「バックデートで契約締結」が複合すると
デスマーチ率が高まる。
これからやっていこうと思ったこと
プロセスを知ること
どんな手法があって、どんな場合に有効なのかを学習する。
周りの人にも覚えてもらえるように、教育の時間をもうける。
意識改革
いつもいつも、声のでかい人間にプロジェクトをメチャクチャにされている感あるけど
我々が理想をもって仕事をしていないからではないかと感じた。
プロジェクトの関係者に敵がいる状況は、やはりよくない。
目先の利益しか見えないのでは、先に進んでいけない。
レビューの文化
まずはプルリク機能を使うところから始める。
その後、マージの確認を挟むという手順を踏んで導入したい。
計画の立て方を文書化
段取りで手間取らないよう、ポイントを明確にする。
タスクには優先順位をつける。
１つのタスクは大きくても１日(５ｈ)に収める。
変更の時間を組み込む。
レビューやテストを考慮する。
まとめ
話を聞いていて、弊社をディスられているのかと思った。
典型的な失敗パターンに全部当てはまるなんて・・・
できることから少しづつやっていきたい。
