2017-11-08 | 技術開発

アジャイル・プロジェクト始動

Thumb img 3050

この記録(ブログ)は、実際のプロジェクトにアジャイル開発のテクニックをどのように応用することが出来るかを記録しました。

キックオフ

開発を始める前に、顧客と私達は一週間程の時間で、プロジェクトのスペックと、開発プランを確認しました。

ビジョンの確認

プロジェクト開始日、顧客の提案から始まりました。
このプロジェクトの顧客は仕様書ではなく、プロダクトに関するイメージを提示してきました。
例えば、
誰が(使用者はだれですか?使用者の役割は何ですか?)、
何を(使用者はこのプラットホームに何をできますか?)、
いつ(このプロダクトはいつ公開しますか?)、
どこで(幾つの国に公開しますか?)、
どんなリソース(今持っているリソースは何ですか?)
などです。
開発チーム(ユーザインタフェース設計者、ソフトウェア開発者、PM)は顧客の要望に沿って、プロダクトの機能が実現可能かを確認するため、意見を出しました。

ユーザーストーリー

私たちは様々な方法で、製品を顧客ニーズに合わせて具現化していきました。
最初はサイトマップで製品の基本概要を示し、フローチャートとワイヤーフレームを作りました。
次に、それらを用いて、顧客はもっと具体的なニーズを打ち合わせの過程で出してきました。(例えばビジネスロジックや必要なページや入力必須の項目など)
User Stroy

そして、顧客の要望に沿って、全ての機能を提示しました。
しかし、この段階で、私たちは顧客がこの製品に望む機能の全てを作成するのは困難であるかもしれないことに気づきました。
ただ、私たちは製品の全容と、必要なページと機能は何かを全て理解していましたから、チームメンバーは機能や画面を一つ一つを分けて、Google spreadsheetのページ上から順番に書いて管理しました。

開発する前のストーリーポイントの見積もり

ストーリーポイントは既に見積もったストーリーをサンプルとして比較しながら相対的なサイズを算出することで行われます。
ストーリーポイントの見積もりは、プロジェクト開発に必要な作業量を表す方法です。
一番理想な状況は「総ポイント数 / 一人日でできるストーリーポイント = 開発時間」です。
ポイント公式
しかし、開発の過程で色々な変更点などがあって、当初のストーリーポイントの見積もりに影響が出る場合があるかもしれません。
開発する前のストーリーポイントの見積もり以外、チームも状況によって、作業の粒度を調整します。
例えば、もしある機能の必要な作業量は最大ポイント(例えば5ポイント)も足りない場合、私たちはその機能をもっと小さく分けて、各機能に一つポイントずつ加えることで、このプロジェクトの総ポイント数を計算することができます。
総ポイント数はチームが毎日完成すべきポイントです。
もしこの段階で、総ポイント数が毎日できる仕事の量より多いと、もっと具体的に、今の作業内容を調整すべき、と顧客に相談します。

スプリント計画

スプリント計画とは、実際のひとつの反復期間(イテレーション期間)の開発フェーズです。
今回このプロジェクトの期間は10日間です。
スプリント計画のGoogle Spreadsheetに記録されている項目は、一つずつのスプリントに分配して、スプリント毎にすべき仕事のスプリント・バックログです。(下図のように)
スプリント計画
チームと顧客はこのスプリント計画によって開発の速度を調整できます。

開発段階

スプリント‧プラニング

今回、プロジェクトのスプリントの反復期間は10日間になりました。
スプリントが始まった日の朝に、チームメンバーは今回のスプリントのバックログを確認し、
前回のスプリントと比べて、ポイントの数と仕事量を調整します。
しかし、今回のプロジェクトに、
特にスプリント‧レビューやスプリント‧プラニング、スプリント‧レトロスペクティブなどのミーティングを区分していませんでした。
今回の顧客は台湾にいないことと、開発時間も限りがあるので、チームの全員がミーティングに参加していたら、多分な時間を余計に要することが想定されました。
その代わりに、顧客がGoogle spreadsheetに記載の完成したアイテムを見て、ステージングエリアで機能を操作して確認することでき、時間の節約ができました。
このやり方のメリットは会議の時間を短縮しましたが、
リスクは毎回のスプリント期間、顧客に対する機能のデモの少なさ、完成の結果と顧客の希望の差異があるかもしれませんでした。
しかし、私たちは、今回の顧客と打ち合わせを頻繁に行い、開発の過程で問題を改善できました。

毎日のスタンドアップ・ミーティング

スタンドアップ・ミーティング
私たちは開発段階に入った後、毎日15分のスタンドアップ・ミーティングを行います。
ちょうど会社にはカウンターがありますから、チームメンバー全員が毎日決まった時刻に、カウンターへ移動します。
そして、スタンドアップ・ミーティングして、以下の3つの質問に答えます。
1.昨日、何を達成しましたか?
2.今日、何をしますか?
3.進捗を妨げている問題は何ですか?
最初の頃、よく予定の時間を超えてしまって、その原因は進捗を妨げる課題をディスカッションし過ぎたことでした。
その改善のため、スタンドアップ・ミーティングの目的は各自の進捗報告をすることとしました。
そして問題を改善するために、その後のミーティングは、メンバーが時間を記録しました。
もし進捗を妨げる課題があったら、課題を記録して、その解決は関係者がそれぞれ別の場や時間を設けて行うのです。
そして、次の日のスタンドアップ・ミーティングで課題の結果を報告しました。

バーンダウンチャート

アジャイル開発の時は、各スプリントの段階で完成すべきプロジェクトの内容を計画する以外に、私たちも期限までに全ての作業を消化できるのかをバーンダウンチャートを用いて毎日の状態をフォローアップします。
バーンダウンチャート
顧客もバーンダウンチャートで、毎日のプロジェクトの状態を確認することができます。
バーンダウンチャートは毎日完成したポイント、増えたポイントによって上下に移動します。
もし実績線は理想線の下になったら、チームスタンドアップ・ミーティングで、予定より遅れている原因を確認して改善します。
1.設計図を確認
2.テスト駆動開発
3.コードレビュー
4.選択肢となるものをマージ(合併)
WEBアプリ開発にとって、バージョン管理は不可欠の要素です。
私達はGitLabで、コードをバージョン管理する以外、Zeplinも使って設計図のバージョン管理をしました。
開発も設計も効率が上がりました。
開発者はテスト駆動開発で各機能を追加し、コードをGitLabにプッシュし、マージのpull requestを出した後、レビュアーはPull Reqeustを確認して、問題なければ元の選択肢にマージします。

最終プロダクト

アルファテストとカスタマー・テスト

プロダクトを公開する前に、チームはビジネスロジックとシナリオを確認するために、シナリオテストもやりました。
そして、顧客にアルファテストをさせて、実際に機能を操作してもらいました。

デプロイとメンテナンス

最後の調整は、自動デプロイのスクリプトを作成して、プロダクトを公開しました。

結論

調整、絶対目標を達成

アジャイル開発の手法で、私達の四人のチームは68人日の作業日数で、順調に製品を公開することができました。
プロジェクトの開発は、ビジネスモデルの調整とスケジュールの変化で、機能を変更しなければならないことはよくあります。
今回のプロジェクト、チーム一体(スクラム)での開発は、短期間で動作するプロダクトを作成できるため、定期的に顧客からのフィードバックを得、修正することができました。
これにより、開発の最終段階になって「想定していたものと違う!」といったトラブルを避けることができます。
開発の過程で設計図の検討に時間がかかりすぎて、他の機能が遅延することありました。
あるチームメンバーがスタンドアップ・ミーティングで、この状況を確認した後、私たちはすぐ顧客と作業の流れを調整して、必要なアクションを取り、作業の軌道修正を行いました。
アジャイル開発の手法を使って、チームと顧客のコミュニケーションが円滑になることによって、有限の時間に高品質のプロダクト開発できると考えています。

Categories

Archives