CSP-SM受けてみることにした そのxに向かって「ソフトウェアクラフトマンシップの適応」
ここまでのあらすじはここから
ソフトウェアクラフトマンシップってなに？
多分これ
アジャイルマニフェストの何かなのか・・・。
■Not only working software, but also WELL-CRAFTED SOFTWARE
動くだけのソフトウェアだけでなく、よく作られたソフトウェアを
■Not only responding to change, but also STEADILY ADDING VALUE
変化への対応だけでなく、堅実に価値を積み重ねよ
■Not only individuals and interactions, but also A COMMUNITY OF PROFESSIONALS
個人との対話だけでなく、プロフェッショナルで作られたコミュニティを
■Not only customer collaboration, but also PRODUCTIVE PARTNERSHIPS
顧客との協調だけでなく、生産的なパートナーシップを
日本の権威の翻訳記事などを見つけたのでペタッと貼って終わろう・・・。
3.7 最低1つ、どのようにソフトウェアクラフトマンシップの要素を仕事に適応させたか説明せよ
1つという言葉には甘える。全てに対して考えると面白いよねー。
■Not only responding to change, but also STEADILY ADDING VALUE
変化への対応だけでなく堅実に価値を積み重ねよ
変化に対応することが忙しくなる事があります。その時は、まるで変化に対応していることによる充実感があります。
しかし、どこまで価値の追求ができているのかわからない場合があると思います。
検証という名のもとにとにかく変更してみている時
変更をすることで、プロダクト自体の保守性が落ちていく時
細部の調整が多くなりすぎている時
このような時には価値が積み重ねられているのか、継続的に価値を提供でいているのか疑う必要があるのではないでしょうか。
とある経験
あるプロダクトAの共通基盤となるプロダクトBの開発をするチームでスクラムマスターをしていた時の話です。その時のプロダクトオーナーは、プロダクトAとBのプロダクトオーナーを兼任していました。
Aの共通基盤としてBを使用するため、Aの優先順位に合わせてBの機能も合理的に拡張されるとの判断からです。
しかし、Aの開発は遅れ、Bのプロダクトの範囲を超える開発をすることになりました。Bの開発チームのメンバーは単純に開発リソースとしか思われていなかったのです。
さらに、Bという範囲では優先順位が着実に決まってインクリメンタルな開発が進んでいたものの、Aというプロダクトでは優先順位が適切に決まっていませんでした。
さらに言えば、外部リソースとの情報連携がうまくいかない状況でした。
ミーティングのたびの仕様変更や顧客価値の薄い単純な文言修正などが続きました。
Bの開発チームは、従順に変化に対応をします。スプリントのコミットメントも達成していました。
しかし、そこに顧客価値が見出せない変更要求が多すぎました。
変化に対応することで技術的に成長することの難しい要求ばかりでした。
チームは次第にモチベーションが下がっていきました。市場価値も提供できず、スキルアップも見込めない改修をし続けたからです。
価値とは、単純な市場への提供価値だけではありません。
間接的に市場への価値提供につながる事柄も価値です。
チームの成長はその価値の１つです。
この事柄からの学びは、
価値を積み重ねない変更の連続は、チームのパフォーマンスすら落とす
ということでした。
単純な金銭的なリターンだけでなく、さまざまな視点で「価値」を定義し、プロダクト開発を行う必要性の学びです。