Scrum ekibimiz her zamanki scrum rollerinden oluşur. Bir UI / UX tasarımcımız yok ve geliştiriciler UI / UX'i ürün sahibiyle çalışıyor. İşte bir sorun yatıyor. Her zaman biriktirme listesi oluşturmak üzereyken ve sprint başlangıcından önce tam UI / UX tasarımını tanımlamıyoruz sprint sırasında UI / UX tasarımını sonlandırmaya çalışırken çok fazla zaman harcıyoruz.

Bu, özelliklerin analizi ve mimarisi için tam olarak doğrudur. Sprint başlamadan önce bir özellik hakkında mümkün olan her detayın geliştiricilere verilmesi gerektiğini mi yoksa özellikler içinde bir görev mi olduğunu düşünüyorsunuz? Bunu deneyimledik ve herhangi bir kriteri olmayan bazı tanımlanmamış özellikler ile sonuçlanır.

İlk olarak: Bu hoş konuşmaya bir göz atın , Florian Haas FROSCON'a (GER) verdi. Scrum yapmanın pratik imkansızlığı ile ilgilidir.

İyi haber : saldırı olduğundan imkansız uygulamak için, ne istersen yapmak serbesttir.

Kötü haber : O scrum deme.

Bu sizi şu sorudan kurtarır: »Scrum doğru mu yapıyorum?« (Cevap: Hayır, yapmazsınız ) ve hayatın pratik sorunlarına devam edebilirsiniz, önemli.

Bir UI / UX tasarımcımız yok ve geliştiriciler UI / UX'i ürün sahibiyle çalışıyor

Bu nadir olmayan bir durumdur. Ancak AFAIR scrum uzmanlaşmaya karşıdır: herkes aynı beceri setine sahip olmalı ve birbirinin yerine çalışabilir.

Her zaman biriktirme listesi oluşturmak üzereyken ve ilkbaharın başlangıcından önce tam UI / UX tasarımını tanımlamayız.

Evet, şimdi bu durum çok iyi. »Kullanıcı olarak x « bilgisini görmek istiyorum gibi çok geniş biriktirme listeleriyle uğraşmak zorunda kaldığımız bir ekipte çalıştım ve hepsi buydu . Sonra öğe sürat tahtasına indi. Bir geliştirici aldı. Çözüldü. Uygulandıktan sonra, kullanıcı arayüzünün nasıl görünmesi gerektiği üzerine tartışmanın başladığı ilk akran değerlendirmesi yapıldı.

Ardından KG-Aşama geldi ve tartışma yeniden başladı.

Sprint'ten sonra, scrum , tasarımın PO tarafından parçalara ayrıldığı incelemeyi talep ettiği gibi yaptık . Ne yazık ki müşterimiz incelemelere yapmadı, bu yüzden yazılımı o noktada görmedi.

Ama sonra PO tatmin olana kadar döngü yeniden başladı .

Sonra müşteri geldi ...

Bu savaş hikayesinden , bu (özel tür) sürecin cehennemde etkisiz olduğunu görüyorsunuz.

Sonunda bizim için işe yarayan şey gemiye scrum atmaktı .

Ama bu sorunun çözümü değil;)

Sprint başlamadan önce bir özellik hakkında mümkün olan her detayın geliştiricilere verilmesi gerektiğini mi yoksa özellikler içinde bir görev mi olduğunu düşünüyorsunuz?

Bu ikileme bir çözüm, a) müşterinin kendisi ile PO arasında sıkı geribildirim döngüleri içerecektir , böylece kriterler nispeten sıkı formüle edilmiştir. b) Yoldan çıkma şansını en aza indirmek için scrum ekibi ve PO arasında sıkı bir geri bildirim döngüsü .

Bir backlogitem tanımlamak için bazı (daha fazla) scrum kurallarını kırardım: a »working dummy«. Bu, basit bir öğeye harcanan geliştirici süresini en aza indirmek için PO ve müşteri tarafından hızlı bir şekilde incelenebilir .

tl; Dr.

Scrum ekibinin girdisi ne olmalı?

Özellikleri mümkün olan en kısa sürede karşılamak için yeterli bilgi.

Konu dışı:

Artık scrum yapmıyoruz. Tahmin yapmıyoruz. Sprint tahtasını tuttuk. Sprint yapmayız. Özellikleri geliştirir / hataları düzeltir ve en kısa sürede yayınlarız. Yeni özellikler uygulandığında, en kısa sürede müşterileri ile daha fazla tasarım tartışabileceğimiz halka açık bir sunucuya giderler.

Standart cevap "sizin için uygun olanı yapın" dır.

Scrum çevik yöntemlerden biridir. Ekibinizi ve projenizi değiştirmek ve bunlara uyum sağlamak için açıkça tasarlanmıştır. Odak noktanız:

Süreçler ve araçlar üzerindeki bireyler ve etkileşimler
Kapsamlı belgeler üzerinde çalışan yazılım
Sözleşme müzakereleri üzerinde müşteri işbirliği
Bir planı takip ederek değişime tepki verme ( Çevik manifesto )

Bu, ekibinizin bir hikaye üzerinde neye başlaması gerektiğine dair bir soru değil , belirli bir ekibin belirli işletme ihtiyacını çözmesine hangi girdinin izin verdiğine dair bir soru.

Kişisel deneyimime göre, bu iş hedefine bağlıdır. Bazı hikayeler zaten UI / UX araştırması ve tam tasarımlarla geliyor ve sorun değil. Bazı hikayeler belirsiz gereksinimlerle birlikte gelir, çünkü işletmenin çözülmesi gereken bir soruna ihtiyacı vardır. Bu da sorun değil.

Elbette başka faktörler de var. Tasarımcılarınızın geliştirici ekibinin bir parçası olup olmadığı veya pazarlama veya ürün geliştirme gibi. İşletmeyi tatmin etmek, esnek olmak için gerekenleri yapın ve geçmişe dönük süreçleriniz sırasında bunları tartıştığınızdan emin olun, süreci gerektiği gibi ayarlayın.

Geliştiricilerden de benzer şekilde geri döndüm. Onların bakış açısından sorun, UX bölümünün ne kadar süre ile uygulanabileceğine karşı dikkatli olmalarıydı. Bir Sprint'te N hikayesi vermeye ve teslim etmeyi kabul ederlerse, ancak bazı hikayeler UX'de ileri geri gitmesi nedeniyle beklenenden çok daha uzun sürüyorsa, o zaman onlara kötü yansıdığını hissettiler.

Bizim için işe yarayan:

1. Birisi geliştirilecek ekranların maketlerini oluşturmak için ürün sahibi ile birlikte çalışır. Bunlar, hikayeye bir sprint haline gelmeden önce olağan hikaye iyileştirme sürecinde gözden geçirilir ve bu da herkese dürüst bir tartışma yapma şansı verir.
2. Kodlamadan önce tasarımı sonlandırmaya çalışmayın, sadece dışarı çıkın ve neyin değişmesi gerektiğine dair bir konuşma yapın. Değişiklik yapmanın maliyetleri daha netleşir ve bu da ürün sahibinin / müşterinin değerin olup olmadığına karar vermesine yardımcı olur.
3. Ürün sahibi / müşteriler ve geliştiriciler arasında güven. Sonunda herkes müşteriye bir şeyler teslim etmeye çalışıyor. PO'nun süratle her şeyi teslim etmemesi hakkında takımın inmesine izin verilmez. Geliştiriciler kasıtlı olarak engelleyici olamaz çünkü yayınlamama konusunda endişeli.
4. Uygulama. Öykü boyutlarını tahmin etmek ve olası sorunları tespit edebilmek için daha iyi bir tahminimiz var.

Tl; DR: Kodlamadan önce UX'i tam olarak tanımlamayın. Kullanıcılar görene kadar bekleyin ve onunla oynayın.

Sprint başlamadan önce bir özellik hakkında mümkün olan her detayın geliştiricilere verilmesi gerektiğini mi yoksa özellikler içinde bir görev mi olduğunu düşünüyorsunuz?

Basitçe söylemek gerekirse, ürün sahibi ui / ux tasarımını süratten önce teslim edemiyorsa, ui / ux'un gelişimi bir görev değil, bir hikaye olmalıdır .

Sprint çıktılarınız her zaman çalışma kodu olmak zorunda değildir ve takımın kendisi hikayedeki "kim" olabilir. "Geliştirme ekibinin bir üyesi olarak, kullanıcı arayüzünü uygulayabilmemiz için kullanıcı arayüzü modellerine ihtiyacımız var" gibi bir hikayeniz olabilir. Daha sonra mockupları teslim etmenin takımınızın ne kadar süreceğini tahmin edersiniz ve bu, üzerinde çalıştığınız ilk hikayelerden biri haline gelir.

Kullanıcı arayüzünü hecelemek zorunda değilsiniz, sadece işlevsel isteği (hikaye) kabul edin ve bir kullanıcı arayüzü hakkında düşünmeniz gerektiğini bilerek puan verin. İstemcinin kullanıcı arayüzünü belirtmesini sağlamak sorun istiyor.

Artık kullanıcı arayüzünün size daha iyi planlayabilmeniz için biraz zamana mal olacağını bildiğinize göre, UI çalışmasını içeren bir görevi bir dahaki sefere eklediğinizde buna ekstra hikaye noktaları atayacaksınız.

Scrum iseniz herkes bir UI / UX tasarımcısı olabilir.

UI / UX sonradan düşünülmemelidir. Bu bir çıktı olmalıdır. Ürün sahibi tarafından onaylanmalıdır. Teslimat sırasında sadece bir gif olsa bile görünmelidir.

Bu değişemeyeceği anlamına gelmez. Sık sık değişecek bir şey. Ayrıca erken geri bildirim almak istediğiniz bir şey. Kodun UI tasarımını kullanmasına izin vermeyin. Müşterinin sürmesine izin verin. Yalnızca müşteri sihir istediğinde geri itin. Aksi takdirde, istedikleri işin miktarı ve ne kadar tutacağı konusunda onları bilgilendirin.

Kesinleşmiş tek kullanıcı arayüzü / UX ölü yazılımda.

Yorumunuzdan:

"Ürününüzün sahibi tarafından onaylanması gerekir." Sorun tam da bu noktada ortaya çıkıyor. Bu onay sürecinde çok fazla zaman harcanıyor ve başlangıçta tahmin edilen birkaç saat yerine günler harcıyoruz. - Raşit

Seni gereksiz yere yavaşlatan her şeyi yok et.

Bir fikrin var. Ürün sahibine bildirin. Yanınızda oturuyor olmalılar.

Bundan nefret mi ediyorlar? Devam et. Sevdim? Yap. Anlamıyor musun? Göster onlara.

Kısa sık planlanmamış toplantılar. Konuşma. Bir beyaz tahta veya kağıt üzerinde doodle. Ekran görüntüleri kullanarak bir boya programında alay et. Fikirleri hızlı bir şekilde iletin, onaylayın, uygulayın ve gözden geçirin.

Ürün sahibi etrafta değilse, uygun bir insan alın ve onlara sorun. Tekrarlamaya başlamak için ne gerekiyorsa yapın. Ürün sahibini mümkün olan en kısa sürede tekrar takın.

Bir saniyenizi güzelleştirmek için harcamayın. Sadece konuya gel. Fikirlerinizi küçük ve artımlı tutun ve herkes tahmin bile etmeden yapılabilir.

Tecrübelerime göre:

• Çok az ön analiz, verimsiz, dur-kalk gelişimine neden olur
• Çok fazla ön analiz analiz felçlerine neden oluyor (Sprint asla başlamıyor)

Neler Yapıyoruz:

• Bazı " Geliştirmeye Hazır " ölçütlerini tanımlayın
• UX hikayeleri için bu, "ekip tarafından iyi anlaşılan bir tel kafesimiz var" olabilir.

Sprint planlama sırasında:

• Geliştirilmeye Hazır Olmayan Hikayeler atılır (ekibe çok rahatsız edici olur ve daha fazla analiz için geri döner)
• Herhangi bir sınır öyküsü "Yüksek Riskli" olarak ilan edilir ve Sprint'in başlangıcında üstlenilir
• İyi Anlaşılan Hikayeler Sprint'te tahmin edilir ve izin verilir

Bu sistem, her Sprint'in çoğunu yürütmeye adamamıza izin verir, yani çok daha verimli çalışırız.

Scrum'unuzdaki herhangi bir görevin, toplam çalışma için bir tahmini ve doğrulanabilir bir sonucu olmalıdır.

Scrum'ınıza "ürün yöneticisinin memnun olduğu bir kullanıcı arayüzü ile X özelliğini uygula" olarak bir görev koyarsam, bu doğrulanabilir bir sonuca sahiptir, ancak ilgili iş miktarını tahmin etmek imkansızdır. Yani bu görev yapamaz makul Hüngür konması.

Şimdi scrumunuza "X özelliği için bir kullanıcı arayüzü tasarlayın" diye bir görev koydum. Bu tahmin edilebilir ve sonuç doğrulanabilir. Bu bir scrum içinde Tamam bir görev. Görev tamamlandığında, bunu yaptınız.

Şimdi görev tamamlandığında, ürün yöneticiniz sonucu beğenmediğini söyleyebilir. Bu iyi. Scrum'da bir görev vardı, bunu yaptın ve bu senin işin. Bir sonraki scrum'a başka bir görev koyabilir. Belki biraz daha fazla yön ile aslında ne tür bir kullanıcı arayüzü isterdi. Bu onun işi. Yararlı sonuçlar veren görevler ayarlama . Bazen zordur ve işe yaramaz hale gelen işler yapılır. Bu yüzden buna "çevik" diyorlar; işe yaramaz hale gelen görevler yapılır ve daha sonra daha iyi bir yöne dönüşürsünüz.

Ayrıca, UX tasarımı, özellikle iyi UX tasarımı, UX tasarımı uygulayan biri için tam zamanlı bir iştir. Birçok iyi yazılım geliştiricisi, bir UX oluşturmak için başarılı bir iş yapabilir, ancak iyi bir UX tasarımcısı kadar iyi ve uygun maliyetli yapmazlar (eğer yapabilirlerse, UX tasarımları oluşturacak ve yazılım geliştirmeyeceklerdir). Bu yüzden UX tasarımcısı olmamak etkisizdir - yine ürün sahibi için bir sorun.

Çevik ilkeleri takip ettiğinizden emin değilim, ama işte bunun nasıl ele alınması gerektiği.

sprint başlangıcından önce tam UI / UX tasarımını tanımlamıyoruz

Amaç bu noktada mükemmel olmak değil. Geliştiriciler, sorulan sorulara olabildiğince yakın bir şeyler oluşturabilmeleri için gereksinimler için çok fazla girdi alın. Bir sürü ince ayar yapmayın veya istenmeyen şeyleri tasarlamaya çalışmayın. Zamanını boşa harcıyorsun.

sprint sırasında UI / UX tasarımını sonlandırmaya çalışırken çok fazla zaman harcıyoruz.

İşlerin ne zaman yapıldığını belirlemek için bir yol üzerinde çalışın. Bir hisim var, birisi UI / UX'in ileri geri değerlendirmesini yapmaya devam ediyor. Çok fazla insanın müşteriden varsayımlarını destekleyecek hiçbir şeyi olmayan UX / UI hakkında görüşleri vardır.

Manager: "I think this should be bold."
Programmer: "The client didn't ask for this"
Manager: "But I think they'll like it."

Bu tür şeyler sonsuza dek devam edebilir. Scrum kusuru değil. Birisi sprint sırasında gereklilikleri yerine getiriyor. Müşterinin ne istediğine karar vermeye geri dönün, ne kadar zaman alacağını belirleyin ve önceliklendirmek için onlarla birlikte çalışın. Çok uzun süreceğini düşünüyorlarsa, onlardan ne kurtulacağını sorun.

Logoları sabit bir ücret karşılığında tasarlayan bir şirket var. Değişiklik taleplerinin sayısını sınırlarlar, çünkü bazı müşterilerin tüm değişiklikleriyle bin kesintiden ölümle onları öldüreceğini biliyorlar. Durun veya daha fazla şarj edin. Buna iş denir.