こんにちは、habradrug。 ソフトウェア開発におけるウォーターフォール （ カスケード ）が人種的に正しいアプローチだと思いますか？ はいまたはいいえ-猫に急いでください。
たとえば、eXtemeプログラミングテクニカルプラクティスを含むスクラムを使用して、 SmartNut Webサービスを開発しています。 他に2週間ごとにビジネス価値を顧客に提供する方法（リリースサイクル）。 Lean Startupをやっている人たちに帰することができると思う。
Scrum c XPは私の最後のチームでも使用されましたが、ここではトピックをより生産的に開発しています。
スクラムとXPの基本的なテクニックについて簡単に説明します。これらのテクニックを実装、サポート、変更、改善して、効率を高めています。
0.私たちのチーム
製品所有者（PO）、チーム、スクラムマスター、すべてが本のようです。 POは製品の所有者であり、タスクの履歴と優先順位付けを担当します。 PO要件を実装するチームには、開発者とテスターが含まれます。 スクラムマスターはチームのメンバーであり、スカムマスターの機能に加えて、製品開発者でもあります。
1.繰り返し
最近まで、反復は毎週行われ、2週間に1回アプリケーションを更新しました。
タスクの主な動機は、反復ではなくリリースであると感じていました。 したがって、リリースのリリースに干渉しなければ、タスクは反復から反復に頻繁に移動しました。
リリースサイクルに反復を付加して、オーバーヘッドを削減できるかどうか、さらに長いタスクを2週間の反復に収めることができるかどうかをテストしました。
プロジェクトの各段階での柔軟性はどの程度ですか？
2.計画
製品ビジョンがあり、それに基づいて、リリース計画が定期的に作成されます。 リリースとは、一定の期間実装できる特定の機能セットであり、現時点で顧客への配信の優先度が最も高いものです。
このようなリリースの計画により、製品開発の「一般的なライン」を確認できます。 このリリースのすべてのタスクが実装されるわけではありません。主なことはこの方向です。
マイクロリリースは2週間ごとにリリースされます。
製品所有者は、イテレーションの始めにストーリーを書きます。 それらをスムーズで滑らかにするために、POは以前の反復でチームとストーリーを議論するために時間を割く必要があります。 一部の制作は受け入れられ、一部は修正され、一部は実装が実際に必要になるまで延期されます。
たとえば、2つのタスクがあります。最初のタスクは新しい機能を追加し、2番目のタスクはそれを開発するか使いやすさを向上させます。
最初のタスクが「撮影」されることを疑う場合、つまり それがお客様に具体的なメリットをもたらす場合、統計を収集してフィードバックを受け取るまで、2番目のタスクを延期できます。
2.5評価
私たちは私たち自身の経験から見て、日と時間での個々の評価が非常に不正確であることを知っています。 したがって、スコアの独立性を確保するために、Planning Pokerを使用してポイントとポイントを獲得します。 ちなみに、これも楽しいです！
興味深いことから：以前、私たちは常に単一の評価に到達しようとしました。 しかし、Jeff Sutherland（写真）は、すべてのプレイヤーがフィボナッチシリーズの連続するカードを捨てた場合の算術平均の計算による解決策を提供します。
3.労働条件
私たちのチームには独立した大きくて明るいオフィスがあります。 タスクの議論、集会の開催、障害物の探索と排除を妨げるものは何もありません。 毎朝11〜30時にスタンドアップミーティングを開催します。これは、最高の伝統では15分間続きます。 速度を数え、成長をそれ自体の目的としてではなく、常に成長を続けようとします。
プログラミングの同僚の隣に座ることは犯罪とは見なされません。 インフラストラクチャの問題と環境の問題を解決する支援は、名誉ある仕事と見なされます。
4.システム設計
最も難しい部分は、エンドユーザーとチームのすべてのプログラマーの両方にとってシステムがシンプルで理解しやすいように開発を行うことです。 機能が明らかでない場合、廊下の2人がコンピューターに座って、POまたは開発者が計画していることを把握できない場合は、何かを変更する必要があります。 私たちはチームとして、シンプルさの方向に向かっています。常にうまくいくとは限りませんが、試してみます。
同じことが、市場がまだニーズを示していない機能にも当てはまります。 それらを追加したいのですが、どうしても必要なようですが、誰が使用するのでしょうか？
5.開発の過程で
設定について質問がある場合は、当社のオフィスに座って製品所有者がそれらすべてに答えることができます。
私たちはコードを書くための標準を持っているので、他人のコードを不必要な感情なしに私たちのものとして見ることができます。
TDDは使用しません。 テストは、コードの記述後に、見つかったエラーについて書かれます。
継続的な統合プロセスにはJenkinsを使用しています。 Jenkinsがsvnのコードが更新されたというシグナルを受け取ると、プロジェクトは自動的にビルドされます。 テストが開始され、静的コードアナライザーが起動されます。 否定的な結果は、もし場所があるなら、変更がアセンブリにある人々に通知されます。
ペアプログラミングが明示的に行われていないため、コードレビュー手順を実施します。 CRを実行することは、タスクを準備するための基準です。
誰もがシステムのすべての部分に変更を加える権利を持っています。これにより、責任が増し、欠落している可能性が減ります。
単体テストに加えて、システムの主な機能の受け入れテストもあります。これは、リポジトリ内のコードを更新した後にも合格します。
タスクの準備状況の別の基準は、コミット前にステートメントのコンプライアンスをテストおよびチェックすることです。 開発者は、タスクの準備が整ったと判断したら、テストのために送信します。 テスターはタスクをチェックし、品質と完全性に満足した後にのみ、タスクは完了したと見なすことができます。 これにより、タスクを切り替える時間を節約し、既にテスト済みのフォームにあるコードをリポジトリにアップロードします。
この手順では、複数のタスクで構成される可能性のある各ストーリーが完了した後、テスターと製品所有者によるリリースを開始する前の受け入れテストを除外しません。
生産性を最大限に高めるには、開発チームで努力するXPプラクティスの最大数を使用する必要があります。 しかし、スクラムチームフレームワークのすべてのプラクティスを忘れてはなりません。
スクラムは、スクラムマスターの仕事の1つは障害物を特定して取り除くことだと言います。 最近まで、プロセスの根本的な改善についてはほとんど考えていませんでした。 このためのスクラムテクニックには特別な会議がありますが、振り返って振り返り、障害を探し、使用されている優れたプラクティスを整理する必要があります。 現在、反復ごとに回顧を行い、A3シート（および3枚）を使用してプロセスのボトルネックを特定しています。
他のすべては、各反復の終わりに、他の部門からの自慢のデモ、他の部門の同僚を、反復のためにしたことを保持します。 たくさんの有用な提案がありますが、あまり提案されていません。また、これまで気付かなかったバグが見つかることもあります。
一般に、各反復でお客様からフィードバックを受け取ります。SmartNutを使用すると、周囲の世界が少し良くなると自信を持って言えます。 2週間ごと。
あなたの目標が波の頂上にあり、本当の滝だけを楽しむことであるなら、できるだけ頻繁にあなたのクライアントにアップデートを届けてください。 そして、スクラムとXPがこれに役立ちます。
PSハブラドラッグであるあなたがまだ私たちがしていることはイデオロギー的に間違っている、またはその逆であると思うなら、あなたは賞賛したい、そしてコメントへようこそ。