アジャイル開発の「安定感」を高める、「スプリントゼロ」
「HRMOSタレントマネジメント」目標・評価チームでは日々スクラムを実践し、アジャイル開発を目指しています。 私たちのチームは開発の中で、以下の課題に直面しました。 🚨 開発者にとって、他の開発者やプロジェクトへのサポートや連携に入りづらい 仕様や見積ドキュメントが標準化されておらず、開発案件の進め方や知識が属人化していました。 これにより、開発者がどう他の開発者やプロジェクトへのサポートや連携に入って良いのかわかりづらくなっていました。 🚨 PO・EMにとって、開発の計画が立てづらい サポートへの入りづらさによるコミュニケーション工数の増加、および仕様見落としによる手戻り工数の増加により、ベロシティ見積の信頼性が低下していました。 これにより、プロダクトオーナー（以下、PO）・エンジニアリングマネージャー（以下、EM）は不測の事態に備えたバッファ工数込みで見積らざるを得ず、開発の計画
見積もりでアジャイル開発の予測可能性を高める - 「キャリトレ」での実践例
アジャイル開発を採用しているチームにおいても、ビジネスの要求によっては「一定規模のフィーチャーセット」を「特定の時期にリリースする」ことを、達成しなければなりません。 そういった要求に対し、挑戦する20代の転職サイト「 キャリトレ 」 の開発チームがどのように立ち向かっているのか、リファインメントの実践例を通してご紹介します。 「キャリトレ」は2022年12月21日をもってサービス終了しました。 予測可能性を求めるビジネスの要求とは 分かりやすい例でいうと「業界の繁忙期に合わせて新機能をリリースしたい」などです。 また、BtoBビジネスの場合、開発チームがフィーチャーセットとリリース時期をある程度担保することができれば、 企業のお客様に対し事前のご案内がしやすくなります。 そのことは、リリース直後からその機能を最大限ご活用していただける、という大きなメリットがあります。 事業部一体となって
スクラムチームを支える心理学 - 死亡前死因分析
この記事では、私たちのチームがスプリントゴールの達成とコード品質の低下を防ぐために行っているプラクティス、「死亡前死因分析」について紹介します。 スクラムチームと計画 変化への適応が強調されるスクラムですが、だからと言って事前の計画をないがしろにすることはできません。 私たちのチームが大切にしているキーワードのひとつに、“Measure twice, cut once” （二度測って、一度で切る）があります。もともとは優れた大工の仕事を指す言葉で、注意深く計画し一度で仕事を済ませる、手戻りのない状況を表現する言い回しです。 私たちにとっても、“Measure twice, cut once” の大切さは大工にとってのそれと変わりません。手戻りはデリバリの速度だけでなく、実装の素直さやコードの端的さにも悪い影響を与えるためです。ソフトウェアのバグが一番現れやすい箇所は「苦労と試行錯誤の末にな
クラウド時代のアイデンティティ・プロビジョニングプロトコル SCIM を人事 DB に採用した話 - BizReach Tech Blog
人事データベース HRMOS Coreチームの doyaaaaaken です。 最近は Kotlin でサーバサイドをメインに開発しています。 なお、本日が最終出社日です！（新手の退職エントリですｗ） 今回、日本語・英語どちらの資料も少ない、珍しい規格を用いた開発を行ったので、それについて簡単に紹介します。 何をやったか 弊社では、現在 HRMOS Core と呼ばれる人事データベースを開発しています。 そこで、Slack や Salesforce などメジャーなクラウドサービスも採用している SCIM（System for Cross-domain Identity Managementの略） と呼ばれる規格に準拠した、汎用的なユーザ情報連携のための API 群を開発しました。 開発した背景 HRMOS Core は人事データベースであるという特性上、社員情報を一元管理し、入社、退社、人
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
