regional tokyo gathering 2017 bui minh truong
TRANSCRIPT
オフショアにおけるアジャイル開発の壁を乗り越えるBUI MINH TRUONG, PMP, CSP, CSM
http://www.buzinga.com.au/wp-content/uploads/2016/05/communication-barriers.png
オフショア、ニアショアーまたベンダーを使用し、アウトソーシングする方がいらっしゃいますか？
自己紹介名前 : Bui Minh Truong （ブイ・ミン・チュオン）メール : [email protected], [email protected]アジャイルベトナムのボードメンバー : [email protected]経験 : ソフトウェア開発：１０年
Played different roles: Developer, Technical Leader, Team Leader, Project Manager, Scrum Master, PMO, Agile Coach.資格 : PMP, CSP, CSM現在：オルトプラス・ベトナム
アジェンダ1. 成功例のケーススタディ2. オフショア開発でアジャイル・スクラムを実施する場合に陥りがちな問題3. オフショア開発で、スクラムを使って成功する方法
事例１：通信会社様の案件• 開発体制：６ペア（ベトナム側）、 PO: お客様の担当者• アジャイル・フレームワーク：スクラム• 業務内容：クラウド・サービス• 工程：設計・開発・テスト• 開発期間：１２ヶ月以上（今まだ続いている）• 最初の課題：開発チームがアジャイルでの開発経験を持っていない。
事例１：通信会社様の案件• チーム
http://cloudblog.kddi.com/agile-2/2244/
事例１：通信会社様の案件• 工夫点：チケットは日本語とベトナム語で記載
http://cloudblog.kddi.com/agile-2/2244/
事例１：通信会社様の案件• 工夫点：設計は UML で実施、 Sonar-Qube でソースレビュー
http://cloudblog.kddi.com/agile-2/2244/
事例１：通信会社様の案件• 工夫点：ペアプログラミング、
事例１：通信会社様の案件
成功ポイント：お客様が我々をパートナーとして考えていただいた。
事例２：オンライン・コースのシステム• 開発体制：９名、 PO: お客様• 開発工数： 40 人月（ 9 人のチーム）• 開発モジュール：フロント・エンドとバックエンド（設計・開発・テス
ト）• 業務内容：イーラニング・システム• 最初の課題：お客様がアジャイルでの開発経験を持っていない。
事例２：オンライン・コースのシステム
https://learnweb.jp/
事例２：オンライン・コースのシステムプロジェクトの進み方
フロント・エンド納品 バックエンド・エンド納品
http://www.intellicacorp.com/intellicacorp/assets/SoftwareDevPics/SprintCycle.png
事例２：オンライン・コースのシステム• チャレンジ：プロダクト・オナー・プロキシをテスターにした。
お客様
＋
事例１：通信会社様の案件
成功ポイント：お客様が我々を信じていただいたから。
オフショア開発の問題点• 作りたいものに対して、作ってくれない 橋を作ってくれない？
https://gregcfuzion.files.wordpress.com/2013/10/grumpy-customer.png
はい、箸をどうぞ！
オフショア開発の問題点• ソースコードが汚い、品質が低い
https://media.licdn.com/mpr/mpr/p/4/005/07d/023/14c48cd.jpg
オフショア開発の問題点• コミュニケーション・コストが非常にかかる
http://4.bp.blogspot.com/-zYxbFb1WdRU/VIYit-8knsI/AAAAAAAAA5o/PkJZlqHJ_sU/s1600/Define%2Bbarriers%2Bto%2Beffective%2Bcommunication%2Band%2Bessentials%2Bof%2Beffective%C2%A0communication.PNG
・言語の壁・回線のスピード・曖昧な言葉。。。
ミスアンダースタンディング• ポジティブなこと• アジャイルで開発して安くなる
• ネガティブなこと• アジャイルは好きなことでやり放題• アジャイルは品質担保できない• アジャイルは文書があまりないから、メンテーが大変
プロジェクト成功のポイント• マインドセット• 検収条件の明確化• 自動化
マインド・セット：アジャイルマニフェストプロセスやツールよりも個人と対話を、
包括的なドキュメントよりも動くソフトウェアを、契約交渉よりも顧客との協調を、
計画に従うことよりも変化への対応を、価値とする。すなわち、左記のことがらに価値があることを認めながらも、私たちは右記のことがらにより価値をおく。
個人と対話：アナログでのタスク管理
マインド・セット：変化への対応
どのようなきっかけで人間が自分を変えて、新しい道を選択しますか？
マインド・セット：変化への対応• プロセス・やり方• 英語でのコミュニケーション• 文化の違い（日本ベンダーと比べる）
マインド・セット： アジャイル宣言の背後にある原則
http://agilemanifesto.org/iso/ja/principles.html
スクラムに関する質問• なぜスクラムはタイムボックスがあると思いますか？• なぜチームが 5 人から 9 人までだと思いますか？
マインド・セット：コア・バリュー
Core Value
s
コミットメント
フォカス
オプーン尊重
カーレッジ
検収条件の明確化
http://cloudblog.kddi.com/agile-2/2244/
自動化チェックアウト・ビルド 単体テストコード解析
テスト環境へのデプロイ結合テスト
Source code Management Build Tools
Gitpush
Poll SCM
Robot Framework CD
Server
Task managemen
t
Notification
実際のコード解析結果
ロボット・フレームワーク
http://seleniummaster.com/sitecontent/images/robotframeworkride/SeleniumRobotFramework_demotest_SiteElements_use.PNG
ロボット・フレームワーク
https://redstack.files.wordpress.com/2013/09/robot-report.png
コミュニケーションの問題に対して• ストレートな言葉• できるだけ映像で説明。目的から説明• 質問の種類：イェス・ノーのタイプ
コミュニケーションの問題に対して日本語がわからないスタッフのためのリアルタイム翻訳プラグインを開発
課題• 品質管理• リスク管理• 。。。
アジャイル開発におけるプロジェクト・マネージメント
http://christianvisionalliance.org/wp-content/uploads/2016/06/thank-you-from-christian-vision-alliance.jpg