2013年07月31日

「アジャイルの好きなところ」(Ultimate Agile Stories2)

 そろそろUltimate Agile Storiesの季節です。
 というわけで、Ultimate Agile Stories1に続き、Ultimate Agile Stories2で書いた内容をほぼ原文で公開します。

***********************

題名:アジャイルの好きなところ

2. はじめに

 皆さんは「アジャイル」のどういうところが好きですか?

 「そもそもアジャイルとは何か?」という議論も色々ありますが、ここでは「アジャイルソフトウェア開発宣言」を理解して実践しようとしていることとします。

 私が「アジャイル」に感じた好きなところは以下のようなものです。
 
(a)顧客により価値の高いものを提供することができる
(b)自分達の成功体験を短いスパンで感じることができる
(c)携わったプロダクトやサービスに誇りを持つことができる
(d)またこのチームで仕事をしたいと思うことができる


 以降、それぞれについて書いていきます。

3. 顧客により価値の高いものを提供することができる

 アジャイルでは顧客に実際に動くものを見てもらい、フィードバックを得ます。
 そのフィードバックを次のスプリントの開発に活かすことで、本当に顧客が欲しかったものを提供できる可能性が高くなります。

 スクラムだと、各スプリントで行う「スプリントレビュー」でデモなどを行い顧客に確認してもらいます。

 私が過去に経験していたやり方のいくつかでは、システムテストまで顧客が実物を見て触る機会がなかったこともありました。
 実際に使うユーザにいたっては、リリースするまでその機会がなかったこともありました。

 常にユーザに見てもらえる状態を維持するのは、それほど簡単なことではありませんが、それにチャレンジする価値はあります。

 要件定義や基本設計の工程の成果物を変更したりできず、またより良い方法をマネージャなどに提案しても力ない笑みや苦笑と共に…
「もう決まったことだから」
「お客様はそれで良いと言ってるから」

 …という返答を聞いたことありませんか?

 社内定義のQCDは充足していたとしても、発注者だけでなく、実際に使うユーザも含んだ顧客の満足度をもっとトレースしたいと思っています。

 プロジェクト終盤によく聞く「自分達が欲しかったのとは少し違うなぁ…」という声よりも、プロジェクトの途中に何度も「こういうことをしたかったんだよ。後、ここをこうすればもっと嬉しい」というユーザの声を聞きたくないですか?

4. 自分達の成功体験を短いスパンで感じることができる

 「スプリント・レトロスペクティブ」(ふりかえり)が大事な理由の1つとして、チームの良い点をより強化して、改善し、顧客への価値の提供のスピード、質を上げるというのがあると思います。

 そして、それと同じほど大事な理由に「自分達チームのことを知って、成功体験を得る」があると思います。

 私が過去に経験していたやり方のいくつかでは、「ふりかえり」はプロジェクト終了時…それこそカットオーバー後…に行うことが多くありました。
 いくつかは詳細設計などの工程の終わりで実施していたこともありました。
 途中でプロジェクトから抜けたり、あまりに大きなプロジェクトの場合、ひょっとすると「ふりかえり」の場すら無いかもしれません。
 いずれにせよ、そこで得た改善や成功体験を活かすまで、長いスパンが必要になります。
 これでは何度もあるレベルアップのチャンスを逃しているようなものです。

 特に経験が浅いエンジニアほど「自分達のチームがどの程度イケてるのか?」に敏感な傾向があり、「ふりかえり」によって成功体験を得ることで一段と伸びていきます。

 またチームメンバー同士でフィードバックをし合うことで、個人の成功体験を得て、自信を持つことができ、レベルアップにつながります。
 さらに相互理解も深まりチーム全体のレベルアップにもつながります。

 「明日からこのふりかえりで出た〇〇をやってみます」とメンバーが宣言しているのを聞きたくありませんか?

5. 携わったプロダクトやサービスに誇りを持つことができる

 ある尊敬できるエンジニアが…
「コードのAuthorに自分の名前を入れたくないようなコードを書くな」
 …と言っていました。
 これはプロダクトやサービスでも同じようなものだと思います。

 自分達チームがリリースしたプロダクトやサービスを街中やインターネットで見かけた時に胸を張って「自分達が作ったもの」と言えますか?

 前述した「顧客により価値の高いものを提供することができる」内容にも関係しますが、私が過去に経験していたやり方のいくつかでは、不本意なコード、ユーザインターフェース、機能群を持ったシステムを提供せざるを得ないことがありました。

 アジャイルでは徐々に顧客と一緒にシステムを作り上げていくので、顧客はもちろん自分達チームにとっても「誇り」と思えるものになる可能性が高いと思います。

 「このサービスは僕が作ったんだよ」と家族や友人に言いたくありませんか?

6. またこのチームで仕事をしたいと思うことができる

 私自身はアジャイルで一番好きなのはこれです。
 これは「アジャイルな開発をしたから思った」「アジャイルな開発でないから思わなかった」わけではありませんが、感覚としてアジャイルなチームで開発をすれば、ほぼ間違いなくこの感情を持ちました。

 私が過去に経験していたやり方のいくつかは「二度と〇〇の顔を見たくない」ということも残念ながらありました。

 でも顧客から「これが欲しかったんだ」という声をもらい、成功体験を積み重ねて、プロダクトに誇りを持っているチームだとそうはならないと思います。

 「またこのチームで仕事したい」という言葉を聞きたくありませんか?

7. 最後に

 私は「これまで書いたようなことをできる/したいからアジャイルをやろうとした」わけではありません。

 当時は色々悩んでいました。もちろん今も悩んでいます。
 「どうしたらお客様もハッピーになってチームも楽しく良い価値を提供できるんだろう?」を日々考えて、動いて、フィードバックを得て、改善してまた動いて…を繰返していく中でたどり着いた「こういう状態で働きたい」という形が自分なりのアジャイルなプラクティスや姿勢に近かったという感じだと思っています。

 「アジャイルをやりたいんです」とたまにを聞きますが、その前に自分達とチームがしたいことが何なのか?を考えてみるってことも大事かと思います。

***********************
タグ:日常 agile
posted by yohhatu at 07:51 | Comment(0) | TrackBack(0) | 雑多 | このブログの読者になる | 更新情報をチェックする

2013年07月26日

「今日から始める自動化〜自動化入門講座〜」を開催しました!

 DevLOVE関西「今日から始める自動化〜自動化入門講座〜」をやりました。

#参加してくれた皆さん、会場を貸してくれたサイバーエージェントさん、お話してくれた皆さん、ありがとうございました!

◆きっかけ
 発表者の1人@moririringさんの「これまで自分がやってきた自動化のノウハウをまとめたので話してみたい。それに他の人の自動化の悩みなどを聴きたい」というのがきっかけでした。
 そこで大阪Jenkins勉強会でも発表していてJenkinsに詳しい@kazuhito_mさんを巻き込んで企画しました。
 
◆感想
 ある技術だけでなく、実際に「自動化」プロセスをやり始める際のポイント、また続けていく心構えなどにもフォーカスした話で、お二人とも事例とその時の感覚や感情など、気づいた点もセットでお話されていて「自動化って何からすれば良いのか・・・」と躊躇している人にとって、何かヒントになったのでは?と思っています。

 「最初からガッツリ」やるのではなく、徐々に作って、使ってもらって、フィードバックを得て、そこから新たな自動化を組み入れるという流れが実際に現場で定着するポイントです。
 また最初から自動化を(開発の中に)組み込んでおき、必要に応じて成長させる。そして成長させることのできるリソースを確保していることが大事です。

 たまに見聞きするのがこの「必要に応じて成長させる」リソースを確保していないパターンがあります。
 Jenkinsをメンテしたり、自動化してより楽になることよりも、開発そのものに忙殺されてしまうと、自動化による効率や安心感といった恩恵を受けることができません。
 すると、いつまでも忙しい状況が続き、「自動化を成長させる」リソースが取れないという悪循環になります。

◆ふりかえり
Keep:
1:テクニカルな面(だけ)でなく、どういう風にしたら導入できそうなのか?という風にお話が聴けた。
2:「(DevLOVE関西に来たことがないという)同僚と一緒に来ました」という人が多かった。

Problem:
1:(時間的に厳しかったが)ダイアログを2回に分けても良かった。

Try:
1:@kazuhito_mさんの『仁斤曰く 「”手間業”蔓延り易く、 “楽”成り難し」』は飛ばし気味で事例紹介も半分はスキップしていたので、どこかでフルバージョンを聴いてみたい。

#DevLOVE関西のアイデアや検討している勉強会はFacebookのグループDoorkeeperのコミュニティで公開していますので、興味がある方はご参加ください。
posted by yohhatu at 07:58 | Comment(0) | TrackBack(0) | 勉強会 | このブログの読者になる | 更新情報をチェックする

2013年07月22日

「開発スターターキット」を開催しました!

 もうかなり前の話になりますがDevLOVE関西「開発スターターキット」をやりました。

#参加してくれた皆さん、TAの皆さん、ありがとうございました!

◆きっかけ
 (募集サイトにも書いていますが)プロジェクトでいざ開発が本格的に始まった時や顧客に見せるという時になって、やれ「CI環境が用意できていない」「(自動デプロイでなく)お客様に見てもらうのに毎回時間がかかる」などというバタバタを何度か経験していました。

 これを開発の初期段階でサクッとベースを作ってそれを必要に応じてメンテしていくリズムになれば、バタバタは減るんじゃないか?と思ってこの企画をスタートしました。

◆準備
 ハンズオンは(DevLOVE関西として)あまりやっていなかったのと割とTAの皆さんも新しい要素があったので、割と準備はしました。
 「どんな内容にするか?シナリオはどうするか?」といった打合せ、「実際にできるか?どんなところで引っかかりそうか?」といった素振りをそれぞれ2回ずつしました。
 相談は主にFacebookグループで、タスク管理はTrelloで行いました。

#だいたいどんなことをやったか?ってのはこちらにアップしています。

◆当日
 10時開始にも関わらず、ほぼ全員が時間通りに集まっていました。

 (ちょっと最初はバタバタしましたが)午前中は概要の説明、チーム作り、環境確認、JenkinsでのJob作成・・・といった感じで進めていきました。
 TAでランチを食べながら、午前のふりかえり、午後の進め方を確認して午後へ向かいます。

 午後もサンプルアプリケーションのデプロイ、プラグインの追加、Seleniumでの動作確認、サンプルアプリケーションの機能拡張等々という感じでやっていきました。

 また、ちょくちょく時間をとって、質問コーナーを作って、TAや参加者同士が話し合ったり、今回使っている技術をテーマにしているコミュニティ紹介をしつつ、一気に駆け抜けていきました。

◆ふりかえり
Keep:
1:自由に動けるTAが2人いたので、問題の共有やちょっとしたインフラ面でのトラブルにも対応できた(TAは全部で6人いて、1テーブル(6人の参加者)に1人という感じで4テーブルありました)
2:再利用できるコンテンツができた(今回参加した人は同じことや続きをやれたりできますよ〜)
3:手を動かすだけでなく、質問の時間を取って次のステップや情報を伝えることができた
4:(本番前に)TAの皆さんが実際に色々調べることができて勉強になったと言ってくれた

Problem:
1:1日のハンズオンはやはり疲れた。私はタイムキーパーや進行だったけどそれでも疲れたので、参加者やTAの方はもっと疲れたんじゃないかな。今度やる時はもう少しタイムスケジュールを考えよう
2:参加者皆さんの個別の理解度までは分からなかったので、「言われた通りにやっている」だけの人がいなかったか少し心配(そんな印象はあまりなかったけど)

#DevLOVE関西のアイデアや検討している勉強会はFacebookのグループDoorkeeperのコミュニティで公開していますので、興味がある方はご参加ください。
posted by yohhatu at 09:21 | Comment(0) | TrackBack(0) | 勉強会 | このブログの読者になる | 更新情報をチェックする

2013年07月09日

「カンバンゲーム」と「宝探しアジャイルゲーム」ワークショップに参加しました!

 DevLOVE関西で「カンバンゲーム」と「宝探しアジャイルゲーム」ワークショップを行いました。

#参加してくれた皆さん、会場提供してくれたシナジーマーケティングさん、 "やっとむ" こと 安井 力(@yattom)さんありがとうございました!

◆発端
 「カンバンゲーム」を以前参加した京都アジャイル勉強会でやった時の話です。
 タスクボードを使い慣れているつもりでも、このワークショップの学びや気づきといったポイントがしっくり来ませんでした(楽しかったのですが)。

 そんなこともあり、京都アジャイル勉強会の主催者である@toshiotmさんと@Posauneさんと「このワークショップの考案者であるやっとむさんを呼ぼう!」と話をしたのが発端でした。

◆カンバンゲームの感想
1:Pullの難しさ
 2パターン目までと3パターン目では明らかに違うカンバンでした。
 言葉の定義は色々あると思いますが、前者が「タスクボード」、後者が「カンバン」という感じでした。

 3パターン目では、後工程がPullできないにも関わらず、作業に取りかかろうとして立ちつくしてしまうシーンもありました。
 Pullの考え方に慣れて効果を出すまでが難しいように感じましたし、勉強と実践が必要な感じでした。

2:「もっと頑張る」ソリューションはダメ
 あるProblemに対してこの「もっと頑張る」ソリューションで解決しようとしましたが、どこか不自然になったりしてうまく行きませんでした。
 しかし現場ではこの「もっと頑張る」がよく使われているよなぁと苦笑いしている方も多かったです。

3:Problemをタスクに紐付ける
 これは現場でもすぐにできる工夫です。

 「問題」と「タスク」を結び付けるのではなく、「問題」と「自分(担当者)」を結びつけてしまっているとこういうのは明らかにしづらくなるので、チームの状態を見るのにも使えます。

◆「宝探しアジャイルゲーム」
 私はビジネス側のロールでしたが、市場はすぐに変化するし、そこでの判断も難しく、本当に頭を使いました(終わった時にはヘロヘロでした)。

 開発側に「なぜ」「どういう狙いで」を全然説明できなかったので、開発側は「要求が来ない」「来てもそれがなぜなのか分からない」という、実際の現場でも見かけるストレスを感じていたようです。
#1ラウンド毎の時間の制約も絶妙でした。

 競合するチームの「今の立ち位置」「どこに向かおうとしているか?」「彼我の差はどれくらいあるか?」が【明確に分かろうと思えば分かる】という状況も判断に時間を取られ、決断が難しくしていました。

 開発側との協調という面では、もっとビジネス側のマップを見てもらうなど、やりようがあったと反省しています。 
 また、スクラムマスターがいるともう少しスムーズに回ったのでは?とも思いました。
 大きな目的は一緒にせよ、目の前のミッションが違う2つのロールだけでは衝突しがちでしたので、時間管理や衝突点の整理、「大丈夫だよ」という声かけ1つで色々判断やアクションが変わったかと思います。
#この辺は普段仕事でしているはずなのに、「ビジネス側のワガママ」を押し通していました。開発側の皆さん、ごめんなさいでした。

◆懇親会
 ここでも色々濃い話ができ、自分の悩みだった「スクラムマスターとして、プロダクトオーナーやチームとの距離感」という話をやっとむさんとお話できたのが本当に良かったです。

 わざわざ「このワークショップをやってみたいから!」という理由で東京から来てくれた方もいたりして、やって良かったです。
 ちなみに「宝探しアジャイルゲーム」は東京でのXP祭り2013で行われるそうなので、興味ある方はぜひ参加してみてはいかがでしょうか?

#DevLOVE関西のアイデアや検討している勉強会はFacebookのグループDoorkeeperのコミュニティで公開していますので、興味がある方はご参加ください。
posted by yohhatu at 08:24 | Comment(0) | TrackBack(0) | 勉強会 | このブログの読者になる | 更新情報をチェックする

広告


この広告は60日以上更新がないブログに表示がされております。

以下のいずれかの方法で非表示にすることが可能です。

・記事の投稿、編集をおこなう
・マイブログの【設定】 > 【広告設定】 より、「60日間更新が無い場合」 の 「広告を表示しない」にチェックを入れて保存する。


×

この広告は1年以上新しい記事の投稿がないブログに表示されております。