43
enPiT 学生5人と社会人1人のアジャイル開発 java Küche Agile Japan 2017 サテライト 琉球大学大学院 理工学研究科 比嘉 明周

Java kuche agile japan 2017

Embed Size (px)

Citation preview

enPiT学生5人と社会人1人のアジャイル開発

java Küche Agile Japan 2017 サテライト

琉球大学大学院 理工学研究科 比嘉 明周

enPiT BizAppに参加してきました。

優秀賞をいただきました!

琉大enPiT活動はWebへhttps://ie.u-ryukyu.ac.jp/enpit/

今日は、1.開発で大変だったこと2.学んだことを話します。

enPiTって何?

enPiTとは?❏ 文部科学省主催

❏ 「情報技術人材育成のための実践教育ネットワーク形成事業」

❏ ビジネスアプリケーション分野、クラウドコンピューティング分野

❏ セキュリティ分野、組み込みシステム分野

❏ 比嘉はビジネスアプリケーション分野(BizApp)に参加

❏ 内容

❏ 筑波大学、公立はこだて未来大学、産業技術大学院大学を拠点

❏ 学生・社会人を募集

❏ 問題解決するためにwebアプリなど、ビジネスアプリケーションを作り、発表

❏ 琉球大学は産技大のカリキュラムに参加

❏ 琉球大学の学生5人が参加

❏ アジャイル開発 + スクラム開発

スケジュール

フレームワーク開発特論Rubyコンポーネントの作り方

自由開発期間講義外なので、開発しなくてもよい

6~9月

ビジネスアプリケーション特別演習チームで開発、毎週土曜日に開発したプロダクトをデモ

アジャイル開発手法特論アジャイルの考え方、スクラムで迅速なチーム開発を練習

コラボレイティブ開発特論Rubyフレームワークで開発

1 ~ 2月

10 ~ 12月

9月

3月 enPiT全体シンポジウム全拠点のチームが集まって、プロダクトを発表

開発を振り返ります

はじまり

❏ 琉球大学の院生5人でチーム結成

❏ リーンキャンバスの作成

❏ エレベーターピッチを作る

❏ パッケージデザインを作る

この辺は割愛します。

スクラム開発

❏ 1週間の計画を立てる❏ スプリントバックログ作成

❏ コアタイムの設置❏ チームで集まって作業する

❏ 作業❏ 個人でも集団でも作業してよい

❏ 1日15分のデイリースクラム

❏ スプリントレビュー❏ 毎週土曜日にデモ

❏ demo or die

❏ 次に何をするか考えてバックログを更新する

❏ スプリントレトロスペクティブ❏ 良かったこと、悪かったことを振り返る

❏ チームのための改善計画をつくる

スプリント1

スプリント2

スプリント3

・・・

・・・

1スプリント=1週間

※他では1スプリント=3日の場合もあるらしい

1スプリントの流れ

土 月

デモ、レビュー振り返り(KPT)

バックログ見直しタスク決め

火 水 木 金

個人&チーム作業

進捗確認話し合い

開発

開発フロー

品質管理

レビュー

コミュニケーション(Slack)チャット

デイリースクラム

エラー監視

コミュニケーション(GitHub)バージョン管理

issue

技術wiki

コミュニケーション(Trello)タスク管理

週次振り返り

苦労と学び

苦労と学び❏ 個人間でのアジャイル開発、スクラムについての理解度の差

❏ 技術的な知識不足

❏ demo or die、タイムボックス、徹底した時間管理、徹夜作業、体調管理

❏ 話し合いの意思決定が遅い、意見を言いあわない、脱線

❏ タスクの粒度、タスクの重み見積もり、開発速度

❏ バックログの引き受け条件、ユーザーストーリーの組み立て

❏ デイリースクラム、スプリントレビューによるリスク回避と外部レビューによる方向修正、

GitHubレビューの観点、レビュータイミング、コアタイム

❏ スプリントレトロスペクティブのKPT分析と達成条件

❏ 外部要因による開発遅れ、研究、課題、学会等

❏ 文化の違い、コミュニケーションの方法、ワークフローの違い

❏ タスクの属人化、他人にはできない分野

❏ 引き継ぎ、途中参加

苦労と学び❏ 個人間でのアジャイル開発、スクラムについての理解度の差

❏ 技術的な知識不足

❏ demo or die、タイムボックス、徹底した時間管理、徹夜作業、体調管理

❏ 話し合いの意思決定が遅い、意見を言いあわない、脱線

❏ タスクの粒度、タスクの重み見積もり、開発速度

❏ バックログの引き受け条件、ユーザーストーリーの組み立て

❏ デイリースクラム、スプリントレビューによるリスク回避と外部レビューによる方向修正、

GitHubレビューの観点、レビュータイミング、コアタイム

❏ スプリントレトロスペクティブのKPT分析と達成条件

❏ 外部要因による開発遅れ、研究、課題、学会等

❏ 文化の違い、コミュニケーションの方法、ワークフローの違い

❏ タスクの属人化、他人にはできない分野

❏ 引き継ぎ、途中参加

タスクの粒度、重み見積もり開発速度

バックログからタスクを作っていく

すごそうなタスク

すごそうなタスク

ナビゲーションフッタはどんな感じに作るんだろう?絵はないの?

もうちょっとタスク分割できそうな気がする。

このタスクと他のタスクは依存関係があるか?

依存関係はなかった。

そのチームにおいてタスク実行待ちを作らない = 良いタスク粒度

このタスクは、そのチームにとって良い粒度

バックログの重み見積もり

バックログの重み見積もり

(3)はバックログの重み

重み=難易度1, 2, 3, 5, 8, 13易 <- -> 難

見積もりはよくハズれる

見積もりはその時期での相対的な技術挑戦度

最初の見積もりは実験どんどん正確になっていく

開発速度

バックログの重みは3+8で11

このスプリントの開発速度(ベロシティ)は11

ベロシティは次回のスプリントの見積もりに使える

ベロシティはスプリントを重ねるごとに加速していく

文化の違いコミュニケーションの方法

ワークフローの違い

人は皆、それぞれ違っている

プログラミングするとき、インデントは何文字ですか?

コードレビューの時、GitHubにどんな風にコメントを送っていますか?

チームメンバーの作業時間を理解していますか?

チームメンバーはいつでも開発状況が見れますか?

週明けコアタイムにチームで情報共有をするとストレスが減る

ちょっとしたコミュニケーションで開発が早く回る

個人間でのアジャイル開発スクラム開発の理解度の差

宣言や用語の理解

宣言を覚えているか?

バックログとタスクの違いがわかるか?

バックログはどんな順にこなせば良いか?

振り返りは何のためにやるのか?

(誤解を恐れずにいうと)あまり理解していなくてもアジャイルっぽくなる失敗して成功しよう