アジャイルチームカンファレンスに行ってきたメモ #atbc
今週の日曜にアジャイルチームカンファレンスに参加してきたのでそのメモをUPります。箇条書きです。
ハッシュタグは#atbc
アジャイルとチームビルディング(Esther Derby)
- チームを良くする話
- コラボレーションをチームにお願いするときは以前のプロジェクトで何があったか聞く
- 理解していないことを質問する
- スモールステップでFB
- あなたはどのように働きたいですか？
- When you work on your projects outside of work, how do you work? Give me an example.
- ユーザーストーリーを使って要求者に返答しているか？
- 要求を1日や2日で解決できるサイズにしているか？
- 要求を小さくしなければFBを得られない
- イテラティブ＆インクリメンタル
- プロジェクトが最適な状態でないとき、何をしなければならないか？
- 例えばプロダクトオーナー不在の時など
- 開発者の仕事はコードを書くこと、ではない
- テスターの仕事はテストをすること、ではない
- フィーチャーを仕上げよう
- Adaptable(状況に応じてやり方を変える)
- Willing to Work Outside Their Expertise
- 自分の領域の外側をやってみる
- いつものやり方と違ったやり方をやったことがありますか？
- 叡智(wisdom)の下に知識(knowledge)があり、情報(Information)の下にデータ(data)がある
アジャイルとチームビルディング(Esther Derby)
- チームに潜むトラップの話
- チームをチームと定義したからってチームになるわけじゃない！
- 4本足＋尻尾の犬を「5本足の犬だ！」といって定義できない
- チームの要求
- メンバーが入れ替わらないこと(安定)
- 5人〜9人ぐらいであること
- 共通の歴史認識があること
- 他責にしあうチームはチームとして成立しない
- メンバーが入れ替わらないこと(安定)
- 情報の共有
- プロジェクトのコアのメンバーに責任を共有すること
- チームメンバーが情報の取捨選択を行うようにしていきましょう
- リーダーが支配する状態は良くない
- リーダーが不在の状態も良くない
- 一人ひとりがリーダーシップを発揮するとよい
- 衝突がない故に健全な関係と言えるのかな？もしかしたらみんな無関心かもしれない
- だからといって衝突しまくるのも良くない
- 衝突が起こったときに誘導を行えることが大切である
- 伝えるべき情報を明確にしなければならない
- よく使う言葉の辞書を共有する
- 問題を人と結びつけてはいけない
- 個人の価値観、スタイルを熟知していないということは問題である
- 計画することが好きな人がいる
- 情報をオープンにすることが好きな人がいる
- 衝突が起こって放置しておくと固定観念がチーム内に芽生えてしまい非生産的である
- チームにアイデアが1つしかないのであればそのチームは問題である
- 逆に沢山アイデアがありすぎると選べなくなってしまう
- with holding information
- 情報を自分の中に閉じ込めてしまう
- 自分の置かれている状態を他者に共有しよう
- pattern blindness
- Ignoring the role of TRUST
- チームは選ぶことができる。リデザインできる。チームのカルチャーもそうだ
アジャイルインフラストラクチャ(角氏)
プロジェクトファシリテーションの原則(平鍋健児氏+松本潤ニ氏)
- タスクを見える化することで他人の負荷がわかる
- アナログでタスクの状態を変更するとモチベーションが高い
- バーンダウンチャートで進捗の見える化
- Iterationでやる
- 1週間分やる
- あんどん
- 失敗と成功を見える化する
- A4ホワイトボード
- UMLに色付けする
- KY(危険予知)MTG
- にこにこカレンダー
- 問題と人間を分離する
- 面談の時、ヒアリングの時は斜めに座ろう
- 問題を書きだしてみんなでそれを見よう
- じゃんけんで故意にあいこににすると親近感が生まれる、らしい
感想
ちょうどこれから新しいプロジェクトがスタートするのでこのカンファレンスで学習したことを実践していく。非常に有意義なカンファレンスを企画してくれた方々に感謝しています。
