タグ付けされた質問 「review」

多くの企業と同様に、私が働いている会社は、SMARTの目標に基づいたパフォーマンスレビューシステムに移行しています。私のチームは、Extreme Programmingのプラクティスを採用した高機能でアジャイルな開発チームです。私たちの大きな利益のために、私たちのアジャイルプラクティスの採用は、直属の管理職の完全なサポートを持っています。 作業を完了するために、私たちのチームは3週間の反復を利用します。即時の反復を超えて、四半期ごとに一般的な計画を立てています。これから数四半期で達成したことは、当四半期で達成することよりもはるかに厄介であることを意味します。私たちのプロジェクトがどこに向かっているのかは確かに一般的な考えを持っていますが、ここでのキーワードは一般的です。 私自身を含む私のチームのプロジェクト計画メンバーへのアプローチを考えると、具体的、測定可能、達成可能、関連性、および時間制限（SMART）の目標を書くことは難しいと感じています。 SoftwareEngineering.seに関する2つの既存の質問は、私たちの懸念のいくつかに対処するのに適しています。 プログラマーにとって良いSMART目標の例は何ですか？ SMARTの目標はプログラマにとって有用ですか？ ただし、アジャイル開発チームで作業する場合、質問はSMART目標を処理するための詳細よりも一般的な回答を引き出しました。アジャイル開発者として、具体的、測定可能、達成可能、関連性があり、時間制限のある5〜7年間の目標をどのように記述しますか？

29 agile  management  planning  review 

私のチームでは、主要なコードレビューが隠蔽されていると考えています。コメントなしでマージされたコードレビューが多すぎます。 単一のコメントなしにコードレビューのようなものはないように思えます。 チームリーダーとして、チームが適切なコードレビュープロセスを行っていることを適切に監視し、プロセスのメリットを最大化するためにチームを支援するにはどうすればよいですか？ 更新 人々はアップデートについて知りたいと思うかもしれません。ここで与えられた多くの提案を試みました。ほとんどはすでに使用されていました。一部は少し助けた。しかし、問題は残りました-私が見ていなかったときに、一部の人々は絶えず悪いコードを得ました。 コードレビューの監視は、チームツールを提供してコードを改善することほど有用ではないことがわかりました。 そこで、コピーペーストを検出するために「jscpd」という名前のライブラリを追加しました。コピーペーストでビルドが失敗しました。これにより、1つの問題がすぐに解消されました。 次に、codeclimateを試します。 また、半日スプリントで1回、古いコードレビューの手動レビューを行っています。私はtodosを問題/チケットに変換しています-人々がそれらを書いていることがわかりましたが、後で処理されることはありません。また、適切なときにコードをレビューするために、チーム全体と会議を行っています。 一般的に、正しい方向に進んでいるように感じます。

28 code-reviews  review