前回は1スプリントの計画と日々の活動について書きました。
今回はプロダクトが完成した後の活動について書いていきます。

日々の活動を経て「リリース判断可能なプロダクト」が完成しました。
そのプロダクトが「リリース可能なプロダクト」かどうかを検証・判断するための会議を「スプリントレビュー」といいます。

■スプリントレビュー
この会議は、開発チームの成果物をプロダクトオーナーが確認する場です。
・開発チームが開発したものをPOにデモをする
・POはリリース可能かどうかを判断する

以前プロダクトバックログを作成する段階で、その要求に対する完了の定義を決めておきました。
今回のスプリント計画で開発することにしたプロダクトバックログ毎に、その完了の定義を満たしているのかどうか、デモを通じて検証します。

その結果を見てPOがリリース可能かどうかの最終判断を下します。
ここでNGになったプロダクトバックログについては、その残作業を次のスプリントに持ち越します。

NGになったプロダクトバックログを、スプリントの期間を延長して完了させるのではなく、次のスプリントに持ち越す点に注意して下さい。

これは開発チームの「ベロシティ」を測るためです。

■ベロシティ
スクラムのルールとして各スプリントの長さは均一にしなければなりません。
また、以前プロダクトバックログの見積もりを行う際にプランニングポーカーの手法を説明しました。
この手法で見積もりが行われた場合、それぞれのプロダクトバックログには、それを実現する場合にどれくらいの工数が掛かりそうかがポイントで表現されています。

つまり、1スプリントで消化できたプロダクトバックログのポイントの総計が、今の開発チームが1スプリントで消化できるポイントであり、今の開発チームの実力を表します。それを「ベロシティ」と呼びます。
このベロシティを測り、また比較するために、スプリントは均一でなければならないのです。

今の開発チームのベロシティがわかれば、今後のスプリント計画も立てやすくなり、プロジェクトの見通しも立ってきます。
開発チームとしてはベロシティ、つまりチームの実力を測る、その目安にもなります。

スクラムでは開発チームがベロシティを向上させるべく、次のスプリントへ向けて今回のスプリントをふりかえるための会議体が用意されており、それを「スプリントレトロスペクティブ」といいます。

■スプリントレトロスペクティブ（ふりかえり会）
次のスプリントを今回のスプリントよりも良くするためのアクションを決める
・プロセスやツールなどの観点で今回のスプリントを検査する
・うまく行ったこと、今後改善すべき点を整理する
・今後のアクションプランを作る

ふりかえりを行って次のスプリントに活かす、つまりPDCAサイクルを回すことで開発チームの業務を改善する仕組みが、スクラムには用意されています。

以上、ここまでが1スプリントで行う活動になります。

まとめますと、
・スプリント計画ミーティング
・デイリースクラムを実施しながらの日々の開発
・スプリントレビュー
・スプリントレトロスペクティブ
を1スプリント内で実施し、それを繰り返すことでプロダクトを作成していき、最終的にはそのプロダクトをリリースする、という流れになります。

今回を含め、今まで５回に渡りスクラム研修のまとめということで書かせていただきました。本連載は今回で終了です。

アジャイル開発におけるマネジメント手法の一つである「スクラム」。
その基本的なルールについては、本連載を書く中で改めて整理できたと感じています。今後はスクラムを実践しながら、更に学んでいければと思っています。

最後に、スクラムをはじめようと思っている方に向けて、スクラムの実践の手引とも言える、すばらしい書籍をご紹介させていただきます。
SCRUM BOOT CAMP THE BOOK

最後まで読んでいただき、ありがとうございました。

LDAPのユーザー情報はLDIFというファイル形式でのインポート・エクスポートが
一般的で、CSVでのインポート・エクスポートはあまりサポートされていません。
LDIFファイルでは、ユーザーの情報を複数行で記述します。
例を挙げれば、

dn: cn=user1,ou=users,dc=icoc,dc=co,dc=jp
cn: user1
objectClass: organizationalRole
objectClass: simpleSecurityObject
userPassword: user1Password

dn: cn=user2,ou=users,dc=icoc,dc=co,dc=jp
cn: user2
objectClass: organizationalRole
objectClass: simpleSecurityObject
userPassword: user2Password

このような形式になります。
dnからuserPasswordまでで1ユーザーの情報となっています。

ある程度の数のユーザーを一括で登録したい場合、
CSVは横方向に情報を持つため、EXCELなどを使用することで
複数ユーザーに対して、一括での追加、編集が容易に行えますが、
LDIFでは縦方向に情報を持つので、複数ユーザーに対しての一括追加、編集は
CSVに比べると、容易には行えません。

これを考慮すると、
データの作成はEXCELなどを用いて作成し、
インポートを行う時にLDIFに変換できれば、
大量のユーザーを扱う際でも手間ではなくなります。

そこでCSVをLDIFに変換するツールは無いものかと探したところ、
csv2ldif2というスクリプトがありました。
http://sourceforge.net/projects/csv2ldif2/

上記URLから「csv2ldif2-1.1.tar.gz」をダウンロードします。
圧縮形式はtar.gzなので、Windowsで使用する場合、
解凍ソフトを用いる必要があります。

ファイル解凍後、フォルダが作成されますので任意の位置に配置します。
コマンドラインからは以下の様に実行します。

cd フォルダの配置場所
perl csv2ldif2.pl "ou=users,dc=icoc,dc=co,dc=jp" < tsuika.csv > tsuika.ldif


perlで書かれているため、perlを宣言後、スクリプトファイルを指定します。
ファイル名の後、LDAP上でユーザーを配置するディレクトリを指定します。
上記の”ou=users,dc=icoc,dc=ac,dc=jp”という箇所です。
その後、変換元のファイル名を記述します。
このとき必ず<>で囲む必要が有ります。
最後に変換後のファイル名を記述し、実行すると、変換が行われます。

例えば、以下の内容を持つCSVを変換すると、

cn,objectClass,objectClass,userPassword
user1,organizationalRole,simpleSecurityObject,user1Password


dn: cn=user1,ou=users,dc=icoc,dc=co,dc=jp
cn: user1
objectClass: organizationalRole
objectClass: simpleSecurityObject
userPassword: user1Password


このように変換されます。
変換したLDIFをLDAPへインポートすれば、ユーザーの一括登録が行えます。

iPhone6sおよびiPhone6s Plusが、9月25日に発売されました。
今回のシリーズでは、本体色にローズゴールドが追加され、Apple Watchで採用されている感圧センサーがiPhoneにも採用されたそうです。

私もiPhoneユーザーで、現在はiPhone5sを使っています。
ちょうど今年の12月で2年になるので、そのタイミングで6sに機種変更したいなぁと数ヶ月前から思っていました。

なのですが。。。

さかのぼること8月下旬。
その日は朝から社内清掃の日で、いつものように自分の胸ポケットにiPhoneを入れて掃除をしていました。
掃除が終わって、塵ごみが落ちてたので拾おうと屈んだ時に事件は起きました。

iPhoneが玄関のタイル部分に落下。

その結果・・・

ご覧のとおりの結果に。

ショックと言うよりは、これはどうすればいいのだろうと思ったのが率直な感想でした。

結果、AppleCareに未加入だったため、予約が取りづらいアップルストアのGenius Barの予約をなんとか取り、後日福岡天神のアップルストアに持ち込んで、本体画面のみの交換で約1万6千円の出費をすることになりました。
（交換作業は約1時間半ほど。その間に友人と天神をぶらついてました）

機種変更前の出費としては非常に痛かったわけですが、割れたまま使用するのにも不便ですし、仕方ないのかなと今では思っています。

今まで何度落としても割れなかったのは奇跡だったのかもしれませんが、当たり所が悪いとすぐに割れてしまうみたいです。
実際私の友人でも割ったことがある人をちらほらと聞きます。

iPhoneに限らず、スマホをご使用の方は、落下にはくれぐれもお気をつけください。