魅力的なプロダクトバックログで開発を楽しく！
どんな開発プロセスでも製品やサービスを作るときは何からの形で要件をまとめると思います。KRAYが採用しているアジャイルソフトウェア開発フレームワーク『スクラム』では、製品やサービスの要件リストをプロダクトバックログと呼びます。実はこのプロダクトバックログ、その書き方や運用の仕方で開発のモチベーションが大きく違ってきます。書き方一つで、開発チームにとってもプロダクトオーナーにとっても見るのが楽しみな資料になりうるのです。 今回は、見るのが楽しみになる魅力的なプロダクトバックログを作るコツについてお話しします。 プロダクトオーナーから見たプロダクトバックログ 最初にプロダクトバックログのライフサイクルについて簡単におさらいします。 開発が決まったら、プロダクトオーナーは製品のビジョンを実現するために必要な機能などをユーザーストーリーと呼ばれる文章で表現し、プロダクトバックログに追加していきます
クソコードに対する怒りとコードレビューにおける人格攻撃について | おそらくはそれさえも平凡な日々
デキるプログラマだけが知っているコードレビュー7つの秘訣 7つの秘訣の1〜5は本当にそのとおりだと思います。 「怒り」って言葉を使っているところはなかなか画期的だと感じた。というのも僕は前から「人格攻撃に思われて」しまうような、コードで人を殴るようなことをしてしまう人が出てきてしまうのは何故かということを考えた時に、そこには「コードに対する怒り」があるからだろうなと思っていたからである。怒りがあるからこそ強く指摘しすぎてしまうことが起こりうる。 「怒り」というのはつまり「感情」である。であれば、「その『怒り』はコードに向けられたものであり、書いた人に対してのものではないので、その人に対しての攻撃ではない」というのは、理屈ではかろうじて通るかもしれないが、書いた人の「感情」的には通らないこともあることは理解したほうが良いと思う。 じゃあ怒らなければ良い、という話にはしたくなくて、どうしても怒
モダンなWebプロジェクトにおけるベストプラクティス | POSTD
Oktavilla では、私たちは定期的に新規プロジェクトを立ち上げています。数年にわたって、私たちはこうしたプロジェクトを通してベストプラクティスを見つけ出してきました。そのおかげで、新規メンバーがスムーズにプロジェクトに参加できるようになり、エラーを減らすこともできました。こうしたベストプラクティスを、組織内部、クライアントを問わず大半のプロジェクトに活用しています。結果として、私たちは高品質のWebプロジェクトを実現しています。ここでお伝えするのは、そのプロセスの一部です。 このブログ記事では、技術面に関わるベストプラクティスに焦点を絞りたいと思います。例えばセットアップや、プロジェクトのツールやプロセスを選択する際に考慮すべきことなどについてお伝えします。各プラクティスの文末に、詳細な情報へのリンクをいくつか貼っています。 READMEファイル まずは、プロジェクトで最も重要なファ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
