My style agile
0 likes850 views
Agile Japan 2012 資料 常識の壁を打ち破れ ～大手ベンダーにおける新たな取り組みへの挑戦事例～ NECST 高橋さんの資料。
My style agile
- 2. 1.チーム紹介 病院内電子カルテシステムの構築 開発規模 ３．２Ｍステップ 開発要員 国内１０名 海外１０名 １年１回の大規模バージョンアップ実施 2005年にVersion 1を出荷 2007年 (Version 3) 以降、Agile的プロセスに 移行
- 3. 2.チーム内でのテーマ 理論や形式にとらわれず、チームの身丈 にあったプロセス改善を行うこと。 無理のない全員参加型のプロジェクトを 維持すること。 メンバーのモチベーションを高めること。 分散開発の制約を解消するための工夫を 行うこと。
- 4. 3.従来の手法 完全なウォータフォール 機能設計 詳細設計 製造 テスト 総合テスト 出荷パッケージング 現場リリース
- 5. 4.従来の問題 各フェーズを完了しなければ、次のフェーズに 進めない。 上工程での誤りで、大きな巻き戻し工数が発生 する。 各フェーズでの必要リソースに差があり、パッ ケージ開発としての要員計画が難しい。 エンドユーザを含め、目に見えるものが存在し ない時期には、本質的問題が抽出されにくい。 機能間の問題が、最終工程まで潜在化しやすい。 問題の混入発生時期が把握できない。
- 6. 5.問題に対する改善 作業項目を分解し、小さな単位で管理 する。 設計～出荷パッケージングの工程を４ 週間の繰り返し作業として定義する。 日本・海外の連携を工夫し、稼働率 100%となるように調整する。 毎朝１時間のミーティングを行う 男女比50%のチーム構成とする。
- 7. 6.具体的な決定 月 火 水 木 金 土 日 サイクル１：企画・設計（日本） 第一週 サイクル１：製造・テスト（海外） 第二週 サイクル１：製造・テスト（海外） 大規模延長 (12) 第三週 サイクル２：企画・設計（日本） サイクル１：出荷パッケージング・総合テスト（日本） サイクル１出荷 第四週 サイクル２：製造・テスト（海外） サイクル２：製造・テスト（海外） 第五週 サイクル３：企画・設計（日本） サイクル２：出荷パッケージング・総合テスト（日本） サイクル２出荷 第六週 サイクル３：製造・テスト（海外）
- 8. 7.作業項目の分解 要求項目/不具合項目の管理 親項目としてRPQ/SDR-xxxxxとして定義する。 (ex. RPQ-12345) 子項目としてRPQ/SDR-xxxxx-nnとして分解す る。(ex. RPQ-12345-01) 分解の単位は出荷して機能できる範囲とする。 それぞれの作業計画に割り当てる。
- 9. 8.バージョン番号の原則 全ての改変物にはバージョン番号を付与 プログラムバイナリ データベーススキーマ マスターデータ 実行時設定ファイル パッケージング一式インストーラ ドキュメント
- 10. 9.バージョン番号体系 Rev. a.b.c.d patch e new f a: メインNo. 年度初めに決定するバージョン番号 b: マイナーNo. 年度計画として決定するバージョン番号 c: サイクルNo. ２週間サイクルにて付与されるバージョン番号 d: メンテナンスNo. 過去の出荷に対する修正対処バージョン e: パッチNo. 緊急対応が必要な場合のパッチバージョン f: 内部NG No. 出荷前テストにおけるNG発生後対処バージョン この番号は、外部公開を行わない。 （例） Ｒ７．０．３．１ Ｒ７．０系列サイクル３の出荷物に不具合対応が１度含まれた インストーラセット。 Ｒ７．０．３．１patch１new２ Ｒ７．０．３．１インストーラセットに対する緊急パッチ１ 出荷前テストにおいてＮＧが２回発生し、それに対処したパッチセット。
- 11. 10. 1時間の朝会 前日の作業内容の確認 海外からの受け入れ状況確認 問題に対する対処の確認、是正 企画フェーズにおける機能内容、分類のレ ビュー RPQ（要求項目）/ SDR（不具合）仕様レビュー 新技術適用時の技術共有教育 総合テスト時の問題報告、対処決定 プチ勉強会講師を持ち回りで実施 隠し事をしない事 批判をしない事
- 12. 11.男女比５０％？？？ 本当かどうかわかりません。 実績としてチームコミュニケーションに貢献 男性の特性 女性の前では、プライド高い いい格好がしたい 挑戦的な考えが強い いざっというときの大黒柱 女性の特性 丁寧、几帳面である 計画に対する進捗管理が得意 安全、堅実な考えが強い 家族を維持する母性本能がある 何の根拠もありませんが、この男女比のおかげ で、進 捗・品質の良くないときでも、前向きで楽しい意味のある 朝会が実施できております。 ( ^_^;;)
- 13. 12.実績の収集 下記状況より、プロジェクトの実績を収集 要求項目(RPQ/SDR)を分解し、製造工程への指示 項目数 製造・テスト項目の完了数・遅延数 出荷前テストにおけるＮＧ数 インストーラレベル 製造レベル 設計レベル 原因の分析 工数の問題（能力の問題も含まれる） 機能分割の問題（粒度の問題） テスト項目の問題（想定漏れ仕様の問題） コミュニケーションの問題
- 14. 13.効果(1) 巻き戻し工数が大幅に削減された。 小さな巻き戻しは発生します。 進捗状況の把握が容易になった。 ２週間程度の作業に関する進捗度合いとなる ため、誤差が小さくなります。 構成管理が明確になった。 構成の静止点が２週間単位で管理されるため、 問題発生時のバックトレースも容易です。
- 15. 13.効果(2) 縦割り構造が排除され知識共有が容易になった。 朝会効果が大きいです。 私たちのチームでは、全員が全担当 （コンセプトです。実際に全員が全部を担当している わけではありません。） エンドユーザへの導入が容易になった。 ２週間単位に、本稼働できる環境がUpdateされます。 ユーザとしても、任意のバージョンを任意のタイミン グでチョイスすることができます。 暇な時期が無くなります。 （良いのか、悪いのか） 常にルーチン的な作業の反復作業になっています。
- 16. 14.コストは如何に。。。 コスト削減という効果は見えません。 （本音です） ただ、爆弾級のトラブルも発生しません。 リソース配備に関する待機工数も発生し ません。 総じてみると、コスト面に関する工夫を 行う部分は存在すると思います。 今後ブラッシュアップしなくてはいけま せん。
- 17. 15.最後に 2007年よりプロジェクト要員、状況のレベル にあわせ、開発プロセスの工夫と試行錯誤で 完成させたスタイルです。 グループ内では、特に Agileであるという意 識を与えずに作業を継続しております。 皆様におかれましても、柔軟な考え方でプロ セス改善を進められてはいかがでしょうか。 本日は、ご清聴ありがとうございました。