前日日付変わるギリギリまで渋谷で飲んでいたので午前中はぐったりしてるんじゃないかと心配でしたが、仕事内容もそこまで無かったので良かったです。
ボランティアスタッフとしてやった事としては
- ロビーでの会場案内
- 部屋の片付け
- タイムキーパー
#以下アフィリエイト用の広告です
-->
色々とAndroidやArduinoで物作りをした雑記/勉強会のメモ等を公開
プロセッサー | インテル Core i7-6500U プロセッサー (2.50GHz, 4MB) |
初期導入OS | Windows 10 Home 64bit |
導入OS言語 | Windows 10 Home 64bit - 日本語版 |
ディスプレイ | 14.0型WQHD液晶 (2560x1440 IPS) |
メモリー | 8GB LPDDR3 1866MHz (オンボード) |
グラフィックス | インテル HD グラフィックス 520 |
キーボード | 英語キーボード (バックライト付) |
指紋センサー | 内蔵指紋センサー |
内蔵 カメラ | カメラ(HD 720p対応)あり 、マイクロフォンあり |
セキュリティーチップ | TPMあり |
ハード・ディスク・ドライブ | 256GB ソリッドステートドライブ SATA (OPAL対応) |
ポインティングデバイス | ThinkPadクリックパッド |
バッテリー | 4セル リチウムイオンバッテリー (52Wh) |
電源アダプター | 65W スリムACアダプター |
ワイヤレス | インテル Tri-Band Wireless-AC 18260(2x2、WiGigおよびvPro対応) + Bluetooth 4.1 |
WiGig Selection | 対応 |
WiGig Dock | WiGig ドック |
Onelink+ アダプター | HDMI-VGA変換アダプター |
標準保証 | 1年間 引き取り修理 |
産地:メキシコ 特徴:ダークモルト、ホップのバランスのとれた風味と繊細な香りを持つミュンヘンスタイルビール(ダークラガー)。メキシコで第1位、アメリカの輸入ビール市場で第2位のダークビールブランドで、クリーミーな泡と明るい黒褐色の液体が特徴。特別な食事や特別な瞬間を演出するのに最適なビール。
産地:ベトナム 特徴:キレが良く、スッキリ爽やかな味わいは日本人の味覚にあったビールです。昨今のベトナムブームによるベトナムレストランの急増で、国内でも躍進しています。サイゴン社はベトナム最大手のビールメーカーで、製法技術はフランスからの影響を受けています。
産地:イギリス 特徴:フラーズが誇るプレミアムストロングエール。深い琥珀色で優しい苦味と穏やかなホップの風味に芳醇な麦芽の味わいを持ち、甘いオレンジオイル、トーストしたパンを思い起こさせ、甘味と苦味がこの濃厚なビールにバランス与えます。
産地:日本 静岡県: 特徴:産直団体(株)野菜くらぶのトレーサビリティーのしっかりしたレタスをふんだんに使い世界でも珍しい飲み物を仕上げました。食事に合い、フルーティーで爽やかな仕上がりが楽しめます♪
本物に徹底してこだわりました!だから、原材料も麦芽・ホップ・レタスのみ。 しっかりと酵母が効いた深い味わいでありながら、フィニッシュにレタスの爽やかさが駆け抜けます。 食前酒でも食中酒としても、楽しく豊かな時間を提供します。 野菜くらぶのレタスは、適地適作、産地リレー、契約栽培契約販売を基本に、群馬・静岡・青森・岡山の産地と技術を共有し、全国をリレーすることで一年通して安定的に出荷しています。 “VEGEALE LETTUCE”でも、“野菜くらぶブランド”のフレッシュなレタスを使用しています。
産地:ドイツ 特徴:50%以上の小麦を使用し、瓶詰め後も瓶の中で二次発酵します。白く濁ったやや濃い黄白色にクリーミーな泡立ち。バナナ、クローブ、パンの香りがあります。レモンのような柑橘系のさわやかな酸味とやさしい酵母の甘味とのバランスが素晴らしいビールです。
産地:チェコ 特徴:チェコの最高級ホップ、モルト、地下300mの良質の水により造られたバドバービールは、700年の伝統を誇ります。麦やホップが主張しつつも調和の取れた味わいで、後にバドワイザーのモデルともなった純粋ビールです。
オープンソース・フリーソフトウェアの統計解析向けのプログラミング言語及びその開発実行環境である。
アジャイルジャパンのイベントが合ったので行ってきた。
その際のメモ。
13:00~15:00
今回は春先にあるアジャイルジャパンのプレイベント
アジャイルジャパンは2016/5/31を予定
http://www.scrumguides.org/download.html
→Japaneseを選ぶ
今回は情報が少ないXPベースで話をする
以下のアジャイルプラクティスを最初に取り入れた手法
4+1の価値を実現するプラクティス
コミュニケーション、フィードバック、シンプリシティ、勇気+リスペクト
http://guide.agilealliance.org/subway.html
アジャイルプラクティスの用語集
なんとなくの見方
これで停車駅を決める⇒今回使うプラクティスみたいなのを決めると分かりやすそう
scrumではスプリントと言う
1週間から3ヶ月(3ヶ月は長すぎると思う)
要件分析から実装・テストまですべての開発を行う
イテレーションの終わりにはリリースできる動くなにかを用意する
ストーリーリスト(プロダクトバックログ)
アジャイルで最低限使われるプラクティスは上記の3つ
ウォーターフォール
ウォーターフォールできっちりできる事であればアジャイルよりも絶対に効率がよい
アジャイルは少しずつ進んでは会議でチェックする
WFと違ってすべて継続的
「アジャイルな計画と見積もり作り」
なんのためにやるのか??
ソフトウェア開発で一番重要なのはコミュニケーション
よりシンプル、コストのかからないものを選ぶ
アクションを起こすための勇気/勇気を持てる仕組み
なぜ価値が4+1なのか?
「事例聞きたい」病
↓ 対処療法で事例を聞かせると・・・
「でもうちの会社では」病
“あなたとつくるアジャイル”
15:10~15:40
グリー株式会社 Quality Assurance部
西脇春名氏 @haruna_nishi
昔はビックバンテストやってた
リリースサイクルの中で各サイクルの ストーリー
に対するテスト。システムテストや受け入れテストに近いフェーズなので単体テストとかではない。
ビジネス的な価値のあるまとまりは?
デメリット
自動化は?
探索的テストは誰がやってるのか?
15:50~16:20
yahoo株式会社 パーソナルカンパニー メール本部
川鯉光起氏
問題
- 発言が出ない
- 改善案が出なくて改善ができないのでふりかえりをやめようとか言い出す
- KPTが出ないとふりかえりができない
対策
- 大切なのは相手の環境や対場を理解すること。
- 批判や提案は後回し
チームを観察して、チームが困っているであろうことを探しだす
- チームに響く内容の問題を提案する方がよい
世の中一般のやり方を積極的にシェアしていく
結果
ふりかえりの時間に例示をして話すハードルを下げた
チームにTryを提案するハードルを下げる
問題が大量に出るようになってしまい、ふりかえりの時間が非常に長くなった
原因
問題が大量
それぞれに改善案を考えるので時間がかかる
対策
問題と改善案を同時に考えるのを辞める
みんなで問題の優先順位をつける
結果
チームが費用対効果の高い問題から解決するようになった
問題
毎回同じような問題が起きる
原因
根本的な解決をしないで表面的な問題のみを解決してる
同じことを繰り返す
対策
問題の深堀
どうして起きたのか?
問題の整理
カテゴリ分け
抽象化
結果
チームで根本的な原因を見つけられるようになった
問題
根本的な原因がチーム外にある
偉い人がきめたこと
原因
なにもできないと思ってる
対策
ボトルネックをスコープの内にする提案
無理だと思うことの対策を考える提案
結果
チームが問題解決を考える前向きなマインドになった
相手の立場を理解する
うまくいかないコンテキスト探しは大変
事前に仕入れて解決案をストックしておく
注目した観察点
毎スプリント計画通りに終わらない
例示をあげてハードルを下げるの具体例
スクラムマスターがガリガリと改善をしてくモチベーション
ふりかえりで工夫したことはなにかあるか?
16:30~17:00
SBS株式会社
小林信氏
資料公開予定
よいものを作り上げたい
それを体現できるのがアジャイル
標準化チームがプロセスをつくって開発チームが使う
策定のためにステップを踏んだ
定義したプロセスで開発実施
スクラムマスターとして参加
失敗した
自己組織化
コントロールの分散化
変化する環境へ継続的な対応
サーバント型のチーム
リーダー メンバーが自発的に働けるようにサポートする
メンバー やりたい気持ちで行動する
言われる前に行動する
工夫しようとする
アジャイル開発をするにはチームのメンバーを長期的かつ継続的な教育が不可欠
アジャイル開発者は幅広いスキルが必要
野望を持った旗振り役が必要
どうしてそれが必要なのか考える
助けてくれたら「ありがとう」を伝えよう
取り入れたプラクティス
デイリーミーティング
ふりかえり
プランニングポーカー
デイリーミーティング
アイスブレイク
ふりかえり
実施タイミング:各工程の1本目が終わったとき
プランニングポーカー
WFだとリスク高い
「利用者にとって価値のあるシステムを作り上げる」という原理原則を意識する
アジャイルソフトウェア開発の12の原則
リーン7つの原則
メンターを作る
ホスピタリティ理論
TOC(制約理論)
SECIモデル
標準化は必要なのか?
大きな枠組みとしての標準化は必要だけども、標準外のことをやることも大切
標準化はレール。アジャイルは復車線。
ユーザー企業の期待値は何?
ユーザー企業の期待値はアジャイル開発という言葉が一人歩きしてたので統一見解を作りたかった
チームへの意識付け
意識付けが手抜きになっていたので失敗した
言われたからやっている感がぬぐえなかった
タスクの定義を網羅的にする方法
オブジェクト指向の考え方ができないと網羅的にあげるのは無理
タスク分割するには基礎的な技術力が必要
テスト自動化
17:10~17:40
DADベースのアジャイル開発プロセスの構築と実践
株式会社東芝 インダストリアルICTソリューション社
IoTテクノロジーセンター プロセス・品質技術開発部
石井裕志氏
リリースサイクルの向上が求められる
モノを作ってみないと良し悪しがわからないプロダクトが増えている
組織として守らなければならない文化・制度
品質保証の体系
事業戦略
既存資産の活用
複雑な利害関係
それぞれの関係者を説得するのが難しい
CSM(認定スクラムマスター)
プロセス構築
試行プロジェクトへの教育
プロジェクトでの試行
ふりかえり
背景
組み込み製品のSWとそれを用いたシステム製品
現在クラウドや携帯端末との連携が求められる
課題
初期段階で要求を固めるのが難しい
設計フェーズ以降の着手が遅れがち
協力会社からアジャイル開発が求められた
目的
設計、コーディングの着手遅れを減らす
テストに時間をかける
既存の品質保証体系とアジャイルのプロセスが合わないことが判明
DAT(Disciplined Agile Delivery)
アジャイルをスケールアップするためのフレームワーク
3つのフェーズを定義
初期計画のフェーズが充実
方向付け
プロジェクトがアジャイルで実施できるのか判断
アジャイルでやる目的があるか?
前提条件を満たすか?
プロジェクト特性をもとにしたアジャイル開発適合性評価手法
プロジェクトの計画立案
構築
移行
従来の品質保証体系
プロセスの検討WGの開催
隔週で半年
参加者:設計、品質保証、支援メンバ(アジャイル)
参加者:プロジェクト関係者全員
目的:アジャイル・スクラムベースの仕事の進め方を理解する
体験演習5時間
アンケート結果
ふりかえりに期待
課題の早期発見
スプリントレビューで適宜確認できる
工数が増えないか心配
変更要求の押し付け
追加要求の増加
捲土重来
成果物の受け入れ可否判断
マイルストーンレビュー
プロセスがちゃんと回っているかのレビュー
デモ・単体テストの結果確認
ふりかえり結果の共有
結構時間がかかった
3~4時間かかった
仕様確認とかもやってた
プロダクトバックログを適宜調整
上長がでてくる
バックログ、バージョンアップチャートを使った
進捗確認がやりやすかった
プロダクトバックログの粒度が難しい
出張等で連絡がつかないとスケジュールが遅れる
進捗確認に効果があると感じた
要求の管理はしやすいが、初期の粒度に基準がほしい
スプリント期間中の品質可視化ができた
教育フェーズをきちんと利用できるかが勝負になりそう
17:45~18:00