アジャイルには、XP、スクラム、リーン、カンバン、スクラムブット（ScramNO）などの多くの方法論が含まれています。 メソッドを分析するために座って、私は私のチームがそれらのいずれかに取り組んでいるとは言えないことに気付きました。 一般的に、ワークフローは次のように表すことができます。
ご覧のとおり、さまざまな方法論の多くのポイントを使用していますが、すべてではありません。 開発プロセス、チームに方法論を適合させました。
XPプラクティスからの多くの推奨事項を使用し、カンバン方法論の開発プロセスで類似のものを見つけましたが、ポイントの一部はスクラム方法論から取られましたが、別の軸を選択してConferencesと名付けました。 多くの有用なアイデアが会議から得られたからです。 初心者のプロジェクトマネージャー（y）、チームリーダー（y）は会議から始めるべきだと言うことができます。ただ来て聞くだけでなく、プレゼンテーションの後にスピーカーに行き、興味のある質問をしてみてください。 それがリリースページが私のチーム、チーム、および個人の目標にどのように現れたか、私のQAスペシャリストが会議からインパクト分析や「テスターアナリスト」の概念などの有用なものをもたらしました。 しかし、メイントピックから気をそらされず、ソフトウェア開発方法論に戻ることはありません。
スプリントと製品バックログの概念はプロジェクト管理の基礎であり、スクラムに精通している人なら誰でもすぐにこれらが彼の主な成果物であると言うでしょう。 しかし、当社のチームにはプロダクトオーナー（a）はいません。ユーザーストーリーには優先順位もストーリーポイントもありません。 Planning Pokerでプレイするためのスクラムカードはなく、バーンダウンダイアグラムを描画しません。スクラムボードの代わりにリリースページがあります。
そして、私たちは怠tooすぎたり、その方法を理解していないからではなく、これらすべてを使用するわけではありません。アプリケーション開発プロセス中に一部のアーティファクトが消えました。 顧客は優先順位を付けたくありませんでした。なぜなら、 彼にとって、すべてのタスクは重要です。私たちはストーリーポイントで「仲間」になりませんでした。 新しいタスクがスプリントに詰め込まれる可能性があります。 また、ダイアグラムを作成しなかったため、視覚的ではありませんでした。 開発中に状況を尋ねられたら、次のようなリリースページを表示します。
一度、アレクセイ・ルパンは私を導くように彼女に助言し、彼は会議で話し、彼のプロジェクトに似たようなことを示しました。 私は自分のプロジェクトにそれを実装し、それが便利であることが判明しました。 このページには、リリースに含めた機能の数、各機能の責任者、条件の一覧が表示されます。 テストと本番の締め切りも示されています。 ここで最も重要なことは、製品の新しいバージョンをリリースする前に注意を払う必要があるすべての重大で非常に重要なエラーのリストです。 プロジェクトに複数のテスターがいる場合、私はこのページが気に入っています。「重要なエラーをテストします。他の誰かのためにフレーム化されているかどうかは関係ありません。見直した方がいいです。 新しいものを見つけることができます。」 そしてそれは動作します。 あるテスターが別のテスターでエラーを見つけたときに、このような状況が何度発生しましたか。 本当に節約できます。 もちろん、常に二重のテストを実行できるとは限りませんが、可能であれば、それを実践しようとしています。 ここでは、格言がうまく機能し、1つの頭が良い、2つの頭が良いです。
そして、私たちがスクラムで使用しないものをあなたに話しました。 そうそう、私はほとんど忘れていた、私たちは毎日のスタンドアップ集会を開催していません。 私たちは近くに座って腕を伸ばし、議論されていることはすべてチームの隣で議論されています。 したがって、会議は必要に応じて開催されます。 基本的に、顧客が必要とするとき。 次に、リリースページを印刷し、サブタスクに分割されたタスクを印刷します。各サブタスクの反対側のステータスと、問題がある場合はコメント列にコメントが表示されます。
一般的に、仕事の過程で、私は自分のために2つの真実を学びました。
1.顧客は、あなたが取り組んでいる方法論を気にしません。実際、彼は最終結果に興味があります。
2.顧客が期待以上に顧客に提供すると、顧客は幸せになります。
リリースの最後にエラーが検出されると、顧客は、たとえばスクラムなどで作業していることを忘れてしまうため、これも複数回、特に最初の真実を確認しました。 このような質問は、「いつ修正されるのか」、「誰が責任を負うのか」、「なぜそれが起こったのか」という頭の中で展開されます。 そして、この順番で気になります。 現時点では、顧客がPlanning Pokerのプレイ、ストーリーポイントの配置、スプリントの計画を開始することを期待しているとは考えられません。 また、前のスプリントと比べて速度が2倍になったとしても、速度は彼に興味を持ちません。 そして、彼もチャートを見ません。 したがって、スクラムの一部のアーティファクトが邪魔をしたり、プロジェクトであまり役に立たないと思う場合、それらを捨てることを恐れないでください。それは何の問題もありません。 主なものは、あなたのチームが前進し続け、変化に関して柔軟であることです。 スクラムは、別々の部分で構成される一種のフレームワークです。 すべてのパーツを使用したり、徐々に接続したり、ニーズに合わせて何かを変更したりできます。 これでは、私には思えますが、方法論の下で曲がるのではなく、方法論があなたの下で曲がるとき、柔軟な（アジャイル）方法論のポイントがあります。
私が気に入っており、実を結んでいるもう1つの真実は、テスターにできる限り多くの時間をかけて完成品をテストし、テスターに作業の中間結果をテストさせることです。 おそらく、前の文の2番目の部分が主な部分です。 私は常にテスターにアプリケーションの生のバージョンを感じさせました。 なんで？ 彼らが批判を始めるために、彼らは何かが便利ではないと言い、アイデアをもたらし、何が起こるかをテストするテストを書き始め、ロジックとインターフェースのボトルネックについて考え始めました。 それは少し退屈になりますが、それでも実を結びます。 主なことは、私が多くのプロジェクトで聞いたことがある1つの間違いをしないことです。 間違いは、テスターとプログラマーが別々に座っており、最も重要なのは、彼らが直接通信していないことです。 つまり 2つの敵陣営が形成されています。 これは正しくありません。あなたはチームであり、同じ製品に取り組んでおり、目標が一致していることを忘れないでください。 互いに助け合い、一緒に座り、質問をし、コミュニケーションを図ります。