ウォーターフォールな私のはじめてのアジャイル開発です。
忘備録も兼ねて、気が向いた時にエントリーを上げていきます。
アジャイルソフトウェア開発手法の多くは、反復 (イテレーション) と呼ばれる短い期間単位を採用することで、リスクを最小化しようとしている。 1つの反復の期間は、プロジェクトごとに異なるが、1週間から4週間くらいであることが多い。
- アジャイルソフトウェア開発 （Wikipedia）
要するに、要件定義～テストまでを短い期間で行い、それらを繰り返すことにより、ソフトウェアを作っていこうというものです。
アジャイルなのでチケット駆動開発ということになります。
チケット駆動開発 (ticket-driven development; TiDD) とは、プログラム開発手法の一種で、作業をタスクに分割しBTS（Bug Tracking System／バグ管理システム）のチケットに割り当てて管理を行う開発スタイル[1]。細かな修正作業の多い従来開発の中で生まれたが、アジャイル開発との親和性が高い[2]ことから、エクストリーム・プログラミングをはじめとするアジャイル開発でも実践されている。
- チケット駆動開発 （Wikipedia）
勉強会ではアジャイル開発絡みのスピーチを積極的に聞くようにしました。
スピーカーは経験者の方で、「自分はこうしました」といった事例紹介です。
- 他山の石以て玉を攻むべし
- 他人の壁は自分の壁
です。
プラクティスはありますが、全てのプロジェクトに適用できるものではないと私は思っています。
原理原則をカスタマイズしていき、各々のプロジェクトに合ったプラクティスを作っていくのが、プロジェクト運営の肝になります。
原理原則を順守するあまり、プロジェクトが炎上しては意味がないですからね。
色々な会社の方の事例を聞きましたが、共通しているのはひとつ。
「とにかくコミュニケーションを密に取れ」
「朝会の実施」が有名ですが、とにかく会話をよくしろということが大切ですが、その際に
「今やっていることをどう思っているか」
という感情も交えて話をしたという話をよく聞きました。
何故そうすべきかという理由はおっしゃっていませんでしたが、あくまでも作業に対する担当者の割り当てをするからかなと思いました。
例えばWBS型の開発だと、「○○画面はAさん担当」「××バッチはBさん担当」といった担当者の割り当てをします。
チケット駆動型の開発だと、「○○の作業はAさん担当」「××の作業はBさん担当」と、作業で管理します。
それぞれのプロジェクトを進めていくとどういうことになるかというと、
◆WBS型の進捗管理
自分は〇〇画面の担当⇒他人が何をしていようが自分の担当領域にはあまり関係ない
◆チケット駆動開発
自分は今のスプリントでは××作業の担当⇒次のスプリントでは△△作業の担当
ということになります。
つまり、プロジェクトの間中、同じ機能の面倒を見ておけばよいというわけではなく、スプリントごとの作業割り当てで担当者が決まるので、自分がどの機能を開発するのかはかなり流動的であると言えます。
他人がその作業をしていて、楽しいのか、不安なのか、どうなのかを知り、他人が困っていることはいつか自分も同じく困ることがある。
それを共有し、悩みをメンバ全体で解決していこうということなのでしょう、たぶん。
※これ、引っ込み思案の方には向いてない開発手法かもしれませんね。
リーダの方はフォローをしっかりしないといけないですね。
最後になりましたが、スプリントでやっていきます。
次回はチケット登録の考え方です。たぶん。
ご意見・ご指摘等があればいただけるとかなり助かります。
0 件のコメント:
コメントを投稿