it-swarm-ja.com

アジャイル開発プロセスは、早期導入ユーザーにとってUXを損なう可能性がありますか?

私は常に、初期のアダプターのような、最新のソフトウェアについて知らされ(そして、可能であれば...)使用するように努めてきました。

そして、ここ数年、手に入れられる可能性のあるすべての製品(ほとんどの新しいアプリ)の品質が低下していることに気付きました。特にアプリには名前を付けませんが、採用のせいかもしれません「アジャイル開発プロセス」の概要。

そのため、私は使用しているすべてのアプリのマイナーアップデートをスキップし、「成熟した」安定したソフトウェアのみを試して、「より長い」ものになっています。

アジャイル開発プロセスがアーリーアダプターのUXを台無しにしている一方で、必要なだけ開発プロセスを何度も繰り返して、できるだけ早くソフトウェアを市場に投入することを目指している可能性はありますか?つまり、バグの多いアプリケーションと小さな更新の無限のストリームで市場をあふれさせます。

3
rraallvv

アジャイルプロセスが機能するためには、テストプロセスが効率的でなければなりません。開発者がBDD( Behavior-Driven development )などのベストプラクティスに従っている場合、企業は1日に4回展開してバグの数を減らすことができます。 GitHubや他の多くの企業は、このアプローチに従います。

問題は、デプロイ前にコードが適切にテストされていないか、テストに適切な重要性が与えられていないことです。振る舞い主導の開発について読んでください、それは基本的に開発者がテスト主導のコードを書くことを意味します。

2
Rosie

どのように作業するかによって、サービスと更新サイクルが決まります。頻繁な更新とアジャイル開発が常に製品全体に悪影響を与えるわけではないことを説明しようと思います。エンドユーザーの認識から、更新が多すぎると、成熟したソフトウェアではないと認識される可能性があります。ただし、前述のように、これは認識であり、これらの2つのルールに従って賢明に設計されている場合にも利点となります。

  • 一度にすべての弾丸を使用しない
  • 機能とバージョンマップを顧客と正直に共有する。

一度にすべての箇条書きを使用しない:更新がある場合、全体的なエクスペリエンスを向上させる可能性がある要素があるはずです(例:アバター、ショートカット...)

機能とバージョンマップを顧客と正直に共有します。優れた例の1つは、図アプリであるGrafioです。彼らが製品を発売したとき、彼らは彼らの0のイテレーションを次のものと共有しましたか? FTEとして。各更新では、それらが展開した新機能と、それらが次に何をするかを確認することもできます。

2
Abektes

アジャイルは開発方法論です。開発者の作業方法は、ユーザーのエクスペリエンスとは別の問題です。

UXに関する質問として再構成したのは、おそらくMVP(Minimum Viable Product)の概念であり、認識した問題の原因となっている迅速な反復と組み合わされていると思います。

MVPを戦略として使用することの問題については、ある程度の量が書かれています(ただし、MVPはいくつかのケースでうまく機能します)。

http://www.andybudd.com/archives/2011/12/the_tyranny_of_the_minimum_viable_produc/

http://pandodaily.com/2013/02/04/three-reasons-not-to-build-a-minimum-viable-product/

2
edeverett

はい、できます!

しかし、企業は完全を出荷するのではなく、利益を生み出すというビジネスを行っています。ユーザーが依然として低品質のアプリを購入する場合-実際、次のリリースで数日ですぐに修正される問題が予想されます-そして、ビジネスの観点から、迅速なリリース戦略はworking正しく

次に、UXerとしての私たちの闘いは、俊敏な方法でフィードバックを提供することです。製品の使いやすさを改善しながら、顧客との高速フィードバックループが壊れるような製品スケジュールへの悪影響を回避します。一方、顧客からの絶え間ないフィードバックは、UX改善のためのデータの宝庫です。

おそらく、あなたの知覚は調整が必要なものです。私は知っている。最近私たちは皆、やや不規則なリリースが見られると予想しています-iOS7には1000のマイナーな欠陥があります-その後、これらの最悪の問題を修正するための迅速なX.0.1リリースがあります。

1
Alex Feinman