QLOOKアクセス解析
ホーム

ソフトウェア開発に関するメモ・考察。 最近もっぱら管理系の仕事ばかりですが、私生活では開発を楽しんでます。

スポンサーサイト

上記の広告は1ヶ月以上更新のないブログに表示されています。
新しい記事を書く事で広告が消せます。

「アジャイル開発とスクラム」を読んだので、感想とメモ

「アジャイル開発とスクラム」を読んだので、感想とメモ。

スクラム開発の概要説明、導入の事例紹介とインタビューいった内容で、
・アジャイル開発ってなんだろう?
・スクラムって何だろう?
・スクラムを導入したいけどメリットは?
といった事に興味のある方にはオススメの書籍です。

特に事例紹介とインタビューについては
生々しいというか、導入時にどの現場でも発生しそうな内容が
書かれており、参考になるとともに導入時の
具体的な事例を話す際にも役立ちそうです。

以下、各章ごとの感想とメモ。

●アジャイル開発とは何か?
 アジャイル開発というとウォータフォールと比較して
 イテレーションの開発、生産性向上といった面で語られる事も
 多いように感じていますが、そこは余り重要ではなく、
 協調とコミュニケーション、顧客と開発チームのゴールの共有、
 柔軟な計画変更の考え方といった価値観が重要。

●なぜ、アジャイルなのか?
 「ゴールを共有した開発」というのが興味深い。
 従来の請負開発では、保険的な要素が強くなってしまい、
 開発側は顧客のゴールを目指すのではなく、「仕様通りに作る」ということを
 目指してしまう。これは開発のモチベーションも上がらないし、
 結果的に顧客も欲しい機能が手に入れれない事が多くなってしまう。
 実際にやるのが難しいのは、この実践には信頼関係が必要なこと。
 
●スクラムとは何か?
 未来を予見するのではなく、反復による経験で適応していく考え方は
 とてもしっくりくる。
 
 スクラムで定義されている役割は3つ。
 ・プロダクトオーナー
 ・開発チーム
 ・スクラムマスター
 とてもシンプルでこれが重要。
 テスターやデザイナー、プログラマーといった役割はない。
 この考えもいいなぁと思います。
 役割を細かくした場合のデメリットは、顧客の価値といったゴールを共有しにくくなること。

 デイリースクラム、レトロスペクティブあたりはすぐにでも導入出来る。
 実際には同じような事をやっている場合も多いと思うけど
 このように言葉の定義があると、色々と都合が良い。

●アジャイル開発の活動(プラクティス)
 プランニングポーカーは面白いですね。
 これは1つのやり方ですが、複数人による見積りはとても重要だと思う。
 三回繰り返しても決まらない場合は平均値、または最大値というのが面白い。
 現場では最小値を求められがち、担当者は最小値で見積もりがちですが、
 現実は最大値を超えることの方が多いように感じるので
 最大値を選択するというのは良い考えと思います。

 どちらの見積もりを選択しても結果、かかる工数は同じ・・と思われがちですが、
 最小工数で見積もって実際に工数が増えた場合、
 当然遅延が発生するので、本来は不要であった報告作業や、
 調整作業といった本来は不要な作業が多発し工数が余分に必要になる。

 デイリースクラムは良いですね。
 早速現場で導入したいと思います。
 簡単に見えて奥が深そうなので、少し自分の勉強と
 導入にあたってみんなが目的を共有出来る資料を作成する。

 タスクかんばんはRedmineでやろうと思ってましたが、
 やはりアナログのホワイトボードなどでの運用が早そう。
 一目でわかりやすい、細かな作業もサッと貼れる、楽しそう。
 XP祭り関西2013で紹介されていた、
 自家製の発砲スチロールのかんばんは粘着力もあって、
 持ち運びも自由で良さそうだったので、あれでいこうかな。

 ペアプログラミングはやってみたいプラクティスの1つ。
 ただ現場では費用対効果について説明しにくく導入しずらい。
 やはりコストが2倍にならない?という壁がある。
 今の現場では難しい実装がないのも1つの要因。

●リクルートの事例紹介
 「できるって言いましたよね」に代表される、発注者⇔受注者の考えから
  発生する様々な弊害。これは本当に痛感してます。
 発注者は途中の仕様変更は追加工数がかかるので、あらかじめ色々な仕様を詰め込もうとする。
 結果、不要な機能に不要な工数が使われる。
 受注者は工数不足に陥らないために、責任を問われないために
 バッファを積む、不要なドキュメントをたくさんつくる。
 
 アジャイルの価値観である「協調」によって上記の問題は解決する。
 簡単そうに見えますが、お互いの信頼がないと出来ないことなので
 実践するのは難しい。従来の発注者も今までよりも間違いなく大変になる。
 でも実践すれば欲しい機能が、少ない工数で手に入り、お互い充実感がでるはず。

 総工数をベースラインにしたスコープ管理は
 発注者には勇気のいることだが、結果的にはメリットの方が多いと思う。
 これをやるには進捗、残作業の可視化を平行にやって
 発注者と受注者でしっかり情報共有することが前提。

 MTGで持ち帰りはNG。80%ならOK回答とする。
 正し後でお互いに責めない。
 というのは良いアイデア。これが実践出来たというのはスゴいと感心。

●楽天の事例紹介
 XPの導入にあたって費用対効果が見えない・・という議論に対して、
 まずは一部導入で効果を測定、結果が良ければ広げていくというアプローチはいいですね。

 楽天のようにサービスを提供する会社と、SIerの仕事のアプローチが違う。
 サービスを提供する会社は、リリースしてからが本番。
 こういった開発はアジャイルが特に有効だと思う。
 メンバーが元気になっていった・・というのは面白いです。
 「魔の横展開」(笑。どこにもあるんですね〜

●富士通の事例紹介
 自由な座席の導入は興味深いです。
 ペアプログラミングの導入と自由な座席をやると
 コミュニケーションは促進されそう。検討してみよう。
 チームリーだの定期的なローテーションもいいかもしれない。

スポンサーサイト

Google Chart Toolでグラフ作成

redminのプラグイン作成中で、グラフ描画に何を使おうかと
思っていたのですが、Google Chart Toolが良さそうなので採用。
●グラフの種類が豊富で奇麗。
●特にインストール不要でシンプル。
●日本語も問題なし。
●AJAXを使ってインタラクティブな図が作成可能
弱点はgoogleとの通信が必要。googleの事なのでいつ仕様が変わるか不明。

こんなグラフが作成出来ます。
Charts Gallery – Google Chart Tools – Google Code

こっちはGoogle Chart Toolのデバッグが出来るのですが、
様々なサンプルがあり、参考になります。かなり奇麗で色々なグラフが作成出来ます。
Google Code Playground

リクエストパラメータで指定するやり方、JSを使って作成するやり方がありますが
JSを使ったやり方の簡単なメモ。

railsで使う場合、普通にやるとViewで色々コードを埋め込んで
JSにパラメータを渡さないと行けなくなるので、今回は gon というgemを使います。
このgemを使うとシンプルにControllerからデータを受け渡す事が可能になります。

gonについて詳しくは以下を参照。
https://github.com/gazay/gon
https://github.com/gazay/gon/wiki

まずはgemのインストール。
Gemfileに以下を追加。
gem 'gon', '3.0.5'
インストール実行。
$ bundle


app/views/layouts/application.html.erbにインクルードの追加。
<head>
<title>some title</title>
<%= include_gon %>
<!-- include your action js code -->

これで gon が使えるようになります。

簡単なグラフの作成。コントローラ側でデータを準備。
格納する変数名は任意でOK。
gon.graph_dataにサンプルデータを格納。
# データテーブルの作成
gon.graph_data = [
['年度', '売上', '費用'],
['2004', 1000, 400],
['2005', 1170, 460],
['2006', 660, 1120],
['2007', 1030, 2000]
]
表示するerbファイルに以下を記載。
<!-- AJAX API のロード -->
<script type="text/javascript" src="https://www.google.com/jsapi"></script>
<script type="text/javascript">

// Visualization API と折れ線グラフ用のパッケージのロード
google.load("visualization", "1", {packages:["corechart"]});

// Google Visualization API ロード時のコールバック関数の設定
google.setOnLoadCallback(drawChart);

// グラフ作成用のコールバック関数
function drawChart() {

// データテーブルの作成
var data = google.visualization.arrayToDataTable(gon.graph_data)

// グラフのオプションを設定
var options = {
title: '会社業績'
};

// LineChart のオブジェクトの作成
var chart = new google.visualization.LineChart(document.getElementById('chart_div'));
// データテーブルとオプションを渡して、グラフを描画
chart.draw(data, options);

}
</script>


これだけで奇麗がグラフが出力されます。

XP関西祭り2013の感想/メモ

2013/4/27(土) に行われた「XP関西祭り2013」に行ってきました。

発表資料については以下のページにリンクが貼ってます。
http://www.xpjug.jp/cgi-bin/main_wiki/wiki.cgi?page=XP%BA%D7%A4%EA%B4%D8%C0%BE2013

皆さんとてもエネルギッシュでパワーをもらいました。

▼基調講演
アダプタプルウォータフォールという考え方は現実的で良いなぁと思います。
私の現場も同じような形で導入していってます。
アジャイル開発にする・・・というよりも今の現場をより良くするために
といった形で導入していくのがやりやすいと思っています。

複数契約、チケットの取捨選択でスコープを管理する。
と行った点は非常に重要な考え方と思います。
QCDに加えて、スコープという考え方は当たり前といえば当たり前なのですが
実際の現場ではそうなっていないことも多いかと思います。
そういった意味でこういった定義付けは大切だと思います。
私も今の現場では総工数をベースラインにスコープ調整をしています。

▼京アジャ 春の特別出張編
エレベータピッチ。実際にやってみると
理解していなかったり、考えていなかったすることが良く分かりました。
やっぱりインップットだけでは駄目ですね。素振りが大切です。
現場でも色々とアウトプットする場というのを作ろうかと思いました。

▼プラクティスって何だろう?
印象的だったのは皆さんがスクラムを導入した経緯が
「これしかなかった」「追いつめられて」といった言葉が多かったこと。
現在の開発に対するスピードの要求を感じたのと、
どうすれば良いか?と考えると「スクラム」にたどり着いたというのが興味深いです。

チームで合宿。カレー作るというのは良いアイデア。

実践→振り返り→改善
の大切さを改めて実感。
誰のための改善?をちゃんと考えよう。
デイリースクラムでは、スクラムマスターは寝るぐらいの気持ちで(笑
いくつか書籍紹介がありました。以下の2つは読んでないので買おう。

▼LT
皆さんエネルギッシュで笑い満載でした。
・とりあえず個人でやってみる。というは有りですね。
 まず成果を出して信頼を得るというやり方は大事です。
・trelloというツールは知らなかったのですが便利そうです。
 Webサービスなので今の現場では導入出来ないですが、
 環境が許す場合で、軽いプロジェクトならぜひ導入したいです。

Sublime Text 2で拡張子別にタブサイズを変更する

Sublime Text 2で拡張子別にタブサイズを変更する方法。

デフォルトではタブサイズは4なのですが、Rubyの世界ではタブサイズは2が標準。
Rubyモードはあるのですがタブサイズはデフォルトなので変更する。

・タブサイズを変更したい対象の拡張子のファイルを開いておく。
 例えば今回はRubyのタブサイズを変更したいので xxx.rb のファイルを開いておく

・メニューから
 Sublime Text 2 -> Preferences -> Settings - more -> Syntax Specific - User
 を選択する。
 すると今の拡張子ファイルのための設定ファイルが開く。
 Rubyだと「Ruby.sublime-settings」

・以下のように入力
{
"tab_size": 2,
"translate_tabs_to_spaces": true
}




gitとGitHubの使い方

git/GitHubの使い方。
ここでは既にローカルで作成済みのファイルを
GitHubで管理するところまでを説明。

GitHubのアカウント、リポジトリは
あらかじめ作成済みのものとします。

▼ユーザ名とe-mailの設定
git config --global user.name "Your UserName"
git config --global user.email "Your Email"

▼ログ出力などをカラーにして見やすくする。
git config --global color.ui auto

▼ローカルのフォルダをgitの管理対象にする。
対象のフォルダに移動して以下のコマンドを実行。
ここでは ~/gitwork を管理対象としてます。
管理しないファイルを指定する場合は、管理対象フォルダの
トップフォルダに「.gitignore」を作成して指定します。

cd ~/gitwork
git init

ちなみに、既にリポジトリで管理されているファイルを
変更したい場合は、以下のコマンドで取得します。
git close <リポジトリ名>

▼作業フォルダ配下のファイルをバージョン管理に追加。
git add .

▼バージョン管理対象野ファイルをリポジトリにコミット。
git commit -m "Your first Commit"

▼SSHの作成とGitHubへの登録。
以下のGitHubのヘルプを参照。
https://help.github.com/articles/generating-ssh-keys

▼GitHubにPushする。
git remote add origin https://github.com/①/②
git push origin master
# ①はあなたのGitHubのID.
# ②はリボジジトリ名 + ".git"
# 例:https://github.com/mygithubid/myrepo.git

▼参考URL
分散バージョン管理システムGitの使い方入門 - SourceForge.JP Magazine : オープンソースの話題満載

サルでもわかるGit入門 〜バージョン管理を使いこなそう〜 | どこでもプロジェクト管理バックログ

gitとgithubの使い方、を思い出す。 - KJ blog

github 超入門 - glasses factory

Gitを使いこなすための20のコマンド - SourceForge.JP Magazine : オープンソースの話題満載

上記広告は1ヶ月以上更新のないブログに表示されています。新しい記事を書くことで広告を消せます。