『第16回 #TFSUG: 大阪vol.2 』に参加してきました

  • 2013.02.26 Tuesday
  • 01:15
昨日、『第16回 #TFSUG: 大阪vol.2』 に参加してきました。

■デブサミ2013Remix チーム×ツール Team Foundation Server & Service 共感しActionできる開発基盤 アルティメイタム


日本マイクロソフト:長沢智治さん(@tomohn)による、デブサミ2013講演内容を再構築されたもの講演して頂きました。



気になった点をピックアップすると
・Actionable
 →意味は『すぐに実行できる実行可能な実用的な、実行力のある』
 →Actionableな開発環境とは、要求からリリースまでのサイクルをキープし続けること

・ビジネス価値を提供し続ける
 →TFSはそのためのツール
 →ITは顧客中心となっていく
 →顧客に権限が移行していく!?


あとはTFSの動作デモなどもありとても勉強になりました。
一番気になったのは、今後顧客に権限が移行していくという点。
顧客とSIerの関係は、会社の垣根を越えて、社内開発チームのような関係になっていくのでしょうか?



■アジャイル開発における品質向上の取り組み


細谷さん(@yasuohosotanによる、日科技連 ソフトウェア品質(SQiP)で講演された内容の再講演でした。
SQiP講演時のtwiiterまとめはこちら

日科技連 ソフトウェア品質 第6回特別講義 「アジャイル開発での品質向上への取り組み」

気になったキーワードをピックアップ!
・スクラム(Scrum)
 →3つの原則
  →透明性 = チーム状態を周り(顧客含む)に見える化
  →検査 = スプリントごとに振り返り
  →適応 = 検査内容を次に反映
 →スクラムマスターとは?
  →ルールを守る者
  →チーム内外どちらに対しても公平
   →チーム外でルール違反が多発するのでチームを守る者というイメージがあるが誤解である。
 →スクラムの境界線
  →スクラム外の世界では根回し重要! 

・品質とは
 →お金と釣り合うのが品質
 →一度品質を落とすと元に戻すのはとても大変
  →スクラムマスターはその点を気にする

・アジャイルテスト
 →4現象

・ドキュメンテーション
 →誰のためなのか?
 →何に使うのか?
 →いつ必要となるのか?

貴重なお話を聞くことができました。


■ALM Summit3レポート


再度、長沢智治さん(@tomohn)によるALMサミットのレポート紹介でした。
詳細資料は下記URLを見てほしいとの事でした。

ALM Summit 3 の最速参加レポート

講演中の気になったキーワードをピックアップすると、
・Be Agile
 →より俊敏に!

・Stay Lean
 →無駄のない動き!

・Scale UP
 →もはや、リーンはスタートアップだけではない。
 →スタートアップだけでなく、エンタープライズでもリーンを使う。


■まとめ(感想)

継続的デリバリーが常識となっていくなかで、ツールの重要性を再確認しました。
しかし、ツールを使う為には、チームのルール作りが大切ですし、そのためには組織改革まで必要な場合が多いのではと思います。
時代に取り残されないよう、まずは意識改革という辺りから一歩ずつ進めていきたいと思います。




第8回 TFSUG:アジャイルなんとか書籍発売記念!TFSUG大坂の陣 に参加してきました!

  • 2012.06.21 Thursday
  • 02:38

 本日、大阪マイクロソフト社でおこなれた「第8回 TFSUG:アジャイルなんとか書籍発売記念!TFSUG大坂の陣 #tfsug」に参加してきました。

本の販売イベントのはずなのに、宣伝が全くない?という変わった内容で、その分アジャイルな色々な話を聞けました。

忘れないうちに内容をメモメモ。


■TFSとは?簡単な説明(@tomohn)

・TFSとはVisual Studio Team Foundation Serverの略
・Continuous Value Delivery
(開発だけでなく、運用も見据えたビジネス価値を届けるTOOL)
・流れを大切にするTOOL
・TFSにはAPIも用意しているの自由にカスタマイズすることも可能。
・Scrum開発をベースにしているので、親和性が高い
・TFSはExcelのインターフェースを持っている
(データ自身はあくまでもTFSの中、Excelへはグラフや表の表現で使用)
(マネージャーなどVSを使わない人などの使用を想定)
(プログラマなどはVSやIEで閲覧可能)
(テスターさんなどは別途、テストマネージャーというTOOLが用意されているらしい)
・TFSはテスト機能にすぐれている
(テスターさんのテスト操作を動画でも保存)
(テスト環境は仮想PCとして準備されている)
(手動テストも2回目からは自動テストが可能)
・コンパイラエラー以外にもアークテクチャー違反検出ができる
(コード重複やセキュリティ違反など色々あるみたい)
・ゲートチェックイン機能
(リボジトリにコミットするときに、自動的にテストを行う)
(テスト違反だとコミットされない。つまりリボジトリを汚す心配がない!)
・Visual Studioの開発者は3600人ぐらいいるがTFSで運用している。
・日本ではMSN JapanがTFSを使用している。

関連動画はこちら http://www.youtube.com/tomoharunagasawa


■TFSを使ったアジャイル開発」(@yasuohosotani)

えーとタイトルに偽りあり?
正確には、原因結果グラフ駆動かな。

原因結果グラフ(CEGTest)を使って、そこから開発を行うというスタイル。
デモとして新人2人の方が実演してくださいましたが、なんと入社以来ペアプロしか経験がないというなんと恐ろしい素晴らしいお2人でした。

主な内容としては、
・CEGTestでデンジョンテーブルを作成
・そのパターンをTDDで開発していくというもの
・新人やケースごとにやりたいという人に向いている
・コードを書きながら考える人には向かない
・CEGTestをカスタマイズしていて、内容をエクスポートできる
・エクスポートしたものはまたインポートもできる。
・つまり、エキスポートした内容をソースに張り付けておくとあとでどんなテスト内容だったのか?その意図を読み解くことができる・またヘルプ用HTMLとしてデンジョンテーブルを見ることも可能

原因結果グラフ駆動は、TDDに慣れていない人に対して入門としてはとても良いと思います。


■TFSと継続的デリバリー(@SHIBAO800

東京からこられたとても面白い方。
チームの自己組織化力を高めると、ぼっちになるという驚愕の真実を教えてくれましたwww
マネージャー→Scrumマスター→Scrumコーチ→ぼっち

・インドに発注してみたが、インドはウォーターフォールに慣れていなかった
・プロジェクト途中でアジャイル形式に変更して納期には間に合った
・スモールスタート、スモールサクセスが大切
・ゴールの共有のために、定期ワークショップや合宿を行った。
・合宿のゴールは、みんなでインセプションデッキを作ること。
・アジャイル導入には対立構図の解消が重要
(導入反対者vs導入推進者ではなく、問題vsチームという形にしていくことが重要)
・インドには開発環境をVM(仮想PC)に入れて配布
・開発環境に約2か月要した
・コンテンツデリバリーではブランチは切ってはいけない
・リスク・ベース・テスト
(ビジネス価値が高いものから優先開発)
(致命傷となるバグがあればそこから開発。顧客が気づきにくいバグは優先度が低い)
(開発の難易度ではなく、ビジネス価値ごとにスケジュールを考慮する)
・デスマーチ度合をみんなが見える場所に紙に張る
(上司やら組合が見たりするので、マネージャーやチームメンバーにも緊張が生まれる)
・USAの問題として開発は早いが、実際にユーザが使えるようにする納期時に時間がかかる
・つまりリリースにて遅延が発生している。
・上流工程はWF →開発はアジャイル →リリースはWFのような開発が多い。
・ビジネスユーズ駆動というのもある
(客の価値で、開発優先度を決める)
・MVP(Minium viavle production)
(客全体から意見を聞くのではなく、リアクションが良いイノベータ層から意見を聞く)
(スピード重視となるので、クラウド開発との親和性が良い)


■Scrum Boot Camp体験記(@shioi

6/16に東京で行われたScrum Boot Campの話。

・ウォームアップとして一定距離を飛ぶ紙ヒコーキの数を競う
・繰り返すことに予想制作数と実際の数は一致してくる
・プロダクトバックログの振り返り
・作業量の見積は最初はざっくりでOK.正確な見積もりは必要ない。
・タスク内容について共通認識されているかが重要。


メモし損なった話もあり、
濃い話がたくさんあった2時間でした。

またジャンケン大会でプランニングポーカーを頂きました。ありがとうございます。.


Scrum BootCamp大阪に初参加 !

  • 2012.06.17 Sunday
  • 02:30

 本日(2012/06/16)にScrum BootCamp大阪に参加してきました!

まさかの開始時刻勘違いで、多少遅刻してしまいました。


 ■10:00〜 Scrum基本のキ@nawoto
http://www.slideshare.net/nawoto/summary-of-scrum-guide

個人的気になった点としては、

1.スクラムとはプロジェクトを維持していくための物
2.タイムボックスという概念
(通常、○個のタスクを完了させるのに、●時間かかりますという言い方になるが、タイムボックスの場合だと、●時間では○個のタスクだけ完了出来るというように逆の発想となる)
3.スクラムとは短い期間で成果物を量産していくこと
4.繰り返し作業を行うため、一つ一つのタスクを小さくすること
5.スクラムに必要なスキルとは、タイムボックスに入るようにタスクを分割する能力
6.情報の共有化。これ重要。

情報の共有化の重要性をトランプを使ったゲームで確認しました。
詳細はネタバレになるので記載しませんが、実際の現場でよく起きるような事象を上手くトランプゲームで表しているなと感心しました。

■13:00〜 川口さんショー(@kawaguti

Scrumを実践された中での気づいた点やノウハウなどの紹介がありました。

1.一日を4つに分ける(AM。PM1、PM2、EX)
2.1週間だと10枠。2週間だと20枠あることになる。
3.2週間20枠を1サイクルとして、その枠数内で会議や作業等をタイムボックスと見立てる
4.最初の月曜日に当タイムボックスで行うことの打合せ
5.最後の金曜(2週間目の金曜)で作業振り返りを行う。
6.完了しなかったタスクがあった場合、改めて次回タイムボックスでどうするか打ち合わせ
7.予測到着地点(ペロシティー)より先の見積もりをしない
8.タスクボードには発生した割り込み作業も書き込む
9.そうすることで、割り込み量も含めたペロシティーの精度が上がっていく
10.チームの結束重要。



■14:00ぐらい?〜アジャイル計画づくり

アジャイルな計画を立てる際の注意点などをゲームなどを通じて学習。
要点としては、
1.タスクには優先度がある
2.タスクの表記・表現には注意すること
(何のために、誰のために、何故必要なのかがわかるようにすること)
3.タスクはチーム内で共通認識すること
4.良いタスクとは「他と独立」「価値がある」「テストできる」「小さい見積もりができる」
5.見積もりは基準のタスクを決めたら相対評価で行う
(例として、今いる部屋の高さを測るというのを紹介されました)
(○○mというのは判らないが、誰か人を基準にしてその人●人分と測ると分かりやすいという話)
6.そもそもアジャイルでは見積もり≒当てずっぽうなので気軽に行う

紙ヒコーキ作ったり、ティッシュでこより作ったり色々しました。


■16:00ぐらい?〜スプリントの過ごし方
http://www.slideshare.net/nawoto/ways-and-means-of-spending-your-sprints

要点としては、
1.サイクル単位を2週間とする
2.1サイクル内で行う作業量を見積もる
3.2週間内の作業量なので、見積もり精度も高くなる
4.もし失敗しても2週間分の作業量なので大きい損傷にはならない。

スライド見ていたので、あまりメモっていなかった。



■17:00ぐらい?〜質疑応答祭り

質問されていた中で気になった点を抜粋

Q.質問
契約時にScrumやアジャイルという事を説明している?

A.回答
興味がある客には話すかもしれないが、無い客には説明しない。
またそういう客の場合は表面上はウォーターフォールで開発しているように見せかけて、内部でアジャイルしている。


Q.質問
初期に詳しいスケジュール設計を求められたら?

A.回答
無理だと正直に話す。
もし作成してもお互い不幸になるだけですよとも言う。



Q.質問
複数プロジェクトを掛け持ちしていて、優先度がすべてぶつかってしまった場合

A.回答
個々のプロジェクトで使える時間を最初に決めておく。
そして実際の作業時間をメモしていき、個々のプロジェクトで使用できる時間からペロシティーを測定し、プロジェクトに対応していくしかない。
また、引き抜きなどによりペロシティーが崩れてしまうような場合には、上司にチームが変わることでのコスト増加について説明する必要がある。


Q.質問
目標達成不可能とわかった時の対応は?

A.回答
まずは目標達成における必須項目の再検討。
本当に必要なものだけとしてそれでも間に合わない場合は、必須項目内で優先度検討。
これは経営判断が伴ってくることになる。


Q.質問
機能の最適化などはどのように行うのか?
負荷対策とはいろいろ。

A.回答
基準として、レビューしづらいのは設計段階では考慮しない。
また実装中気づいた必須処理は必ずメモとしてピックアップしておく。
その後、都度対応する項目なのか、不必要なのか検討していく。
負荷テストなどは実践として3スプリントごとに行っている。

Q.質問
ウォーターフォールからScrumへの移行はどうやったの?

A.回答
客に話した時に誘ってみた。
チームに対しては勉強会という形で行った。
問題としては自信が発注元の場合、発注先への教育義務を自身が負えるのかが問題。
すべてがScrumに向くということではないので、案件により見極める必要があるかも。


Q.質問
優先度付けが本気ではない、またはすべて「A」の客への対応は?

A.回答
その場合、後半の仕様変更や要件定義ブレを発生しやすいので、早めに動くものを用意して客の注目をこちらに引き付ける必要がある。
まずはそこからしないと、その状態の客に何を話しても無駄となる場合が多い。


Q.質問
苦労場話あれば教えてください。

A.
上司への対応(笑)



メモはしたけど理解不足で書ききれない項目も多数。
なかなか濃い8時間でした。
またあれば参加したいなー。



 

PR

calendar

S M T W T F S
     12
3456789
10111213141516
17181920212223
24252627282930
31      
<< December 2017 >>

selected entries

categories

archives

recommend

カンバン仕事術
カンバン仕事術 (JUGEMレビュー »)
Marcus Hammarberg,Joakim Sundén

recommend

recommend

profile

search this site.

others

mobile

qrcode

powered

無料ブログ作成サービス JUGEM