testing - スクラム、ただしテストやドキュメントなし

Question

スクラムを使用しているが、プロセス全体ではなく時間管理ツールとしてのみ使用しているというチームに参加した場合、あなたはどうしますか? バックテストとドキュメントを元に戻すにはどうすればよいですか?

テストと文書化に特化したユーザー ストーリーを追加することから始めようと考えていました。おそらく、他の誰かがこれについてより多くの経験を持っているでしょう。

Answer 1

テストもドキュメントも実際にはスクラムの一部ではないことに注意してください。スクラムは純粋なプロジェクト管理アプローチです。あなたが言及したような必要なエンジニアリング手法は、プロジェクト中に「出現」することになっています。そして最も具体的には、それらはすべてのスプリントの終わりに行う心拍の回顧展の間に識別されることになっています。あなたはそれらをやっていますか？そこで懸念事項を提起できますか？実際、チームが抱えている最大の懸念事項ですか？

Answer 2

スクラムの鍵は、タスクが「完了」と分類される前に、「完了」と識別できるようにすることです。ドキュメントやテストを確認せずに、何かが完了したかどうかをどのように評価しますか?

おそらく、彼らはそれを行うための珍しい、しかし有効な方法を持っています. あるいは、「完了したタスク」のポイントを逃したのかもしれません。どのように測定しているか、改善できるかどうかを尋ねることから始めることをお勧めします。次に、プロセスを改善する方法として、文書化とテストを提案します。

Answer 3

ドキュメントやテストがないこと、またはスクラムの方法論全体を実装していないことが問題ですか? これらは私の心の中で2つの非常に異なる問題です。

私は、上から真のプロセスを 1 つだけ命令するのではなく、時間と労力をかけて開発スタイルに合った開発プロセスを見つけて適合させる組織を望んでいます。したがって、彼らがスクラムと呼んでいるが、すべての「公式」ガイドラインを満たしていないプロセスを使用していたとしても、私はまったく心配しません。プロセスがそのようになっている理由を特定してみてください。彼らが時間をかけて調整した場合、特にあなたが時間をかけて物事がそのようになっている理由を判断した場合、チームはあなたのアイデアを受け入れてくれる可能性があります。「これはスクラムではないので、正しくない」という単純なアプローチでは、おそらく大きな前進はありませんが、メリットについて実際的に考えることで、大幅な改善を実現できる可能性があります。

あるいは、彼らがテストを行っておらず、ドキュメントも持っていない場合、それはかなり悪い兆候だと思います. そして、ドキュメンテーションによって、私はここで最小限のビューを取っています - 機能のリスト、バグ追跡など - これらの項目がないことは非常に心配ですが、抽象化リストの上位に項目がないことはあまり心配しません. 経営陣からのサポートがない場合は、模範を示すことをお勧めします。自分で簡単なバグ追跡システムをセットアップしてください (いくつかあります - ピンチでは、中央の場所にある簡単なテキスト リストも同様に機能します)。他の誰かがテストするまで、機能が完成したと宣言しないでください。これは、別の開発者のところに行って、目の前で試してみるように依頼するのと同じくらい簡単です。ある機能が完成したと主張する人がいる場合は、数分かけてその機能に慣れてください。バグを見つけた場合は、担当の開発者に丁寧に伝えてください。チームがテストを実行し、機能とバグを追跡することの利点を理解できる環境をゆっくりと構築します。

ほとんどのチームは、単に「正しく行う」時間がない、または後で行うという誤った信念のために、この方法で運営されています。多くの場合、これは、1 人または 2 人の開発者がサイド プロジェクトとして行った単純な概念実証が、本格的な開発作業に変わるときに発生します。時間と労力を実際に節約できることを示し、チームの他のメンバーの初期コストを削減することで、公式に承認または承認されることなく、プロセスの一部として定着することがよくあります。

管理者のサポートがあれば、はるかに簡単になりますが、チームが変更を受け入れるように常に注意してください。これは、必要以上に時間がかかることを意味する場合がありますが、チームのサポートがなければ、義務付けられたプロセスは、圧力の最初の兆候、つまりプロセスが最も必要なときに失敗します。

*免責事項 - 私の最後のプロジェクトでは、私は環境に合わせて SCRUM プロセスを調整する動きの先頭に立ちました。「正式な」プロセスは、クライアントにとって受け入れがたいものでしたが、それでもプロセスを調整する上で非常に貴重なガイドでした。

Answer 4

「特にテストと文書化のためにユーザー ストーリーを追加する」

メタユーザーのストーリーは、一部のサークルでは理にかなっているかもしれませんが、うまくいくことはめったにありません. ソフトウェア関係者は、メタユーザー ストーリーにうまく対処することはめったにありません。ストーリーを書くことで自分のプロセスを変更できるという考えを理解していないか、より一般的にはメタユーザー ストーリーを設計して死に至らしめています。

ユーザーにインタビューしていると、ユーザー ストーリーを作り上げているように感じます。確かに、彼らの話を聞いてそれを捉えようとするとき、あなたはそれを作り上げています。

IT 組織が、IT がどのように機能するかについて独自のユーザー ストーリーを作成しようとすると、プロセスが崩壊します。組織がそのこと (たとえば、テスト) を手動で何度も行うまでは、ユーザー ストーリーを書く資格はありません。その後、ソフトウェア開発プロセスは必要なく、重要な部分を少しずつ自動化するだけです。

変化は、形式ばらない方向からもたらされなければならないと思います。実際、テストされていないことを「完了」と呼ぶのを躊躇することは、良い出発点です。

強制されない限り、IT は何もしません。そのため、ユーザーに会って、テストが不要な理由を見つけてください。テストが必要になるように指導します。結果と使用する言葉を伝えます。

組織内で多くの問題が発生し、不十分なプロセスにつながる可能性があります。何が問題なのかを知り、変化への要求を生み出すことが重要です。可能な限り最善の方法は、おそらくそれを修正するのが良いだろうと提案するのではなく、修正していないと上司に不平を言うことです.

[上司がプロセスの修正を要求するのは気分が悪いが、変化が起こる唯一の方法だ。]