開発プロセスをインクリメンタルに改善する - 一休.com Developers Blog
一休.comレストランのエンジニアのkymmtです。 2023年度の下半期、一休.comレストランの開発チームでは開発プロセス改善に取り組みました。改善は小さい単位で徐々に進め、バックログの作りかたやカンバンの運用方法を改善することで、フロー効率の向上、開発ペースの把握、チーム内外からの進捗の見える化ができるようになりました。 この記事では、このようなインクリメンタルな開発プロセス改善の取り組みについて紹介します。 従来の開発プロセス 主に2023年度前半の開発プロセスは次のような形でした1。 プロダクトのリリースに必要なタスクが長いバックログとして存在し、ひたすらタスクを消化 その状況に課題を感じ、区切りを入れるために2週間のスプリントを導入 この時点では、スプリントは2週間ごとに状況を確認するためのもので、目標に対するふりかえりや、次のスプリントの計画を作るためのものとしては活用してい
仕様書の参考例と、こんな内容を仕様書に最低書くといいというお話｜田辺めぐみ
よく、仕様書を書いていなくて、書いてみたいけど、具体的な仕様書がネット上に落ちてなくってこまってるって相談を受けるので 「仕様書の記載内容のイメージ」を作りました！ ※前提として「現在仕様書を書いていない、自社開発のMVP検証前後のフェーズのスタートアップ向け」に書いています。PMが仕様書、エンジニアがDesign Docを書く分担です。 ついでに、システム開発の基礎である「システム開発のV字モデルをベースにした設計書の紹介」も含めてまとめてみましたー！ 大規模開発に使われたり、古くからあるフレームワークなので、スタートアップの方だと、システム開発のV字モデルの概念やそれにあわせた成果物を知らない人が多いけど、「要件定義書」と「設計書」を全てドキュメント化するとどうなるかを理解した上で、「仕様書」として情報を削る方が、考慮漏れ防止やエンジニアがやっている設計内容の理解につながるので、全体を
How to Deal with Difficult People on Software Projects
Software is easy. People are hard.
「ITの開発現場によくいるやっかいな人」の対処法をタイプごとに解説したサイトが登場
ソフトウェアの開発プロジェクトにはさまざまな経歴や役職を持つ人が関与するので、我が強い人や性格に難がある人が問題になることもしばしば発生します。ソフトウェア業界のよもやま話を語るブロガーのニール・グリーン氏が、ソフトウェア開発プロジェクトの中で問題になりがちな人をタイプごとにまとめつつ、それぞれのタイプの特徴と管理職向けの解決策を解説しました。 How to Deal with Difficult People on Software Projects https://www.howtodeal.dev/ 上記のサイトにアクセスしたのが以下。上から「プロダクトマネージャー」「デザイナー」「プロジェクトマネージャー」「開発マネージャー」「開発者」「品質保証(QA)」の6カテゴリに分かれていて、それぞれの役職の中によくいる「問題のある人」のタイプが動物のアイコンで示されています。例えば、「プロ
締め切りが厳しいプロジェクトで、プロジェクト初期にまずやっておきたいこと - $shibayu36->blog;
これまで僕は締切がかなり厳しいプロジェクトを数回経験してきた。その経験から、締切が厳しいという特性を持ったプロジェクトの初期にまずこれだけはやったほうが良いということがいくつか見つかったので、今回はそれらを紹介していこうと思う。 前提となるプロジェクト 今回紹介する方法は、次のような特性を持ったプロジェクトを前提とする。 細かい仕様は決まっていないが、作るものの要件はある程度明確である アジャイルの定義におけるスコープ・コスト・品質・スケジュールの中で、スケジュールを特に優先したい(スケジュールを変えられないなど) 数ヶ月以上のプロジェクトである 短いスパンでリリースしてユーザーの様子を見てその後のプロダクトバックログの優先度を変えるような性質のプロジェクトでは、別のやり方を取る必要があると思う。そこは注意してほしい。 プロジェクト初期にやっておきたいことは何か 上記のようなプロジェクトの
技術的負債の返済プロジェクトが失敗する 11 のワケ - jfluteの日記
ワケ一覧 序の口: フレームワークだけが負債だと思ってる 序二段: ビジネスサイドに理解してもらう努力がない 三段目: 技術で遊び過ぎてしまう 幕下: 太り過ぎアーキテクチャ 十両: 過去に目もくれず、現状だって見ない 前頭: 技術に詳しいだけでアーキテクト 小結: アーキテクトの知識と覚悟が足りない 関脇: スパンが長く、モチベーションが続かない かど番大関: スパンが長く、人の入れ替えでチグハグ 大関: アーキテクチャデザインはどこへ？ 横綱: 実は人間的負債だった 序の口: フレームワークだけが負債だと思ってる みんな、フレームワークが大好き。とはいえ、さすがにみんな、「フレームワークが古いことだけが負債」だなんて思ってないはずだが...なのに多くの人が、あたかもそのような振舞いと判断をしてしまう。潜在意識の Big Issue だから？ o 信用できないテストデータ も負債 o 現
第9回 プロジェクトに対する環境固有設定の導入 ｜ DevelopersIO
よく訓練されたアップル信者、都元です。本連載はSpring Frameworkの解説が主ですが、今回はあまりSpringとは関係ない話をします。 システムを構成するためのあらゆる情報は、基本的にGit等の構成管理ツールの下で管理するのが望ましい、というのは一般的に共通の認識だと思います。しかし一方で、そのシステムを扱う全ての人に共通するわけではない設定、つまり環境固有の設定というのもあります。例えば、 ローカル環境での起動時 接続すべきデータベースのホスト名、ポート番号、DB名、ユーザ名、パスワード 仮にAWSを利用する場合、そのアクセスキーとシークレット 仮にAmazon S3を利用する場合、そのバケット名 ログ設定ファイルのpath（ローカル起動でログ設定は各自自由に設定したいですよね） Springの起動プロファイル（あ、Springに関係あった！ 後で触れます。これも各自自由に設定
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
