SiG Staff Blog

福井と金沢にある株式会社SIG 総合研究所で働きたい方、ご連絡ください。

ウォーターフォールからアジャイル的な開発にするために - 7

プロジェクト開始時

チームでのルールを共有

  • 一番大事な内容。
  • どんなチームにしたいか、という意識の共有。
  • 気持ち的に安心できる環境を作りましょうという意識の共有。

このあたりを共有して、コミットを得ておかないと後々辛くなるので、
みんなが納得できるまで話し合う。

全員での見積もり

作業の洗い出しはリーダーがして、洗い出した後どんな機能が必要が全員で出し合う。
出し合った機能に対して、自分がやるとしてMinとMaxかかる時間をざっくり出して、真ん中を取るようにしてみると、いい感じの期間なるかなと思ってます。

本当は、プランニングポーカーとか相対的な見積もりをしたほうが速いし分かりやすいのでいいと思うんですが、最初は慣れてる方法でやってみて、後々でいいかと思ってます。

見積を元に仮の計画を立てる

恐らく、どのぐらいの期間でできるのか?という事を聞かれるので、上で出したものでWBSを作成しておく。
加えて、Maxの平均値でもWBSを作成して、最も延びる場合の期間も報告するといいと思います。

報告したことも議事に残しておくと、後で揉めた時に使えるかと思います。

開発ルールの共有(チケットの書き方や、Gitのブランチ運用など)

大体のプロジェクトの最初にやると思いますので、省略します。

スプリント期間の決定(作業の区切りを自分たちで決める)

プロジェクトの動きの修正を行う単位を決めます。
1週間か2週間のどちらかがいいと思います。

まとめ

いつものプロジェクトでやる事とそんなに違いが無いと思います。
大事な事はメンバーで考えて、決めるというところだと思います。

全部のまとめ

やる事の違いは、

  • メンバーで決める。
  • 悪い事はすぐに知らせて、すぐに対処する。
  • ミーティングは離す内容を決めておき、すぐに終わらせる。
  • 定期的に振り返りをする。

って事だと思います。
チームで話し合って、同意をとって、みんなが納得した状態で進めれるといいですね。


これが成功したら、スクラムがやったほうがいいというプラクティスを実施していくといいと思います。
そして、テスト自動化、CI、DIも欲しくなってくると思います。

こんな本を読みました

ウォーターフォールからアジャイル的な開発にするために - 6

プロジェクト後の作業

KPTなどを使った振り返り

  • プロジェクトで、良かった事、悪かった事、それらに対してどうアクションを起こすかを話し合い、纏める。
  • 見積でブレが生じた原因を探す。
  • チームとしてどうだったかの話。
    などをするといいかなと思います。

予算と費用と利益の計算

残業などから、実際にかかった費用を出す。
売上から費用を引いて利益を出す。
見積から費用を引いた予定利益を出す。
その差を見て、みんなで感想を話し合う。

まとめ

全体を通して、良かった事、悪かった事を話し合って、次のプロジェクトにつなげる。
利益を気にしない人が多いので、幾ら利益が出たのか共有する。もっと儲けられないかとか。

次はプロジェクトの前にする作業を纏めようと思います。

こんな本を読みました

ウォーターフォールからアジャイル的な開発にするために - 5

1ヵ月毎の作業

最初は不要だと思っていたのですが、長い時間で情報の共有をしたいという声があったのでやるようにしました。 スプリント毎にやる振り返りの代わりに行います。 例えばスプリントが1週間の場合、4回目はこの作業に切り替えます。

やる事はスプリント毎に行う振り返りと同じです。

振り返り

  • 1~2時間かけて、見積の予実と原因を探り、見積を見直す。
  • 人員の追加などが必要か話し合う。
  • 納期の延期などを行う必要があるか話し合う。
  • その裏付けとなるデータの作成。
  • ノウハウの共有
  • 今後のタスクで必要な技術の洗い出しと、不安点の話あい。

報告

  • スプリント毎に行っている事と同じ。なぜそうなったかのデータを提示するとなお良い。

まとめ

プロジェクトを完了させるために、人の追加、大きい納期の変更が必要かどうかを決める。
プログラムで全体的なノウハウ、問題点の共有を行う。

物凄い残業をしないといけなさそうな予感があった場合、ここでつぶせるように手を打っておく。
その為の情報共有を行えるといい。

次はプロジェクト毎にする作業を纏めようと思います。

こんな本を読みました

ウォーターフォールからアジャイル的な開発にするために - 4

スプリント毎の作業

主な目的は、「速めにプロジェクトの進む方向を修正する」です。
言葉を変えれば遅延の確認ですが、「見積が悪かった」という視点で話すことが大事です。

メンバーは悪くない。計画が悪かったんです。

スプリントの振り返り(長くて1時間で終わらせる)

見積の精度を上げる

  • 一週間で終わる予定だった作業が終わったかかどうかを確認する。
    • 速く終わった場合、終わっていない場合毎に、何が見積と違っていたかを確認する。
  • 来週の作業の見積もりが妥当か検討する。

予実から原因を探って、全員で現在の見積の妥当性を疑って修正する。
全員が納得するのが大事。放っておくと延びっぱなしになるので、それを抑制する人も必要。

ノウハウの共有

嵌ったポイントとその解決や、作成した便利クラス or メソッドの連絡とかを共有する。

報告

言いにくいかもしれないができないことはできないので、自分の社内で計画を変更したことを共有してお客に報告する。
この時の議事録を必ず取る。音声をレコーディングしてもよい。

なぜなら、絶対後でそんな延長の話をしたっけ?そうだっけ?という話をする人が現れるからである。
社内での話も、お客との話も全て残しておくこと。

水掛け論にならないように、メンバーを守る。

まとめ

メンバーは悪くない。計画が悪い。という事を前面に出して話し合いをしましょう。 暖かいお茶でも飲みながらできるといいです。

次は1か月毎にする作業を纏めようと思います。

こんな本を読みました

ウォーターフォールからアジャイル的な開発にするために - 3

毎日の作業

ルールの中で、

  • 隠し事をしない。
  • 完了が遅れる事を言い易い(言える)場を作る。
  • 上下関係を出さない。
  • 全体を把握できるようにするために、チームの人数を多くて6~10人程度にする。

これらを実現するためにやります。
ただ、毎日することなので、
定例部分は時間をかけないことが重要です。

朝会

  1. 昨日した事
  2. 今日する事
  3. 進捗の報告
  4. 困ってる事

をメンバーが報告する。
注意するのは、「困っている事」を報告している時に、それを解決する為に議論が勃発することである。
2~3分などですぐ終わるのであればいいが、それ以上かかりそうだったら、議論をしていた人達で後でミーティングしてもらう。

メンバーの時間を無駄に指定はいけない。

また、作業遅延に対しては「なぜ遅れたのか?」など攻めてはいけない。デイリーな報告で聞く内容ではない。
長いスパンでの遅延を言いにくくなってしまう。

開発

チケット駆動

ツールは何でもいいが、

などのタスク管理を使う。

そこで割り振られたチケットの作業を行う。
チャットツールで会話して決まった事はチケットにその経緯と結果を記載する。

ただし、チケット上で対話をしない。情報のノイズが増える事と、手間が増えるため。

話し合い

チャットツールを使って、履歴が残るようにするといい。
文字でのやり取りだと、とらえ方が人によって違い誤解を生みやすいので、伝わってないと思ったらすぐにSkypeなどで会話をする。
この時、表情が見えないと話がしにくいので、カメラを使用する事。

無駄話

作業と関係ない話をする。
ゲームの話とか、趣味の話とかをして作業に没頭しすぎないようにする。

没頭しすぎると、俯瞰的な視点でプログラムをすることができなくなりがちだからである。

進捗報告(チャットツールで)

帰る前に、予定との差などを報告する。
いちいち報告に行くと大変なので、チャットツールで報告するだけでよいと思う。

何を報告するかテンプレートを作っても良いかと思う。

その他

個人的には、小休憩ができるようにイベントや席を離れる仕組みを入れると良いかと思う

  • お菓子コーナーを設けて、小休憩がしやすい状況を作る。お菓子は各々が持ち寄る。
  • 時々、みんなでお金を出し合いお取り寄せをして、みんなで食べるなどのイベントをする。

まとめ

日々は、時々休憩しながら作業できるようにするといい。
遅延に対して責めない(責められていないと思わす)事が大事である。(責任感は持ってもらわないといけませんが。)

次はスプリント毎にする作業を纏めようと思います。

こんな本を読みました

ウォーターフォールからアジャイル的な開発にするために - 2

どんな事をするのか

こんな前提で話をします。

  • スクラムっぽい事をします。
  • みんなスクラム未経験。
  • リモートワークの人が居る
  • "お客と打ち合わせをする人"と"開発する人"という役割分担がある

まず最初に、メンバーで共有する事

素早く作業を進めるために、問題が発生した時は即座に対応する必要があります。 なので、ネガティブな事をオープンに話せる状況を作る事を最上の目標にします。

なので、下のような事を共有し実践します。

  • 隠し事をしない。
  • 完了が遅れる事を言い易い(言える)場を作る。
  • 上下関係を出さない。
  • 仕事以外の話をする。
  • 全体を把握できるようにするために、チームの人数を多くて6~10人程度にする。
  • ツールは自由になんでも使えるようにする。新しいツールを拒否しない。
  • チャットツールを使い、リモートの人が疎外感を感じないように頻繁にチャットする。
  • MTGは顔が見えるように、カメラを付ける。
  • MTGは必ず議事録を取る。

これが一番大事かもしれません。ここさえクリアできれば、後はリーダーがスクラムで必要な行程をチェックしながら進めていけれます。

実施する行程

やる事は、

プロジェクトの最初に、ルールと見積を行う。 次に、各行程毎に、作業予定と作業結果を報告する。 最後に、その予実を元にプロジェクトの道筋を訂正する。

これだけである。 恐らく、普通のプロジェクトではほとんどやってる事じゃないでしょうか。 違いがあるといえば、「スプリント毎にプロジェクトの計画を修正をして、その修正に対して承認を得る。」というところだと思います。

プロジェクト開始時

  • 先ほど書いたルールの共有
  • 全員での見積もり
  • 見積を元に仮の計画を立てる
  • 開発ルールの共有(チケットの書き方や、Gitのブランチ運用など)
  • スプリント期間の決定(作業の区切りを自分たちで決める)

毎日

  • 朝会(10分程度で終わらせる)
  • 開発
  • 進捗報告(チャットツールで)

スプリント毎

  • スプリントの振り返り(長くて1時間で終わらせる)
  • 見積の見直し & 報告

1ヵ月毎

  • 1ヵ月の振り返り
  • 見積の見直し & 報告
  • 計画の見直し(「人の追加」とか「納期の延期」など)

プロジェクト後

  • KPTなどを使った振り返り
  • 予算と費用と利益の計算

次は

それぞれについて具体的にどんなことをするのかを纏めていく。

こんな本を読みました

躓きポイントが書いてあってめちゃ良かったです。

ウォーターフォールからアジャイル的な開発にするために - 1

アジャイルはメンドクサイ?

多くの現場でまだウォーターフォール(W/F)で開発している現場が多く、そこでスクラムしようぜって言っても、

  • 品質・納期・費用でどれを重視するの?納期無視するんでしょ?
  • 決まりみたいなのが多くてメンドクサイ。
  • 契約で期間が決まっているからできない。

などの言い訳されて実施に至りにくく、どれもそんなことないよって事を自分的にまとめたい。

※ 書籍を読んで、実際にやってみてこうやって進めたらいいんじゃないのか?と思った内容になるので、何とか宣言に沿ってないとか、色々あると思います。

ウォーターフォールは悪なのか?

こういう話が立ち上がると、ウォーターフォールしか経験したことない人が、「やり方が否定されている」=「俺たちが悪だといわれている」という勘違いをして話をしがちな事に注意したい。
そんな考え方してるから次に進めない人な感じもしますが。

なので、どっちも目標としていることは同じだけど、プロジェクトの性質によって使い分けないと辛くなるんだ。という事を全員で最初に共有したい。

なので、ウォーターフォールは悪くない。(当たり前ですが)

使う場面

ウォーターフォールは最初から最後まで、ほぼ計画通り進む事を前提に話を進める必要があります。なので、計画の確定性が高いプロジェクトには適してます。
例えば、自動車を作るラインとか、パンの加工とかでしょうか。各工程でやる事がかなり明確になっているプロジェクトですね。
ITでいえば、ベースのアプリがあって、決まったカスタマイズをかけて出荷するようなプロジェクト(アプリ)でしょうか。


アジャイルは、計画の確定性が低いプロジェクトに使います。
なにか作業をしている途中で、「やっぱり、それ無しで」、「これにこの機能も足してくれないと仕事につかえない」とか、最初の計画になかったことを言われるプロジェクトですね。
良くありますね・・・。

プロジェクトの途中だし、今更変えれないよ

やる事はほとんど変わりません。

書籍を読むとJeninsやらCircleCIやら、TeamCityやらCIを導入しなさいとか、テスト駆動(TDD)しなさいとかありますが、しなくてもいいです。

したほうがもちろんいいですが、しなくてもいいです。いきなり全部しようとすると、何のためにしているのかわからず、形骸化してやるだけになってしまい、どこが自分たちにマッチしているのかわからなくなってしまって結局使わなくなるからです。


それらの考えが導入された順を追って、導入していけばいいと思います。
アジャイルをやってくうちに、きっと欲しくなってきます。その時に新しい物好きな人を探して導入してもらえばいいと思います。

で、何が違うの?

ほとんどの事が、恐らく普段やっているであろう管理業務の間隔を短くするだけです。

次から一つずつ纏めていこうと思います。

こんな本を読みました

もはや、有名ですね。チームを作るうえで必要な事がほぼ書いてあります。あやふやだった部分を文章化されているので、知識の再認識にもいい。



不確実な事に対してどうやって取り組んで、確実に近づけていくか。その手法について書いてあります。読むだけだと当たり前だよなぁってなりがちだけど、実践すると大変。
知識として入れておくといい。