ラベル guideline の投稿を表示しています。すべての投稿を表示

2015年9月2日水曜日

概要

やってみたい記事を書いて一ヶ月後に実現したのでどんな感じでやったかメモしておきます

メンバー

4人 (男:女=3:1)

合宿先

沖縄
宿泊先 : にらい恩納

日程

2015/08/29 - 2015/08/31 の 2泊3日

料金

飛行機代 : 37,180円
宿泊代 : 15,500円
レンタカー：2,355円
食費：約10,000円

-> 合計：65,035円/1人

合宿の記録 (時系列)

初日
- 7時起床
- 7:30 - 9:30 成田空港移動
- 9:30 - 10:30 出発準備 (出発が11時に遅れる)
- 11:00 - 14:30 飛行機内 (30分くらい開発)
- 14:30 - 15:00 レンタカー手配
- 15:00 - 15:30 食事へ
- 15:30 - 16:20 食事完了
- 16:20 - 18:00 宿泊地へ移動
- 18:00 - 18:30 買い出し
- 18:30 宿舎到着
- 18:30 - 20:00 開発
- 20:00 - 21:00 夕食 (食べながら開発)
- 21:00 - 23:00 開発
- 23:00 - 24:00 就寝準備
- 24:00 就寝
二日目
- 10:00 起床 (他の人は 8:00 とかに起きて開発していた)
- 10:00 - 13:00 開発
- 13:00 - 15:30 食事＋買い出し
- 15:30 - 16:30 海
- 16:30 - 17:30 開発
- 17:30 - 20:00 BBQ
- 20:00 - 23:00 開発＋プレゼン作成
- 23:00 - 24:00 全員でプレゼン
- 24:00 就寝
三日目
- 10:00 起床 (他の人は 8:00 とかに起きて開発していた)
- 10:00 - 11:00 チェックアウト準備
- 11:00 チェックアウト
- 11:00 - 16:00 フリー行動
- 16:00 - 18:00 那覇空港へ
- 18:00 - 18:30 出発準備
- 18:30 - 21:40 飛行機
- 21:40 - 22:30 空港から電車に乗り換え
- 22:30 - 24:00 電車で帰宅
- 24:00 帰宅

まとめ

開発時間：10時間30分＋α
(＋αは移動の時間や食事の時間もちょろちょろやっていた分)

所感

Bad
- とにかく移動が多すぎた
- 移動中開発したが、集中できない
- コテージが内陸にあり、WiMAXが届かなかった (キャリアの回線は届いた)
- コテージに電源プラグが少なく、電源タップがなかったらやばかった
Good
- とくかく楽しめた
- 一応全員アウトプットすることができた
- 宿泊したコテージの雰囲気は開発合宿にピッタリ
- 普段とは違う開発環境を味わうことができた

感想

ガチで開発するなら会議室のある近場の民宿がやっぱりいいなと感じた
いいわけだが、今回は旅行も兼ねていたので開発が少なくなってしまったのは仕方ない感じか
(会社にコミットメントも約束していなかったので、、、)

費用が少し高くついてしまった
ツアーではなく、それぞれ別で申し込んだのでそうなってしまった

とりあえず楽しかったのでOK
たまには南国で開発するのもいいなと思った

2015年7月22日水曜日

概要

非日常的な環境で開発をすることで、おそろしく開発効率が上がるのではないか
「仕事」として行く気はないので気軽に行こう
成果のルールは決めない
南国でやりたい

唯一のルール

必ず最後に何をしたのか、していないのか、作ったのかなど「発表」をすること
昼飯と晩飯はみんなで食べましょう

欲望メモ

仕事はしたくない、とにかく自分がやりたいことをやってみよう
オフィスでない非日常的な環境で開発することで効率アップ（するかどうか）を体験してみる
あれ、オレリモートでも仕事できるじゃん
OSS、クローズドは問わない
ホテルとかじゃなくて、Airbnbとかでコテージとか借りてやりたい（ホテルでもいいと思うけど）
食事、睡眠以外の時間は基本的にフリーでコーディング、場所も問わない、飯の時間は決めておくし、みんなで一緒に食う
フリー時間はコーディングすらしなくてもOK、遊んでもOK
コーディングスタイルは自由、ペアでもチームでも個人でもいい
メンバーは一応知人を中心に 3 - 5人、多すぎはダメ
コーディング中はみんなバラバラだと思うので連絡は Slack とかのチャットを使おうと思う
1泊2日 or 2泊3日
あえて土日返上
集合解散は最悪、現地集合 - 解散でもOK
開発環境（ネットワーク、ディスプレイ）は知らん、自分で何とかする
移動とかも知らん
最後の発表はフリーフォーマット、特にテーマはなし
たぶん単発、定期的にやる気はないです
ぶっちゃけ自分が開発したいだけ

2014年8月8日金曜日

概要

1年弱くらいチケット駆動開発をして来て感じたことがあったので今更ながらメリット・デメリットの観点でまとめてみました

チケット駆動開発とは

作業をタスクに分割しBTS（Bug Tracking System／バグ管理システム）のチケットに割り当てて管理を行う開発スタイル

Wikipediaより一部を抜粋

要するに「やること」や「やりたい」ことをチケットという単位で管理し開発を進める手法
Githubのissueみたいな感じ、Closeされれば終了

また今回、私はBTSにRedmineを使いましたのでRedmineでの話を中心に記載したいと思います

どんな使い方をしていたか

特殊な使い方をしていたつもりはないので至って普通かと思いますがコンテキストをまとめておいたほうがいいと思うので簡単に記載します

チケット
- チケットの発行（開発タスク、bugfix、ツール開発、テスト実施、次期開発、やりたいこと、調査依頼等々何かあれば発行）
- チケットへのカテゴリ付与（必須）
- チケットへのトラッカー付与（必須）
- チケットのステータスの活用（終わった場合は必ず終了にする）（必須）
- チケットを担当者に割り当てる（必須）
- 本文、タイトルは基本フリーフォーマット、開始日、進捗率も特にルールはなし（任意）
- 子チケット、関連チケットも自由に作成可能（任意）
wiki
- 基本はフリーフォーマット
- 記事録、ノウハウ、検証記録等を記載していく
- 記載する際の基準はない（このタイミングで、これを書いてねみたいなのはない）
文書管理
- ルールは特に無し、置きたいものを自由に置く

基本的には上記の機能を使うことが多かったです
上記を踏まえて運用した上でのメリット・デメリットを考えてみました

メリットとかイケてるところ

進捗を把握しやすい
全てはチケット管理なのでシンプルかつ明確にタスク管理することができると思います
進捗率や期日も設定できるのでガントチャート的な見え方もできてGood
優先度を駆使すれば今やるべきことがすぐわかる
子チケットを駆使すればタスクのカテゴライズができて把握しやすい
マネージメントが簡単
日本の会社のようにヒエラルキー型の会社にはがっつりハマると思います
上の人がチケット切って「はい、これやって、これやって」とホイホイ下の人に割り当てればいいだけなのでマネージメントはめちゃくちゃ簡単
アサインしている人ごとにチケットも見れるのでリソースの空き状況もすぐに把握できる
チケットさえちゃんと作成できていればという点はあるが
ルールが勝手に出来上がる（出来上がった）
これはいい事象かなと思ってます
例えば、文書管理のフォルダ名とかwikiのタイトルとかは全くルールがない状態で初めたんですが、初めに誰かが作成した命名規則的なものを次の人がそれに沿って「いい感じ」に作ってくれるようになりました
例えば、wikiページは必ずYYYYMMDD_で始まるように記載していたら、他の人もそれに合わせて書いてくれるようになったりとか、文書管理のフォルダ名もはじめに00_hogehogeとか数字をつけるようにしていたら次のフォルダ名が01_barbarとかになって自然にルールができていたのはいいなと感じました
通知機能
チケットを更新するとメール通知できるので他の人の作業内容が把握しやすいです
自分はgrowlと組み合わせて担当者が自分にアサインされるとgrowlで通知してくれる機能を作ってチケットの見落としを防いでいました
低学習コスト
かなり個人的な間隔もありますが、そこまで勉強しなくても使えると思います
ツールにもよりけりですが、Redmineに関しては低いと思います
ただ、機能は本当にたくさんあるので使い込もうとするとそれなりのコストがかかると思っていただければと思います

デメリットとイケてないところ

クローズされない亡霊のようなゾンビチケットができあがってしまう
「よし、絶対やるぞ！」とその場の勢いで作成したチケットが半年後に誰にもアサインされずに残り続けてしまう
残り続けてしまうこと自体は「やるべきこと」なのでいいのですが、誰にもアサインされず「いや、これ誰がやるんだよ･･･」的な感じでみんなから無視され続けてクローズもされず、ほっとかれる現象が発生してしまう
こうなってしまうと一生消化されることがなく「やっほうがいいのかな･･･でも他に優先度高いことあるし･･･今更そんなのやってるなよとか言われそうだし･･･」とか、精神衛生上もよくない、疑心暗鬼、そわそわしちゃう
なのでそんなチケットが出来ちゃわないために「6ヶ月以上更新のないチケットはクローズして別チケットを発行して誰かにアサインする」とか「アサインを外して対応保留カテゴリに割り当てる」などルールを作ることが必要かなと感じた
ルールでどうにもならないときには「カンバン機能」や「API」もあるので可視化、自動化でシステムに解決してもらうのがいいと思います
チケットの粒度
なんでもかんでもチケットが切れる状況だったので、開発者それぞれでチケットの粒度が統一されていないのが微妙でした
これも「ルール」の問題なので事前に粒度のルールを決めておけばいい話なのですが、そもそも粒度をルール化するのは難しいという問題点もあります
やるとしたら粒度のルールというよりかはチケットを発行できる人を制限する感じかと思いますが、それもそれで開発者の自由を縛るようなルールなのでやるのは微妙かと思います
私の場合はだんだん各人が粒度を「暗黙的に」理解したので徐々によくなりましたが、最初のほうは1つのチケットにいろんな作業記録をコミットメントしまくってカオスな状況でした
検索機能が弱い
デフォルト提供されている検索がそこまで賢くないのが残念でした
せっかくチケットやwikiに貯めたノウハウもうまく取り出せないんじゃ意味がありません
検索が微妙だった分カテゴリやトラッカーを適切に付与してカバーしてましたが、さすがに規模が大きくなると検索なしでは厳しかったです
また、文書管理にあるファイル名と説明までは検索対象にできるのですが、ファイルの中までは検索対象にならないので、なるべく文書管理にノウハウを貯めるようなことは避けるようにしました
よくある設計書にオフィス製品を使っちゃう問題もありましたが、極力ドキュメント類はコードに落とすか、wikiに記載するようにしました

その他アンチパターン

wikiに動的に変化する情報を記載する
なるべくwikiには普遍的な情報を記載する
よくwikiにサーバ構成図などを書くが例えば頻繁にサーバが追加されたり削除されたりすると更新を忘れて管理が破綻する

まとめと所感

GoodかBadかで言うとGood
100点満点な開発方法ではないと思いますが、10点とか20点でもないです
man powerで解決しなければいけない面（ルールとか縛りとか）もありますが、システム的に解決できる部分もあるので、なんとかなります
全然、開発手法が決まっていなくてどうしたらいいかわからんときには、とりあえずチケット駆動にしておけばなんとかなると思います
チケットエンジニア
簡単に言うとチケットの進捗とか状況とかを管理する人
ゾンビチケットやアサインされていない人を見つけたときに適切にアサインしたりする人
マネージャではないので進捗管理とかタスク割り当てをするわけではなく、チケット駆動が回るために適切に振る舞う人
的な人がいると更によくなるとは思うが、そこまでしてやるかというのと
そもそも、そこにリソースを割り当てる人がいないという問題があるので正直やる価値はないと思うが、なんとなく思ったので記載
ツールは
今回はRedmineを例に話を進めましたが、それ以外にもめちゃくちゃあります
参考 -> バグ管理システム
「決定版はどれだ」という議論をするときっとキリがないのでここではしませんが、正直どれでもいいと思います
あえて進めるならオープンソースでまだ開発が続いているツールにするのがいいと思いますあとは、拡張機能が作れるとか

文字ばかりですが、以上です
これからもチケット駆動を続けるのでまた何かあれば別ポストでもして、今回と見比べて解決してる点とかしてない点とか比較すると面白いかなと思いました

2012年2月25日土曜日

今回の記事はかなり私事ではあるのですが、
小生エンジニアという仕事を一応やらせていただいており、一サービスを展開している
エンジニアとして毎日を過ごしております。
その中で（私的作業の中に）作業手順書を作成するという作業が結構な頻度で発生しております。
「作業手順書」という言葉が一般的に流通しているかどうかはわかりませんが、
簡単に言うとエンハンスやメンテのときに本番環境にデプロイ作業をする作業をすべて手順書と化し
作業日当日にはそれしかやらないという制約の元作業を行うためのドキュメントになります。
そんなドキュメント、作業手順書を大体、月に5件くらい書いています。
（多いときで10件くらい･･･）
私の中では「結構多い」と感じております。
（たぶん世の中にはもっとたくさんの手順書を書いていらっしゃる方がいると思いますが･･･）
そんな作業を淡々とこなしていることにいささか不安と不振を抱き始めた今日この頃
ちょっと思い立ったので「作業手順書」というものについて少し考えてみました。
本当に少しだけね。

そもそも作業手順書とは何のために作るのだろうか？
から考えてみました。以下考えたこと。

■なぜ作業手順書を作成するのか
・事前に準備した必要以上の作業を行わないことで作業ミス、作業漏れを防ぐ
（しか根本的な理由としてはないのかなーと･･･）

まぁ理由は理解したとして、今現段階で私が疑問に不振に思っていることを
率直に書いてみました。以下。

■疑問点、不信感をいだく点
・本当に作る必要はあるのか
・作業を行う人が手順書を書いて意味があるのか
逆にいうと手順書を書く人が作業を行って意味があるのか
・どこまで詳細に書く必要があるのか
・できる人が作業を行えば、手順書はだいぶ荒くても問題ないのでは
・手順書を作っている人的にはどうでもよいところをガンガン指摘される

ここから導き出される私的デメリット、以下。

■デメリットは
・人的コストが結構かかる
（どこまで詳細に記載するかによってくるが）
・定常化されている手順のコピペ作成によるリスク
（慣れすぎた手順、枯れた手順はレビューでもチェックが甘くなる）
・たとえば新規で作成した手順が本当に正しい手順かどうかを図る指標がない
・一人で手順書作成＋作業をしてしまうと他の人が作成、作業をできない手順書が
知らぬ間にできあがってしまう

やはり一番は「コスト」かなと思います。コストとリスク回避が等価交換になっている
のだとは思いますが･･･
とはいえメリットもあるはずということでメリット以下。

■メリットは
・記録を残せる
・誰がやってもできるようになる（属人化解消）
・必要以上の作業をしないことによるミスの防止
・本番に対するビビリがなくなる（ある意味デメリットでもあるのか･･･）

基本的には「安全」とか「リスク回避」とかそんな感じのキーワードが
当てはまるんじゃないかなーと思います。

以上のつらつら書いたことを見返してみてまとめてみました。
まとまってないですが･･･
何の参考にもなりませんが、共感してくる人がいたら仲間ですｗ

■まとめ
・手順書職人になってしまった段階でこの負のスパイラルからは抜けられない
・極力ムダなこと、余計なことを書かないようにし、修正が少なくなるようにする
（A型の人は手順書作成をするとおわります）
・人的コストを考えると手順書を作る手順をまとめておく（手順書の手順書）

以上
もはや愚痴ですね･･･ｗ
とりあえず書いたけどまた何か気づいたら追記してみよかな。

■P.S 20140108 自動化について
定型化された作業は自動化することでコストを下げられるかなと思っています
最近は（本当に定型化された）作業を自動化するようにしておりJenkinでのCDやcapistranoを使ってのコマンドの削減等をしています
またテストも自動化することで作業手順書に書く（であろう）確認項目の数を減らすようにしています

自動化することは本当にいいことだとは思うのですが、自動化することでデメリットも発生するかなと思っているので一応それも書いておきます
・自動化するためにプログラムやミドルウェアの操作、習得が必要
・自動化用のプログラムを「運用」する必要がある（エンハンス時のテストの修正や不具合修正等）
・教育することができなくなる、自動化されていることでボタン一発で作業やテストが完了するのでこれまで頑張って行っていた作業のノウハウをこれから来るであろう新しい人に教える必要がなくなる
・自動化に終わりはない（どこまでやるか、何のための自動化かを明確にしておく必要がある、たとえばこの自動テストは正常系のみを網羅するテストであるなど）

と書いてみましたが上記のデメリットが必ず発生すると考えても自動化は絶対やるべきかなと思います
やる理由の大きな目的は品質向上やコスト削減ですが、運用しているエンジニア（デプロイエンジニア）的には自動化することで精神衛生上もいいかと思います

自動化の作業を仕事でできるのが一番いいですが、小生は中々に難しい環境で結局あと回しになってしまっています
自動化を推進するプロジェクトとかチームで仕事ができるといいなと思っている次第です（そんなチームにしたいなとも思っています）

登録: 投稿 (Atom)

kakakikikekeのブログ