restofwaterimpのぎじゅつMemo

SIerに所属。企画から運用まで幅広くやってます。C#中心に書いてます。

スクラム始めました-スプリント1実施【#2】

前回の続き

スクラムを始めました【#1】 - restofwaterimpのぎじゅつMemo

 

 

まずはやってみようということでスタート。試行錯誤の中、徐々に良くなればいいやという思いを持ち、進めることに。

■どういうものを作るのか

 ・とあるビジネスアプリを完全に作り変える

 ・要求は漠然としており、モックやプロトを見せながら要件を決めていく。

 ・また、データが散在・ダブルネーミングや一定のルールが無いデータを一元化するため、クレンジングをしながらデータ移行業務あり

 ・.netで作成

  (詳しくかけないので、いろいろ伏せています)

 

まずは、計画を作成・・・

 

■チームメンバーの構成

 全員で5名のチーム

 ・スクラムマスター

 ・プロダクトオーナー

  本来はプロダクトオーナーは企画チームやお客様に実践してもらうのが良く、プロダクトの優先順位をつけてもらうのがベスト。

  しかし、今回はお客様も掛け持ちで色々持っているため、兼務で私が実施。

  

  他メンバーは

   設計・移行担当・・・1名

   開発メンバー ・・・3名(今回使う言語、アプリの技術を知る人1名

                他言語の経験者1名。

                .netもJavaなどWeb経験無し 1名)

  マルチスキルというわけでもなく、特定要素に偏ったメンバー構成でスタート。

  また、チームメンバーはそれぞれ異なる会社のパートナー社員

  

 

■スプリントの期間の設定

書籍などを参考に、スプリント期間は2週間で実践し、まずは自分たちの力量を知ることをスプリント1に決定

 

■ゴール定義

 スプリント完了後にどこまでできているかを決定。

 今回は

  ・モックアップ完了

  ・α版・・・単体テストまで完了

  ・リリース版・・・本番に載せられる状態

 と意味付けた。実施しながら定義は見直すことも可能とした。

 

■コミュニケーション

 ・朝会を実施。基本30分とし、超えそうな場合は別で時間を確保。

 ・別時間で打ち合わせをする場合は、

  「打ち合わせの目的」

  「会議のゴール」

  を明確にして、打ち合わせを行う。

 ・極力、メンバーの一部だけしか情報を知らないということをなくすため、共有するときはチームメンバー全員で実施

 

ツール

 ・お客様環境の都合上、初期はツールを入れられず。

  Excelを基本に管理を実施。

  下記のサイトなどを参考に、バックログを書き、バーンダウンチャートを作成

河西 高明 BLOG: ガントチャートを捨てろ(2) バーンダウンチャートを使う

   → 資料作るのに時間がかかり、細かな管理がおろそかに。

     また、Excelだと基本、メンバーは入力をしない。。。のがわかりました。

 

■プロダクトログの作成

 ・進める前にお客様の企画部隊と話はしていたので、おおよそのユーザーストーリーを作成し、必要と思われるフィーチャーを箇条書きにした。

 ・優先度が高く、すでに具体的に書けそうなものは具体的に記載し、優先度が低そうでまだまだ要望が固まっていないものはあらく記載。

 ・細かく出来る部分は極力、1つのプロダクトログに対し、1,2日で終る範囲まで切り分けた。

 ・粒度の記載のばらつき具合には目をつぶり、まずは作るべき機能を書きだした。

 ・環境面で作成しなければならないことは「環境改善」という名前でグルーピング化

  アプリ基盤の作成などはフィーチャーとは分けてラベル付

 

■タスクの考え方

 ・開発の作業に必要なタスクを形式化。

 ・言葉ジリにこだわらず、チームメンバーの中で「DONE」できそうな内容で、意味が共有できていれば良いという形で記載。

 

■まずは見積もろう!

 作成したプロダクトログの中から、スプリント1で作成する機能を私がピックアップ。

 その機能に対して、メンバーに見積もりをしてもらった。

 ここで有識者が「ざざっと」基準となる機能を見積もり、ほかの機能は相対的に複雑度や規模から見積もりを行おうと思ったが、できそうもないので、ざっくり見積もりに。スプリント1の状況を見て、見積の正しさを検証することに・・・

 ・極力、スクラムマスターが「この工数でいきます」とは言わず、メンバーに工数を話してもらい、「合意」「宣言」という形で言ったことをコミットしてもらう雰囲気にしました。

 

 

■実践開始!

 ・いろいろと問題が・・・。

  スプリント1の振り返り後に記載することに。 

                        (つづく)

 

<追加の参考にした書籍>

 

アジャイルプラクティス 達人プログラマに学ぶ現場開発者の習慣
Venkat Subramaniam Andy Hunt
オーム社
売り上げランキング: 61,478

スクラムを始めました【#1】

スクラムの研修やセミナーを受けたことはないですが、

書籍から得た知識を元にスクラムを導入しようと決意し、明日からスプリント1を

始めることになりました。

何もかも初めての経験なので、忘れないように一定のタイミングで経験したことを文書に起こそうと思ってます。自分向けの振り返りの意味合いが強いので、他の方の参考になるかわかりません。。。 

■なぜスクラムを取り入れようとしたのか

理由1:要求がぼやけているため

基幹系の仕組みではなく、「あると便利なもの」というものを作ることになった(あまり具体的には書けないです)ためです。

現行の仕組みはあるのですが、まあ不満もあり、システム都合でコードの改修もできず。で、新しいのを作り直しましょうとなったのですが、「こういうのがあったらいいな」くらいの感覚でしかユーザから要求が無いので、WF型は無理だなと判断し、アジャイル型開発を取り入れることにしました。

 

理由2:今のチームの力量がわからない

これまでシステム改善や運用保守をチームとしてやっており、WBS書いてガントチャートで見積もってやりくりしていました。ほぼ「この仕組ならこの人」状態になっており属人化しつつある状況でした。

また、今回のチームでやろうとしている言語などの技術スキルがチーム内でバラバラ過ぎ、見積もりの基準が作れなかったのもあります。リーダーが見積もっても当たるはずも無いし、根拠もないので、開発者自身が構築すべきタスクの規模と難易度を見極めて、「自分ならこれくらい」と見積もれる形が良いと思い、スクラムを選びました。

 

■取り入れるにあたっての準備

私自身、「アジャイル」「スクラム」という用語は聞いたことはあったのですが、具体的に語れず・・・の状態でした。そのため、まずは『本から学ぼう」と思い、昔に購入した書籍と新たに購入した書籍でイメージを掴みました。

書籍と、あとはWEBで検索かけまくっていろいろな情報を掛けあわせながら自分自身で言葉などを解釈することに努めてました。

 

インプットに使った書籍・・

 

アジャイルなゲーム開発 スクラムによる柔軟なプロジェクト管理
エッセンシャル スクラム: アジャイル開発に関わるすべての人のための完全攻略ガイド (Object Oriented Selection)
スクラム実践入門 ── 成果を生み出すアジャイルな開発プロセス (WEB+DB PRESS plus)
貝瀬 岳志 原田 勝信 和島 史典 栗林 健太郎 柴田 博志 家永 英治
技術評論社
売り上げランキング: 2,679
アジャイルソフトウェア開発の奥義
ロバート・C・マーチン
ソフトバンククリエイティブ
売り上げランキング: 100,909
(終了)ESD21/JASA共催「TPS/Agile組込システム」セミナー(資料と写真公開) - お知らせhttp://www.scrumguides.org/docs/scrumguide/v1/Scrum-Guide-JA.pdf日本で唯一のアジャイルコーチの江端さんの講演があるということで聞いてきました。むしろ、書籍よりこちらを先に聞いてました。アジャイルスクラムの幻想と間違った解釈を解読してくる良いセミナーでした。資料も上記のサイトに記載されています。
 

 

つづく・・・(予定)

【システム開発】画面検討とユーザインタフェース検討は違う?

SI業界に入り、10年以上経つのだが、今までホストでの開発や、クラサバ系または現行アプリの改修を中心に実施して来ており、あまり画面について深く考えることはありませんでした。

 

私の頭のなかにはビジネスアプリ(Webなどとか関係なく、一企業の中で使うアプリ)は

「無駄をそぎ落として」

「必要最低限の機能で・・・」

「使う側が仕組みを理解して・・・」

 

というのが染みこんでいたのだろうか、「ユーザビリティ」という視点を持っていたようで抜けていることに気づいた。

 

私なりの認識で画面検討というと

「入力」「表示・参照」を「どのような項目で行うか」というのを考え、

モックアップを作成し、ユーザに確認、合意を行う。

というプロセス。

 

しかし、これって、画面のイメージや業務ストーリーはすべてユーザ任せ何だよなと

最近気づきました。

受託案件でも常駐型でも、「使いやすさ」「見やすさ」というのは大いに求められていると思われる。

 

スマホアプリや私用のPCでWEBサイトなどを利用し、登録・参照を行うときの画面の使いやすさ(使いやすさに気づかず、使いやすくなっているのだが・・)に慣れていると新たに企業システムを作ると不都合さのギャップにハマり、使ってもらえないならまだしも、画面イメージでNGを受けるのではないかと。

いくらシステム開発がメインで、WEBデザイナーでないとしても、多少の嗜みを持って、UIを考える時代になっていると実感しています。

 

そこで、今参考にしているサイトは・・・


デザイニング・インターフェース: パターンによる実践的インタラクションデザイン - Jenifer Tidwell - Google ブックス

google booksで一部参照できるので

 


【インタビュー】クックパッドのUIデザイナー:「エンジニアの仕事が0を1にする仕事なら、デザインは1を100にする仕事 」 - THE BRIDGE(ザ・ブリッジ)

・UIってcookpadかなと思ったので、ググった。

 この記事に付いているui-patternでデザインパターンを知る

 


UI/UX JAPAN - UIデザイン・UXデザインのいろいろを発信するブログメディア

・シンプルに、何を伝えたいのかという原則を考えるのに使ってます。

 51のチェックリストに記載の内容を元に画面を複雑にしないように意識しています。

 

他にも優良な情報というのはあると思いますが、今は限られた中で消化中です。

 

画面を考えるときには、言われたとおりに考えるのではなく、

「利用ユーザになりきって、想定される使い方をイメージし、システムの利用動線を

 考えながら画面のラフ案を作る」

ということがユーザ・インタフェース検討になっていくのかと今は思っております。

 

現在進行形で、動いていますので、また経験値を積んだら、

おさらいをしようと思います。

運用って・・・ただこなすだけじゃないだろう!


ITILとは - itSMF Japanオフィシャルサイト

 

ITILのサイトにも書かれているように、

ITサービスに対するユーザと顧客の満足度の向上
サービス可用性の向上、事業の利益と収益の増加
やり直しと損失時間の削減、リソースの管理と利用の改善によるコスト削減
新しい製品やサービスの市場投入までの時間の短縮
意思決定の改善とリスクの最適化

 

ってのが運用担当には求められている。

 

作業手順書に従って、日々、ユーザからの依頼にしたがって、淡々とこなすのは

何か違う気がしています。

 

エンタープライズ・・アプリケーションの保守運用であれば、日々運用に携わりながら、

・システムの特徴

・データの特徴

・発生しやすいこと

などを掴み、システム改善の提案やシステム品質を保つための提案を

先んじてできると感じています。

 

せっかく仕組みを作っても、システムとともに人が劣化させて行ったら元も子もないので、運用は運用でしっかり考えていただきたいものである。

【R】ggplot2のインストール

Rを勉強しようと

 

 

RとRubyによるデータ解析入門
Sau Sheong Chang
オライリージャパン
売り上げランキング: 51,695

 

でRの学習開始をし始めてます。

 

昔にRをインストールしており、バージョン3.1.0で開始。

一個一個やっていたのですが、ggplot2のパッケージインストールをしたところ、

digestが見つからないと。

 

よく見ると

http://cran.ism.ac.jp/bin/macosx/mavericks/contrib/3.1/digest_0.6.6.tgz

を指している。

 

実際にサイトを見ると、0.6.7が置いてある。

下位バージョンのRだと、パッケージは取れない仕組みなのか??はたまた自分がやり方をまだ知っていないからなのか?

 

今はよくわらかないので、ひとまずRを最新の3.1.2にあげたら、0.6.7を指すことができたのでよしとしよう。

まだ課金されていた in AWS

もう、大丈夫だろうと思っていた、AWSが課金されていた。。。

 

何じゃと思ったら、SnapShotが削除されていなかったようである。

 

http://docs.aws.amazon.com/ja_jp/AWSEC2/latest/UserGuide/deregister-ami.html

 

Amiの管理下であったため、SnapShot情報が削除できず残っており、

まあ、1$にも見ていないが、月額で細かく取られていた。

 

スタートアップは便利だが、クロージングが結構面倒なのかもしれない。

 

先日も、食事していた時に聞いた話だが、試しにResionサイトを日本とアメリカでインスタンスを立ち上げ、データ通信のテストを検証していた人がいた。

 

その後、自身ではインスタンスを落としたつもりだったそうだが、

請求で4000$が来たようである。

 

話を伺うと、バックアップ処理が残っており、結構大容量データを検証していたため、データ使用量を取られたそうな。

 

一応、悪意はないことをAmazon Japanにダメ元で確認を取り、本国で対応してもらい、請求されたお金は、返金されるみたいですが・・。

 

便利な分、使う方も気をつけて使わないと、余計な出費になりそうである。

【メモ】ETL系のデータ生成での調査の段取り

本日ハマったので、段取りを残す。

 

1.登場するファイル、データベースの一覧を取得する

2.登場するファイル、データベースのER図(関係図)をまとめる

3.ETLツールを調査し、生成元ファイルと生成先ファイルの関連性を整理する

4.トリガーイベントが隠れていないか・・・確認する

5.ETLツール以外にデータにアタッチしていないか確認する

 

トリガーイベントは基本使わないだろう・・・とう認識があったので、

完全見落としており、ずっと「なんでこのDBのデータが生成されているんだろう?」と

悩んでいた。

ホスト系の開発ですと、トリガーを利用する意識がなく、調査のフレームに入っていなかたのですが、GUI系のシステムならばどうも使っている傾向があるようである。

 

SQLServerでは、このサイトで確認方法を見たので、記述。

リンク先

select tr.name as trigger_name, ta.name as table_name, tr.is_disabled as disabled
from sys.triggers as tr
inner join sys.tables as ta on tr.parent_id = ta.object_id

リンク先のSQLにはdisabledの記述は記載がなかったが、トリガーが無効になっているか否かも調べておいたほうが後々説明する場合、及び自身の仮説を作成するのに利用できます。