「Lightning Review Tips」タグの記事が14件件あります

Lightning Review (以下、LR)開発チームに参画して、半年の前川です。
以前のチームでは一番年下だった私が、このチームでは上からかぞえた方が早くなりました。。。歳を感じる今日この頃です。

さて、レビューファイルに指摘を追加した後、修正者をどこまで割り振ったのかわからなくなったことはありませんか？

LR の修正者の割り当てについて​

LR は、指摘を追加したときに先頭に設定されたメンバを自動的に修正者に割り当てます。
この機能はとても便利なのですが、1つのレビューファイルに対して複数人が修正を並行して行うようなケースでは、指摘ごとに修正者を割り当てる必要があります。

しかし、レビュー時に都度、修正者を割り当てるのは手間であるため、修正に着手する時に修正者を変更することが多いかと思います。
このようなケースでは、修正者が自動的に割り当てられることで、逆にどこまで適切に修正者を割り振ったのか、わからなくなることがしばしばあります。

修正者の割り当てが適切にされないと、メンバ間の認識の齟齬によって、1つの指摘を複数人がそれぞれ修正してしまったり、お互いが手を付けずにお見合いしてしまったりすることが発生します。
こういった事象は、プロジェクトの管理を難しくする一因になります。

未定を表すメンバを追加して解決する​

この問題を解決するための効果的な方法があります。
それは、未定を表すメンバを追加して、このメンバを修正者として自動的に割り当てられるようにしておくことです。
これにより、修正者が割り当てられていない指摘が一目瞭然になり、プロジェクトの管理が格段に楽になります。

未定を表すメンバの追加手順​

次の手順で、未定を表すメンバを追加します。

1. [概要]ページを表示させ、ナビゲータの[メンバ]を押下することで、メンバの設定画面を表示させます。
2. [メンバ追加] ボタンを押下すると、[新規メンバ]というメンバが追加されるので、メンバ名を(未定)に変更します。
3. (未定)のメンバを選択して、[↑]ボタンで一覧の最上位に移動させます。

この設定を行うことで、指摘を新規に追加したときに、修正者に(未定)が設定されるようになります。

(未定)のメンバを追加したテンプレートを利用したり、スクリプトから追加したりすることでメンバ追加の手間も減らせます。
ユースケースに合わせて、利用してみてください。

まとめ​

修正者の割り当てに焦点を当て、スムーズなレビュープロセスを実現するための Tips をご紹介しました。
この Tips を適用して(未定)のメンバを追加することで、複数人で1つのレビューファイルの処置をするときに、誰がどの指摘を修正するかが一目瞭然になり、プロジェクトの管理が格段に楽になります。

是非、この Tips を実践して、スムーズなプロジェクト管理ができるようなプロセスを構築してみてください。

では、また次の記事でお会いしましょう。

Lightning Review (以下、LR)開発チーム、入社3年目の角谷です！
最近ようやく涼しくなったので、キャンプ場に焚火しに行きました🔥
ついでに、買ってから眠っていたダッチオーブンで燻製も作ったのですが、初めてにしては美味しくできました。
ベーコン、チーズ、ソーセージの燻製を作ったのですが、特にソーセージが美味しかったです。
この調子であらゆるものを燻製にしていきたいですね。

今回は LR のTipsとして、「中間レビューごとに指摘を管理する」使い方についてご紹介します。

大きな変更を伴う開発アイテムを経験の浅い開発者が担当する場合、一度のレビューで成果物の全体を確認すると、似たような指摘が大量に発生してしまうかもしれません。
コードレビューを例に挙げると、私の過去の経験では以下の内容で指摘されることが複数回ありました。

• ソースコードのコメントの書き方がコーディング規約に沿っていない
• 処理が共通化されておらず、コピーコードになっている

効率的な開発のためには、早めに問題点を検出し、類似のミスはしないように進めていくことが大切です。

このような問題に対して、私たちのチームでは成果物が完成する前に何度かレビューすることを「中間レビュー」と呼んで実施しています。
開発途中の成果物に対して、中間レビューで識者の指摘をもらうことで、開発者はその後の開発において中間レビューの指摘を参考に、成果物の問題点を事前に摘み取りやすくなります。
中間レビューでもらった指摘は、LR を使うと例えば以下のように管理できます。

LR では一つのレビューファイル内で複数のドキュメントとアウトラインノードを自由に作成できるので、中間レビューごとにドキュメントやアウトラインノードを用意すれば、指摘を簡単に分類できます。
開発者は中間レビューでもらった指摘と類似の指摘がその後のレビューで出ていないかを確認することで、自身の仕事の振り返りにも活用できます。

ぜひ、試してみてください！

Lightning Review(以下、LR)開発チーム、入社6年目の新美です！
11月に入ってあったかいものがおいしい時期になりましたね。
こんな時期には、やはりラーメンが食べたくなってしまいます🍜
寒くなくても週3で食べてしまうんですけどね……

今回は、LRを活用してレビューアへの相談事項を管理するTipsをご紹介します。

レビューで見てほしいポイントは独力では作り込めなかった、あるいは不安なポイントであると思います。
そんなポイントをレビューで相談できるようにLRを活用しましょう。
作り込みの最中でもLRを利用して不安なポイントを保存しておけば、よりレビューアの知識を引き出せるレビューとなるはずです。

たとえば、外部仕様の作り込みで不安なポイントを指摘にします。
具体的には、ダイアログのテキストボックスにおいて不適切な文字列を入力された場合に、ダイアログのOKボタンを無効にするか、OKボタンを押下したあとにエラーダイアログを表示すべきかで悩んだとします。
その場合に上記のような不安なポイントを指摘として登録することで、レビューの場ではどのような考え方や判断をして、どちらを採用すると良いのかをレビューアに聞くことができます。

そして、レビューアに聞いた方針を元に、レビューイがその方針とした理由とともに修正内容を記し、修正済みにステータスを遷移させます。

レビューアは修正内容を確認し、レビューイの理解度も確認した上で確認済みにステータスを遷移させられるため、指導も指摘修正も、どちらも確実にやり切れます。

上記をヒントにしていただき、相談事項をLRでレビューアと共有すれば自分の不明点も解消でき、より質の高いレビューにつながると思います。

実際、私はレビューア・レビューイの両方の立場となった経験がありますが、レビューのポイントを絞って集中して議論できるため、とても効果的に感じました。

ぜひ、試してみてくださいね！

レビューとは一口にいっても外部仕様や実装、テストなど対象となる工程も幅広く、成果物も仕様書や設計書、ソースコードなどさまざまです。
また、レビューでチェックすべき項目や検出される指摘の種類も、工程や成果物ごとに異なります。
このように多様な工程や成果物に対して、レビューを実施するたびに指摘の分類や原因工程・検出工程、カスタムフィールドなどのレビューに必要な情報を毎回レビューファイルに設定するのは大変です。

そこで、工程別のレビューファイルのテンプレートを事前に作成することをオススメします。
指摘の分類や原因工程・検出工程、カスタムフィールドなどが設定されている既存のレビューファイルから指摘を削除し、工程別にテンプレートとして保存します。
保存したテンプレートからレビューする工程に合ったテンプレートを選択してレビューファイルを作成することで、既にレビューファイルに必要な情報が設定された状態でレビューを開始できます。
これにより、複数の工程に対してもレビューファイルの準備に手間がかかったり、もれがあったりすることなくレビューを実施できます。
テンプレート機能の詳細はこちらを参照ください。

さらに、Lightning Review 開発チームならではの使い方を紹介します。
事前に工程別のテンプレートに、図のようにセルフチェック観点をあらかじめ指摘として登録しておきます。
レビュー前に、レビューイはセルフチェック観点に対する処置内容を指摘の[修正内容]欄に記入し、その指摘のステータスを[修正済み]にします。
例えば、実装工程で処理速度が妥当か確認する観点であれば、処理速度の計測結果を[修正内容]欄に記入します。
そして、レビュー時にレビューアが確認して、処置内容が妥当であれば、指摘を[確認済み]にします。
レビューファイルにセルフチェックの指摘があることで、レビューイはレビュー準備の際にセルフチェックを忘れずに実施できますし、レビューアもレビューイがどのようにセルフチェックを実施したかを指摘の[修正内容]欄から確認できるため、重要なチェック項目について認識の誤り・ずれなどがあってもレビューで摘み取ることができます。