Genel olarak konuşursak, tüm fonksiyonel parçaları yapmak veya önce UI'nin çalışmasını sağlamak mı - yoksa ikisinin bir karışımı mı?


47

Genel olarak konuşursak, tüm fonksiyonel parçaları yapmak veya önce UI'nin çalışmasını sağlamak mı - yoksa ikisinin bir karışımı mı?

Büyük bir şey üzerinde çalıştığınızı varsayalım, herhangi bir UI'dan önce çalışan tüm işlevsel veri toplama bloğlarını almak, tüm UI'yı gittiğinizde tek bir parça çalıştırmak veya ortada bir şey yapmak genel kabul görmüş bir uygulama mıdır?

Hepimiz işleri yönetilebilir parçalara ayırmayı biliyoruz, ancak soru, nihayetinde UI'nin yönetilebilir parçalara dahil edilip edilmediğidir.

Örnek için, tek bir kök pencereli bir GUI uygulamasını, ancak farklı veri bileşenlerini ayırmak için çeşitli iskelelerdeki bir düzineden fazla sekmeyi düşünün. Her bir sekme, arkasında fonksiyonel bir perspektif perspektifinden görece karmaşık hareketli parçalara sahiptir.

Bu özel sorudaki örnek uygulama , beraberindeki blog ve orijinal ticari ürün ile birlikte burada .

Yanıtlar:


85

Pek çok işletme kullanıcısı ve müşterisi arasında , eksiksiz göründüğünde neredeyse tamamlandığı konusunda genel bir anlayış var . Muhtemelen bildiğiniz gibi, bu gerçek olmaktan uzak. Biri güzel görünmesini sağlayabilir, ancak arka uçsuz ve bazı kullanıcılar hoş görünmesini% 20 ( veya diğer% 80 ) değil, işin% 80'i olduğunu düşünüyor .

Sayısız geliştirici bunun korku hikayelerini anlatabilir - başka bir aracın ekran görüntülerini kullanarak Microsoft Word'de yapılan sayfaların bir listesini almak ve müşteri "yani neredeyse bitti mi?"

Hızlandırmanız gerekir, böylece tüm parçalar bittiğinde yapılır. Önce tüm arka uçları ve sonra tüm ön uçları yapmaya çalışmak, son kullanıcıya, hiçbir şey yapmadığınızı ve neden gösterecek bir şey olmadığında neden para kazandığınızı sormaya neden olacaktır. Öte yandan, ilk önce ön uç ve son kullanıcının niggling değişiklikleri yapan ve tüm zamanımızı tüketen son kullanıcı olduğunu göreceksiniz.

'Birincisi diğeri' olan en kötü durum, diğer kısma ulaştığınızda, tasarıma hiç uymadığını fark edersiniz.

Böylece, her ikisini de oluştur. Ön uçtaki ilerlemeyi gösterin, arka uç oluşturduğunuz şeyle çalışsın. Çoğu durumda, artımlı kurulumlar yapmak ve müşterinin istediğini yaptığınızdan emin olmanız iyi bir fikirdir (bu Çevik hale gelir). Dışarıda 'gözle görülür ilerlemelerle' çok fazla uzağa gitmek müşteri ilişkisine zarar verebilir (bu her iki durum için de 'her şey erken gözüküyor' ve 'en sonuna kadar hiçbir şey yapılmadı') - müşterinin çerçeveyi yazdığını görmesi zor veya ünite testler veya ilerleme olarak veri temizliği).

Joel bunu Buzdağ Sırrı'nda yazdı : Revealed :

Önemli Corollary İki. Programcı olmayan bir kullanıcı% 100 güzel bir kullanıcı arayüzü olan bir ekran gösterirseniz, programın neredeyse bittiğini düşüneceklerdir.

Programcı olmayan insanlar sadece ekrana bakıyor ve bazı pikseller görüyorlar. Eğer pikseller bir şeyler yapan bir program oluşturuyorlarsa, "ah, tanrım, gerçekten çalışması için ne kadar zor olabilir?" Diye düşünüyorlar.

Buradaki en büyük risk, önce kullanıcı arayüzünü alay ediyorsanız, muhtemelen müşteri ile bazı konuşmalar yapabilmeniz için, o zaman herkesin bitmek üzere olduğunu düşünmesidir. Ve sonra, gelecek yıl "örtülerin altında" çalışarak geçirdiğiniz zaman, tabiri caizse, kimse ne yaptığınızı gerçekten görmeyecek ve bunun bir hiç olduğunu düşünmeyecekler.

Bu yine blog yazısında yineleniyor Demoyu faydalı bir grafiğe sahip yapmayın.

Nasıl göründüğü nasıl oldu?

Buradaki iki seçeneğin genellikle 'kullanıcı arayüzünün yapılmasını sağlayın' (ve sonrasında beklentinin yakında yapılması gerektiğidir) ve 'arka planın sonlandırılması' (ve daha sonra müşteri son teslim tarihini kaçırdığınız için endişeleniyor) 'u yansıtır.

Bir şeyin nasıl göründüğünü, bir şeyin nasıl yapıldığını eşleştirmelisiniz.

Her yazılım geliştiricisi, kariyerlerinde birçok kez bunu yaşamıştır. Ancak masaüstü yayıncılık araçları, teknoloji yazarları için aynı baş ağrısına yol açıyor - birine mükemmel şekilde fontlanmış ve biçimlendirilmiş sert bir taslak gösterirseniz, onu istediğinizden daha fazlasını görürler. Nerede olduğumuzla başkalarının nerede olduğumuzu algıladığı arasında bir eşleşmeye ihtiyacımız var.

Bu makale aynı zamanda , kullanıcı arayüzünün farklı seviyelerde olması ile elde ettiğiniz geri bildirim türleri hakkında önemli bir noktayı da ortaya koymaktadır. Tamamlanmış görünen bir şey varsa, "yazı tipini değiştirebilir misiniz" hakkında "bu düzen çalışmaz - çok fazla sekme vardır" hakkında geribildirim alma olasılığınız daha yüksektir.


Java Swing dünyasında bununla kavga edenler için , UI'nin eksiksiz görünmemesini sağlayan (öyle olsa bile), bunu yapan Napkin adında bir görünüm ve his var .

Buradaki anahtar, yapılmadığı şekilde görünmesini sağlamak . UI görünümünün eksiksiz olması, birçok işletme kullanıcısına uygulamanın tamamlandığının bir işaretidir (arkasında herhangi bir mantık olmadan veya bir arayüz oluşturucusunda yerleşik bir şey olmadan sadece birkaç statik sayfası olsa bile).


Daha fazla okuma (ve yazının linkleri):


7
Bir tür çevik metodoloji önermiş gibisiniz ... :)
Alexander

7
@Alexander Agile bu durumda yardımcı olur, ancak zorunlu değildir. Şelale (teslim edilebilir) kilometre taşlarına sahip olabilir ve müşteriler "göründüğü halde, neden bu kadar uzun süren 3 mil daha var?" Görünce çok hayal kırıklığına uğrayabilirler. FWIW, teknoloji kullanıcılarının (şelale dükkanı) ekran görüntüsü + ms boyası nedeniyle iyi göründüğü için işletme kullanıcısının bunun yapıldığını düşündüğü durumlar vardı .

3
Bu videoya uzman bir cevap görmediyseniz
ragol

3
Programlama kariyerimin büyük bir kısmını UI'lar için tasarlıyorum ve bir keresinde bir müşterinin bir prototip UI'nin yazılımın 'neredeyse yapıldığı' anlamına geldiğini varsaydığımı varsaymıyorum. Müşteriler bir şekilde projenin neredeyse bittiğini düşünmekle karıştıysa, tel kafes UI'larının sunum yapanları gibi tel kafesleri açıklamak konusunda iyi bir iş yapmıyor gibi geliyor.
Graham,

2
Peçete L & F için +1. Bu kesinlikle benim geleceğimde olacak. :)
Kathy,

27

Şunlara bağlıdır: En önemli işlevsellik parçanızın etrafında sıkı bir geri bildirim döngüsü gerekir

Yaptığınız şeyin özü, riskli ve korkutucu kısım bir iç motor ise, o zaman çalışan kısmı konsolda veya ünite testlerinde söyleyin. Örneğin, bir protokol ayrıştırıcısının düzgün çalışıp çalışmadığını bilmek için bir UI'ye ihtiyacı yoktur.

Havalı şeyiniz herhangi bir etkileşimi içeriyorsa - etkileşimi sürekli olarak sorun gidermeniz, atmanız ve yeniden keşfetmeniz gerekir - o zaman UI-ilk yaklaşımı çok önemlidir. Örneğin, insanların veri görselleştirmesiyle etkileşime girmesini sağlamak için bir uygulama oluşturmak istiyorum. Çözmem gereken en önemli şey, görselleştirmenin anlamlı olup olmadığıdır, bu yüzden bir tanesine yerleşmeden önce yarım düzine yaklaşımı atacağım. Bunları tek bir birim testi yazmadan önce yapacağım.

Kodunuzu en iyi nasıl etkileyeceğiniz ve doğrulayacağınız konusunda en iyi kombinasyona karar vereceğiniz arasında bulanık gri bir alan var (otomatik testler? Deneme için kullanıcı arayüzü?). Kişisel olarak hem aşırı uçları hem de aradaki her şeyi yaptım ve bu spektrumda olması için doğru yere karar vermek, karar vermem gereken en zor şeylerden biri ve% 100 inşa ettiğim şeyin türüne bağlı.


2
Yani, aşılma ve / veya başarısızlık olasılığını azaltmak için önündeki en riskli ve en kritik bileşenleri tanımlayın ve ele alın. Bu bileşenler UI, işletme mantığı, vb ... veya büyük olasılıkla, tüm çeşitli bileşenlerin bir kombinasyonu olsun.
Alexander,

1
Bana prototip yapmaktan bahsediyor gibisiniz, çünkü hala tasarımları atıyorsanız, yinelemeniz gereken şey budur - gerçek kod değil.
Aarona

8

Çevik bir ortamda, "yürüyen iskeletler" veya "ince dikey dilimler" hakkındaki tartışmaları duyabilirsiniz. Çalışan yazılım, kullanıcı için önemli olan şey olduğu için, yazılımı çalışan bir parça halinde tek tek geliştirdiniz.

Bahsettiğiniz örnek uygulamada, pencere ve belki bir sekme ile başlayıp, hepsinin bir önden arkaya çalışmasını sağlayabilirsiniz. Sonra zamanla, işlevsellik eklersiniz ve bu nedenle duruma göre sekmeler yaparsınız, böylece her özelliği oluştururken çalışır hale getirirsiniz. Bu, sık sık müşteri gösterilerinin size sağladığı şeyin bir parçasıdır: yeni bir şeyler gösterme ve anında geri bildirim alma şansı.

Kısacası, evet, kullanıcı arabirimi çalışması, bir kullanıcı arabiriminiz varsa, kesinlikle bir işlevsel çalışma biriminin bir parçasıdır.

İşe yarayan küçük bir şeyle başlayın ve tam bir yazılım parçası sunmak için işlevselliğini arttırın.


+1 Daima bir şeyden çıkarılabilir bir parçaya sahip olmak önemlidir.
JensG

@Jens: "Daima bir şey taşıyabilecek bir parçaya sahip olmak önemlidir". En iyi ihtimalle, bu sadece az sayıda yazılım uygulamasına uygulanır. Gerçek dünyada ihtiyaç duyulan işin sadece bir kısmını yapan uygulamalar en ufak bir faydası olmaz.
Dunk,

Bu senin tecrübelerin. Benim de farklı olanlarım var. Çok sayıda kilometre taşından oluşan büyük, gerçek dünya projeleri ve gerçek müşteriler dahil.
JensG

1
@Dunk: İşin herhangi bir bölümünü yapmayan bir uygulama, işin bir bölümünü yapan bir uygulamadan daha az kullanışlıdır. Ancak, "yapılan" bir uygulamadan bahsetmiyorum; Ben bir uygulama inşa emri hakkında konuşuyorum. Tecrübelerim JensG ile uyumlu: her zaman o hafta neyi gösterdiğine bağlı olarak bir beta kesmek ve müşterilere hemen göndermek müşterileri çok daha mutlu ediyor.
Keith B,

Tanımlayabildiğim tek cevap bu. Diğerleri, iyi ürün geliştirme sürecinin "UI" ve "arka uç" olarak net bir şekilde dağılmaması ihtimalini düşünüyor gibi görünmüyor. Bu, yalnızca yeni başlayan bir programcının veya proje yöneticisinin soracağı bir soru ve deneyimli bir programcının ya da Başbakan'ın gerçek değeriyle cevap vermek için tenezzül etmesi gerektiği bir soru değil. Hangisinin “ilk yapılması gerektiğini” sorma fikri şelale kokuyor.
Aarona

3

Hem işlevselliğin hem de UI'nin bir karışımını yapmanızı (ve en kısa sürede geri bildirim alma veya test etme deneyimi) öneririm.

BTW, çoğu büyük GUI yazılımının geliştirildiği yol değil mi? Örneğin Firefox tarayıcısına bakınız: bir sürümden diğerine hem işlevsellik hem de kullanıcı arayüzü gelişti.


2

Üzerinde çalıştığım büyük (PHP web tabanlı) uygulamalarda, önce kukla değerleri veren sınıfları ve yöntemleri yerine getirmeye çalışıyorum . Bu, diğer devlerin kullanıcı arayüzünü uygulamak için kullanabilecekleri sözde bir sözleşme oluşturmaktır.

Bu yöntemin ikincil bir avantajı , tüm kod yazılmadan ve teslim edilmeden önce bile , UI gereksinimleri değiştikçe sözleşmeyi / arayüzü bilebiliriz (ve her zaman değişirler).


Bu yapmaya çalıştığım bir şey. Özel projem büyük bir UI kabuğu olarak uygulandığından ve her veri noktası toplayıcı bir eklenti olduğundan, her bir eklenti kendi UI bileşenlerini yönetmekten sorumludur. Bu şekilde, belirli bir kişi / grup için gerekli bir “sözleşme” yoktur. Varsayım, aynı insan grubunun belirli bir eklenti üzerinde çalışmaya başlayacağıdır. Olduğum gibi tasarladığımın bir parçası. Alternatif olarak, diğer projeler için bu mükemmel bir tavsiyedir. Bu yüzden benden başkalarına faydalı olacağı için benden daha fazla oy verin.
RobotHumans

2

Yapmaya meyilli olduğum şey berbat bir UI ile başlamak : sadece değişken verilerini ekrana döken bir şey. Yazı tipi yok, hizalama yok, aslında uzun süre grafiksel bir şey yok. Sadece "Hoşgeldin kullanıcısı x" ve "load pic" vb. Düğmeleri.

Geliştirme ilerledikçe, devam etmesi gereken daha fazla veya daha az şey bulabilirsiniz. Ancak bir aşamada, arka ucun tamamlanmaya yakın olduğuna karar vereceksiniz. Artık gereken tüm ekleri içeren bir UI'nız var ve tüm grafik işleri yapmak için çok zaman harcayabilirsiniz.

Ancak dikkatli olun, kusursuz değildir. Ortaya çıkan bazı sorunları görmek için biraz öngörmeniz gerekir. Örneğin, verileri mantıklı bir şekilde görüntülemek için UI bileşenlerini araştırmanız gerekebilir.


Ve müşteri metodolojinizde nerede devreye giriyor? Genellikle müşterinizin ne istediği hakkında çok genel bir fikri olduğunu unutmayın. Tam olarak ne istediklerini “onlardan nasıl çıkaracağınızı” bulmak ve sizin inşa etmenizi sağlamak size bağlıdır. Metodolojiniz, müşterinin istediğini düşündüğü şeyi oluşturdu, ancak bu nadiren müşterinin istediği gibi olacak. Yani sadece müşterinin istemediği bir şeyi kodlamakla zamanını boşa harcadın.
Dunk

Ah, "müşterilerim" hemen yanımda oturuyorlar ve bu alanda ne istendiği konusunda oldukça iyi bir fikir veren bir geçmişim var. Temel olarak, her zaman son ürüne, UI bilge yakın ve her zaman geri bildirim alabilirim. Uzun bir geri bildirim döngüsü olması sorununu düşünmemiştim. Etki alanı bilgisine sahip olmak anahtardır sanırım.
Carlos,

0

İyi bir kilometre taşı ve sorun takip sistemi kullanıyorsanız, bu sorunlardan bazılarını önleyebilirsiniz, çünkü bir bakışta yönetim ne kadar üretken olduğunuzu görebilir. % 80'inin arka ucu tamamladığını ve kullanıcı arayüzünün bir sonraki kilometre taşı olduğunu görebilecekler; Belirli bir özellik dönüm noktası için bitirmek üzere bir dizi kullanıcı arayüzü ve arka uç göreviniz olduğunu görebilecekler. Ancak her şey projenin gereklilikleriyle başlıyor ve Doug T'ın cevabı bir sistem tasarlamanın bu yönü hakkında bazı iyi noktaları ortaya koyuyor.


0

Kullanıcılarınız / müşteri bakış açınızla düşünün. Bir yazılım sistemi, bu kullanıcılara / müşterilere bir miktar değer kazandıran özellikler topluluğudur. Tabii ki bu özelliklerin her biri ve kullanıcı arayüzü, bir arka uç ve başka şeyler var.

Sisteminizi daima özelliklere göre oluşturun ve çok küçük özelliklere bölünmeyi deneyin. Bu yolla, müşterilerinize ulaştırmak için daha fazlasına her zaman yakınsınızdır, yazılım geliştirmenin 1.0 sürümünü oluşturmakla ilgili olmadığını, 1.0.1 sürümünün 1.0.2 sürümüne gitmediğini unutmayın.


0

Değişir. Gereksinimleriniz ne kadar iyi tanımlandı? Sistemin ne kadarı UI ile karşı karşıya?

Deneyimlerime göre çoğu müşteri, önünde bir şey görene kadar ne istediğini bilmiyor. Bu yüzden normal olarak, temel UI yönleriyle ilgili bazı tel çerçeveler sunarım veya kullanıcı arayüzünün çoğunluğunu (çalışma dışı) veririm. Bu, müşterinin, veritabanı tasarımı ve kod yapısı hala sadece tasarım aşamasında olduğu için özellikleri / işlevleri konusundaki fikrini değiştirmesine olanak tanır - tasarımı değiştirmek kolaydır. Projenin başlarında projeyi sonradan sonra değiştirmek daha kolay / hızlıdır.

Çevik devletler ayrıca ilk önce en zor ve en önemli eşyalar üzerinde çalışmanız gerektiğini belirtir. Hızlı başarısız . Bu yüzden, müşteri UI'yi gördükten sonra, ilk uygulanacak en önemli ve en zor olan konuşma olan, tamamen işlevsel olan küçük bileşenler oluşturmaya odaklanıyorum;

Daha sonra sprintleriniz var ve müşterinizle aynı anda hem kullanıcı arayüzü hem de işlevsel yönleri geliştiren sürekli iletişim kurarsınız.

Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.