-
gen_nakami
- 1656
- 0
- 0
- 1
-
- いいね！1
秀玄舎の中の人
@gen_nakami
和智さん 自己紹介中。 略歴。 猫好き。 ITアーキテクト。 @digitalsoul0124 翻訳。 はてブロも書いてらっしゃいます。 → /dijitalsoul #gen_agile
2012-06-23 14:21:20
秀玄舎の中の人
@gen_nakami
いきなり和智さんからの質問「今日なにが聞きたいですか？」 → Q.どうゆう動機でCDが生まれたのか？ その背景は？ Q.それによってナニが変わるのか？ Q.純粋にCDとはナニなのか？ Q.導入に関して敷居が高いのか？簡単に導入できるものなのか？ #gen_agile
2012-06-23 14:24:51
秀玄舎の中の人
@gen_nakami
質問の続き → Q.実質的にどうゆう効果があるものなのか？ Q.CDによって何ができるのか？ Q.成功するための人的・マインド的な要素は？ Q.他社ではどのような取り組みになっているのか？ #gen_agile
2012-06-23 14:26:44
秀玄舎の中の人
@gen_nakami
”継続的デリバリーのエッセンス” AgileだろうがWFだろうがV字を描く。 継続的デリバリー（以下”CD"）は、V字の後半＝上っていく部分＝検証 で活用される。 #gen_agile
2012-06-23 14:28:49
秀玄舎の中の人
@gen_nakami
CDの中核を一言でいうと 「コードを1行書き換えてから、それがデプロイするまでにどれくらいかかるでしょう？」 という質問に集約される。 コードレビュー、ユニットテスト、結合テスト、品質指標チェック、データ移行・・・ 積み上がって大変な時間がかかる。 #gen_agile
2012-06-23 14:30:39
秀玄舎の中の人
@gen_nakami
コストやスケジュールだけではなく、人の問題もある。 ユーザー、運用チーム、開発チーム・・・ チーム間でロス、コストがかかる。 リリースにこぎつけたら そこからまた一悶着ある。 リリース手順書、作業、、、 時間がかかるだけでなくミスも発生しうる。 #gen_agile
2012-06-23 14:35:23
秀玄舎の中の人
@gen_nakami
そこで、デプロイまでの流れを 信頼できる、可視化された、自動のプロセスにする 具体的には デプロイメントパイプラインという「定義されたつながり」にする。 ちなみにパイプラインとは 水道管のことではなくコマンドのイメージ。 #gen_agile
2012-06-23 14:36:09
秀玄舎の中の人
@gen_nakami
CDを実践するために・・・ まずはチーム共有の構成管理を行う。 セントリックなリポジトリをまずは構築する。次に「変更があったら常にインテグレーション≒ビルドをする」、さらに「常にテスト環境にデプロイする」 #gen_agile
2012-06-23 14:42:55
秀玄舎の中の人
@gen_nakami
Q.「構成管理に変更が入る度にテスト環境までデプロイするか？」 A.「今のプロジェクトではインテグレーションまでは自動で、デプロイは人の判断を入れて随時やっている」 #gen_agile
2012-06-23 14:43:56
秀玄舎の中の人
@gen_nakami
ここまでは比較的容易。 デプロイ後のテスト戦略になると少し複雑化する。 プロジェクトによって結合→ST→運用テスト などの環境は多岐にわたる。 重要なことはこのプロセスを可視化しておくこと。 #gen_agile
2012-06-23 14:47:10
秀玄舎の中の人
@gen_nakami
Q.「継続的(continuasu)という言葉は、『継続的に繰り返す』ということなのか『連続した』という言葉なのか？」 →A.「語源はAgile宣言に依る。 システムは変化し続けるので、それを継続的に届けるという意味」 #gen_agile
2012-06-23 14:53:16
秀玄舎の中の人
@gen_nakami
Q.「自動化が前提なのか？」 A.「本では自動化を推奨している。現実問題としては環境的に自動化できない場合もある。」 #gen_agile
2012-06-23 14:56:43
秀玄舎の中の人
@gen_nakami
Q.「CDのデリバリー先はエンドユーザーか？」 A.「本質的にはそうです。 が、Water Scrum Fall と揶揄されるように、経営会議に通すときや、サービスリリースするための手続きなどはCDの外になることはある。それが必ずしも悪いことではない」 #gen_agile
2012-06-23 15:00:01
秀玄舎の中の人
@gen_nakami
Q.印象的に、開発寄りのプロセスは自動化しやすく、ユーザーよりは自動化しにくい。 A.ツールで受入テストを自動化する風潮を悪いとは思わない。が、結局全てを自動化できない。大事なのはステータスが可視化していること #gen_agile
2012-06-23 15:02:47
秀玄舎の中の人
@gen_nakami
Q.自動化するとなるとツールは重要？ A.重要ではあります。リポジトリはSVN対DVCS。ゆくゆくはDVCSに軍配が上がるのではないかと思っている。こうした取り組みをする会社ってだいたい有償ツールへの抵抗感があり、JenkinsとRMの組み合わせなど主流。 #gen_agile
2012-06-23 15:10:31
秀玄舎の中の人
@gen_nakami
（A.続き）ツール云々よりも、マインドセットが重要。ソースを抱え込まない とか落ちるコードをコミットしない とか、エラーをコメントアウトしない とか。 そうしたべからず集は本に載ってます。 #gen_agile
2012-06-23 15:11:51
秀玄舎の中の人
@gen_nakami
導入するキモとして、可視化されたプロセスをできるだけ初期段階で実用化されていること。 テストフェーズになってやおら始めようとすると コードがいっぱいでカオス みたいなことになる。 #gen_agile
2012-06-23 15:14:52
秀玄舎の中の人
@gen_nakami
Q.やったらいい というのは感覚的にわかる。が、実際にベンダーにこれをやらせるにはどうすればいいのか？ A.開発者と運用担当者が早い段階でチームになることが重要。という話をできるかどうか。受託が多い日本では難しいが、逆にだからこそ意味がある。 #gen_agile
2012-06-23 15:28:09
秀玄舎の中の人
@gen_nakami
Q.複数のプロジェクトがある場合、それぞれがパイプラインを共有する必要があるか？ A.結合するシステムは共有したほうがよい。Agileの基本理念は「痛みは早く」とうことなので、ビッグバンインテグレーションは避けたい。 #gen_agile
2012-06-23 15:32:28
秀玄舎の中の人
@gen_nakami
Q.導入にあたって、敷居が高いと思うところは何か？ みなさんどうですか？ A1.ユーザーを巻き込む箇所になるといきなり難しい。 A2.データ変更が入るような改修はデータ移行がネックになる。 #gen_agile
2012-06-23 15:42:27
秀玄舎の中の人
@gen_nakami
どうしても議論がAgile になってしまいます。 業務システムにおける、Agileの有効性について。日本ではSIという存在がいて、ユーザーはSIに完成品を発注する文化。ベンダー側は大手ゼネコンもAgileと言い出すが、ユーザーでは用語すら出てこない。 #gen_agile
2012-06-23 15:59:54