システム開発(アジャイル・スクラム)とか色々

スクラムについてのアウトプットだったり、時々お気に入りのものなど。

RSGT動画同時視聴したりアジャイルの相談したりOSTに参加しました(2021/06/17)

はじめに

RSGT動画同時視聴したりアジャイルの相談したりOSTに参加しました。 ほぼ1テーマで、あとはアリの動画見たり、SFOのはなしとかおすすめの動画の話とかしてました。 (12時以降の話は濃いので現在進行系で飲み込んでいる)

自分が思ったこととかも雑多に書いているので正確性はご容赦ください。

思考力やその他若手に足りてないスキルを向上させるためには

元々のテーマはこんな感じだったのですが、発展して色々話していました。 主に印象に残ったこととかをメモ。

ふりかえりのはなし

色々なツールや手法がありますが、それだけでフォースを働かせるほどのものは少ないみたいな話をしていました。 ふりかえりの目的意識みたいなものは大事、だけどガチガチにやると固くなっちゃうとか。

関係性が出来上がってない状態でやろう!が先行しちゃうとありますよね。 場作りから日頃の関係性構築が大事なんだろうなと。

最近色々なふりかえり手法をやっていて、同じようなものもあるけどものによってやりやすさが違う。 人によって言葉の刺さりが違うっていうのはとても腹落ちしました。

あとはふりかえりを楽しくやるためのゆとり大事だなーとか。 だまって書く時間も良いかもだけど喋りながらこんなことあったねーってやり方もいいかもとか。

ふりかえりとかのファシリテーションで形容詞で問うといいっていう学び。 早速明日からやってみよう。

他の人に対する期待

他の人にこうあってほしいみたいなのが最近多く、自分は頑固なんだなーと反省することがある。

頭ごなしに言われてもなんだよってなるので、偉大なチームとか良い教材を見せるってのはとても良い。 期待を下げれば伸びしろしかないっていう名言もあった。

雑談のはなし

雑談苦手〜って人が多かった。 弊チームはデイリーで自分の今の気分とか、プライベートな話とか一言話したりしてるんですが、 上手く話さなきゃ感がないのがよかったのかも。

このあたりはチームで言語化したい。

雑談って楽しそうに話すとみんな興味持ってくれるなと思うし、それを見るのが楽しいって話もあった。 好きなものをとことん拘るってこういう面でもいいなー。

その他

  • Agilergo Dojo知らなかった。どれも気になる。
  • ついSCRUM BOOT CAMP THE BOOKを勧めてしまいますがFisdomいいですね
  • TOC全然知らないので勉強しよ
  • VAKモデルのはなしとか
  • ファシリテーションのはなしめっちゃ腹落ちした

japan-toc-association.org

www.nlp.co.jp

基本に立ち返ってエッセンシャルスクラムを読む(その1)

はじめに

チームが成熟するにつれて、改めてバックログの良い管理方法を模索したり、技術的負債の立ち向かい方を議論している。

基本的なところから立ち返ってみようということで、エッセンシャルスクラムを引っ張り出して読み始めたのでメモです。

最終責任時点(LRM)

この原則はポッペンディークの研究かららしい。

判断しないコスト>判断するコストになったらときに意思決定する。十分な情報が得られるまでは意思決定しない。どちらのコストも指数関数的に見えるのでタイミングは逃さないようにという意味なのかな。

仕掛中の作業(WIP)

あんまり意識してなかったけど、計画駆動型開発はall-before-any型アプローチ。 いっぺんにやると効率が良い思想。

あとは改めて遅延コストのはなしとか。

medium.com

WIPに上限を設けるのを結構前にチームでやり出したけど普通に書いてあった。(ちょっと別の文脈からでしたが)

タイムボックス化

タイムボックス化の恩恵は不必要な完璧主義を避けられること。パーキンソンの法則的なはなし。

できる限り非機能要件はDoDに含める

はい、、という感じ。

よくできたプロダクトバックログ

INVEST以外にもDEEPという概念あり。

技術的負債

大きく3つに分類でき、不可避、ナイーブ、戦略的なものとある。

技術的負債はビジネスと技術的な視点のバランスを取る必要があり、POがいることで合理的に判断できる。PO難易度高い要素の1つ。

ベロシティを使えば負債の金銭的コストわかるとあるが、これはやりたくない。 負債の返済はボーイスカウトルールとバックログの管理とでバランスよくやりたいなあと。

さいごに

本の画像出したかっただけなので、アフィリンクは踏まなくて大丈夫です。

Management3.0のパーソナルマップをやった

はじめに

Management3.0のプラクティスの1つである、パーソナルマップをチームでやってみたので、覚えているうちに気付いたことをメモ。

パーソナルマップとは

自己紹介×マインドマップ×アクティブリスニングをかけ合わせた手法で、簡単に言うといい感じに自己紹介をやるプラクティスです。

気になった方はManagement3.0のトレーニングで詳しく学べるので是非どうぞ。

コンテキスト

  • チームメンバープラスアルファの10人で実施
  • 新しくメンバーが1名入ってきたタイミングだったのでやってみた
  • 1時間枠、1人約4分質問タイム

気付いたこととか

メンバーから出た声や自分で感じたことなど。

関係性が出来上がっている場合、普通に話したいこと話しても良いかも

自分語りすると快楽中枢が刺激されるみたいな話がありますが、人は自分のことを話したいもの。

パーソナルマップやって改めて飲み会的な雑談の場が減ったなあって思ったこともあり、無理に質問形式にしなくても最近あったこととかみんなで話す場にしても良いかも。

無理にやり方に拘るよりはわちゃわちゃやるのが楽しい。

知らない人同士でやる場合

マップになっているので1個の質問だけ掘り下げるよりも広範に聞いたほうが良いのでは精神になったので、具体的に書いたほうが盛り上がる話が振れそう。

人多いと質問し辛いかも、多くても4〜5人くらいがいい?

そのほか

面白いこととかインパクトあるワードセンスが求められる。

あとワイガヤでやってたこともあり、瞬発的な面白さみたいなものが求められたので日頃からトーク力を磨く意志が芽生える。

さいごに

オンライン飲み会に持ち込みたい〜

ソフトウェアテストの教科書―品質を決定づけるテスト工程の基本と実践を読んだ(その2)

はじめに

引き続き、ソフトウェアテストの教科書という書籍を読んだので、気になったところメモです。

daimyo-blog.hatenablog.com

組み合わせテスト

因子と水準

例えば以下の要素があったとして、列見出しのテスト対象の機能名や設定項目を因子、因子が持つ選択肢や設定値などが水準となります。

ブラウザの種類 画面サイズ OS
chrome FullHD Windows
safari - Mac

2因子間網羅

なぜ2因子間網羅で十分なのか、出典をきちんと把握してなかったのでメモメモ。

D.Richard Kuhn氏の研究かららしい。

https://www.researchgate.net/publication/3188430_Software_Fault_Interactions_and_Implications_for_Software_Testingwww.researchgate.net

組み合わせテストを全部やるとケース数が膨大になるので、バグの発見数と組み合わせの数のバランスを考えて2因子間を網羅できれば良いのではという考え方ですね。

ペアワイズ法(オールペア法)

上記の2因子間網羅を達成できる、2因子間の水準の組み合わせを全て作る方法のこと。 作成ツールとしてはPICTやPictMasterが有名。

直交法

あんまり書籍では一言で表す定義がなかったのですが、日科技研さんのサイトによると以下の通り。

直交表とは,任意の2因子(列)について,その水準のすべての組合せが同数回ずつ現れるという性質をもつ実験のための割り付け表です

こちらも調べるとテンプレートが出てくるのでそれを活用するのが早い。

踏み込むと数学的な話になっちゃいそうですが、直交法の方が組み合わせ数が多く、3因子間以上の網羅率が高いとのことで、多因子で検出されるバグはこちらの方が発見できる可能性がある。

回帰テストにおすすめな組み合わせテスト

状況に応じてどのテスト技法を使えばいいのかチャートが用意されていました。 組み合わせテストは回帰テストに良いってところは納得なので実践してみたい。

テストドキュメントの項目

MECEに項目を考えるために、IEEEがテストドキュメント項目ってものを出しているらしい。

ieeexplore.ieee.org

さいごに

テスト工程で作成するドキュメントのサンプルが載ってたり、ゼロイチで何か始めるにも良さげな書籍だと思いました。まだ手に取ってない方は是非。

ソフトウェアテストの教科書―品質を決定づけるテスト工程の基本と実践を読んだ(その1)

はじめに

かなり前からアジャイル開発におけるQAに課題感があり、色々勉強しているところなんですが、あまり体系立って勉強したことがなかったので、ソフトウェアテストの教科書という書籍を読んでみました。

読んでて気になったところをメモがてらまとめていきます。

狩野モデル

かの有名なやつ。
改めて品質の作り込みが効果あるのかきちんと見極めたい。

productmanager55.hatenablog.com

W字モデル

V字モデルの発展型のようなW字モデルというものが存在するらしい。

webrage.jp

思想的には類似開発経験のあるQAが上流から参画してドキュメント等の確認により手戻りをなくす、工程が終わったらV字の相対する工程の計画をする(要求定義だったらシステムテスト計画とか)という進め方をするらしい。

利用しているプロジェクトは今の所聞いたことはないし、上流工程で検出されるバグが下流工程で見つかるようなケースとかまあまああると思うので、そういったときの手戻りがありそう。

カバレッジ基準

カバレッジってC0〜C2とかよく言うけど、正式な名称を知らなかった。
あとよく混乱するのでまとめておく。

名称 略称 一言で説明
ステートメントカバレッジ C0 コードで書かれている命令文を実行
デジジョンカバレッジ(ブランチカバレッジ C1 各IF文のTRUE・FALSEの両パターンを実行(要は判定条件を満たす)
コンディションカバレッジ C2 IF文の全ての条件文のTRUE・FALSEを実行
マルチプルコンディションカバレッジ MCC C2の組み合わせ全パターンを実行

※ IF文の条件部分=条件文、TRUE・FALSEの場合に実行されるブロック文=命令文 としてます

qiita.com

テストフェーズ

以下の順で実施。
最近はそんなことないですが、あんまりテスト設計ってワードに今まで馴染みがなかった。

  • テスト計画
  • テスト設計
  • テストケース作成
  • テスト実施
  • テスト報告

機能観点一覧表

前職のガチガチWFでは作ってたかもしれないドキュメント。 作成にあたりインプットになりそうなもの。

  • ISO/IEC 9126の品質特性
  • Ostrandの4つのビュー
  • Myersの14のシステムテスト・カテゴリ

状態遷移テスト

状態遷移図を用いたテストの総称らしい。

このあたりを読んでいて、 非同期でプログラム組むことが多いのでなんかうまいこと使える手法ないんかなって思った。

状態遷移表を少し改造?して、表の行見出しに状態、列見出しにイベントや動作、交差するところに結果みたいな感じとかどうかな。ファイルダウンロード中に画面切り替えたらAPI打鍵キャンセルするかみたいな。

さいごに

後半読んだらその2を書きます。

実践者のLT大会!~Management 3.0はマネージャーだけのものではない!~に参加しました

はじめに

Management3.0の月1?程度でやっているギャザリングに参加しました。
途中ネット落ちたのであんまり聞けなかったやつもありますが、、まとめました。

LT1:学びを最大化するために

  • 知る→行動する→伝えるのステップ
  • 行動するためには素直であるべき
  • いつの間にか伝えることが億劫になってない?
  • 伝えることを褒めたり質問して成長する機会を与えたり大事

学習の5段階とラーニングピラミッドをおもだした。

note.com

career-ed-lab.mynavi.jp

LT2:フォロワーシップを引き出すためには

  • 社内表彰とか、KudoBox的な感謝を伝える取組みを会社としてやったり
  • 会社という組織のあり方も変える必要がある、個人の成長を支援したり、そのためのM30
  • ゴールデンサークルのはなし、ドーナツにならない

koicpa.com

LT3:ネットワーク型チームのManagement3.0のPrincipleとPractice

  • 新しい人たちがチームにきたというコンテキスト、自己組織的なチームにしたい
  • ネットワークには可塑性や壊れにくさがある
  • 仕事のバウンダリーを明確にすることが重要
  • ゲーミフィケーション、創造性を刺激すれば苦境をハックする(いい言葉)
  • 原理は変わらない、プラクティスはコンテキストによって変わる
  • 自分たちのプラクティスをつくる、名前づけしてみるとM30っぽい笑
  • グッドダブルループ(システム思考あたりからの発想?)

LT4:アジャイルでIKIGAIのあるSDGs

  • 短時間でSDGsものすごい理解
  • バックキャスティング
  • 地球がやばいからやる
  • ビジネスとして重要
  • 社会価値と経済価値を両立して向上させる
  • ソーシャル事業は答えや要件が明確ではない。
  • 正しいことの探索:デザイン思考、正しいやり方の探索:アジャイル
  • 心理的安全性の高さと責任感の高さが学習するチームを作る(チームが機能するとはどういうことか)
  • キャリアの語源は道、キャリアとはIKIGAIを見つけること
  • 計画された偶発性、偶発性の試行回数を増やす

多分このへんの話、めちゃめちゃおもしろかった。

mainichi.doda.jp

LT5:ムービングモチベーターズ

  • AMO理論、モチベーションは生産性を挙げるのに重要な変数
  • MMめっちゃ使っている、実践例は参考になる
  • 内発外発的動機づけ(動因と誘引)
  • 有能性・関係性・自律性の欲求が大事

最後のは諸説ありそうなので引用元が気になった。

LT6:ふりかえり

  • テスト駆動飲み会あるらしい
  • ふりかえりにはレトロスペクティブとリフレクション(内省)がある
  • ふりかえりカンファレンスでの学び
  • ふりかえりはシステマチックにやるだけではなく、話聞いてもらうとか納得感とか色々な効能
  • お茶にしませんか

LT7:LEAN CHANGE MANAGEMENTをちょっと紹介

  • 小手先では解決できない課題ってある、それは組織的な問題だったりとか、、
  • 脳は確実性を大事にする
  • 変化に対応するために自分たちも変わらないといけない、でも変わるって難しい
  • そこでLEAN CHANGE MANAGEMENT(日本語の本出るらしい)
  • INSIGHTS:現在の状態を理解する、左記をやるためにWATERCOOLERとか色々なプラクティスがあるらしい
  • OPTION:やってみることを列挙する、オプションのコストとか価値とかリスクを考えてみる
  • EXPERIMENT:実際に試してみる、準備・導入・レビューする、オプションを実験して検証
  • CHANGE CANVASとかある
  • 多くの変化を起こさないとかひとつずつ実行評価するとかが大事なこと

最後に

あとでもう少しゆっくりふりかえります。 表現とか微妙に異なるかも、、なにか意図せぬところあったらご指摘ください。

色々な発見がありました!ありがとうございました〜

アジャイル開発でのメトリクスについて考える

はじめに

大規模のSIだと必ず出てくるメトリック、 現場とはまったく無縁の企画部門から求められる評価指標、組織で働いていると一度は悩むことがあるのではないでしょうか。

最初に断っておきますが、見る人のコンテキストによっては当たり前じゃんくらいの可能性が高いので、期待値低で見ていただけたらと思います。

今回の内容はアジャイルチームを支える会さんの勉強会に出たときの気付きをベースに作成したものです。これはまた別途まとめられたらいいなあ。

なんでメトリックが必要なんだっけ?

なにかを定期的にモニタリングする、これが脳死で目的化されてしまうケースがあるかもしれませんが、よく考えてみるとチームなりプロダクトをより良くするため、現場の自分達が自ずと欲するもの。

最近バグが多いとかなればカバレッジ見たり、なんかオーバーヘッドが多いなと感じたらリリースサイクルを見たりとか、チームやプロダクトを良くしていくための評価指標は定期的にウォッチすべきだし、本来メトリックって目に見えないものを自分達のために見える化させる、そういうもの。

近視眼的なTryがふりかえりで出がちだったりするけど、突き詰めて考えるとこういうことを改善したい!、だったらこういった指標でモニタリングしたいよねっていうチーム作りを目指したい。

上司が求める指標ってなに?

上司が評価指標を求める、結局それは安心が欲しいだけじゃないですか? そんな人はこう一蹴するか、こちらからプル型のまめな報告。スクラムだったらレビューの場に呼ぶのが早い。

面倒くさい人はこれで排除できるとして、いやいや投資の判断基準とかあるわって言われたらそれはプロダクトのビジネス価値やKPIを置けばいいし、このあたりのメトリクスこうあるべきのコンテキストが色々な人と共有できていれば上手くいく気がしてきた。

さいごに

ベロシティをKPIにすべきと報告書に記載するようなコンサルはこの世から滅びればいいなあ。(フィクションです)