“Arıza Odaklı Gelişme” hakkında ne yapmalı?

Mağazamızda, çevik olmak için çalışıyoruz. Ve harika adımlar attığımızı söyleyebilirim. Bununla birlikte, bazılarımız "Arıza Odaklı Gelişme" olarak adlandırdığımız bir kalıp tespit etti.

Arıza Odaklı Gelişme, temel olarak böceklerin / özelliklerin kabul kriterleri olan görevler ve hikayeler tarafından değil, kusur izleme yazılımına girilen kusurlar tarafından yönlendirildiği çevik bir salınım / yineleme döngüsü olarak tanımlanabilir.

Ekibimiz, müşteriden / müşteriden kabul kriterleri almaya çalışan harika bir Proje Yöneticisine sahiptir, ancak her zaman mümkün değildir. Gelişim başkanımdan, bunun nedeni, müşterinin ne istediğini tam olarak bilmemesi ya da (ve bu hakarettir) müşterinin ana ofisinde iki farklı "kampın" bir hikayenin nasıl uygulanması gerektiği ile çatışmasından kaynaklanıyor. Camp A gevşek gibi o Özelliği X eserlerini dikte edecek bu , daha sonra Camp B dolayı böyle çalışmıyor onu başarısız olur o . Dolayısıyla, "FDD" terimi. Süreci "başarısız" ile tahrik edilir.

Bu benim soruma yol açıyor: Bir başkası bununla karşılaştı ve eğer öyleyse, onunla başa çıkmak için herhangi bir ipucu / öneri?

Elbette, A ve B Kampını önceden kararlaştırmaya çalıştık, ancak herkes bunun her zaman böyle olmadığını bilir.

Teşekkürler

Çılgınca çelişen gereksinimler şirket dünyasında sıradışı değildir. Ve bu genellikle iş süreci otomasyon projelerinin “başarısız” olmasının nedenidir. Gerçekten işi yapan insanlar Y yaparken "politika ve prosedürler kılavuzu X yapmak" kadar basit olabilir. Yazılımı Y yapmak perspektif. Yazılımı X yapmak, aslında işi yapan kişilerin işi tamamlayamayacakları anlamına gelir.

Normal olarak, çoğu geliştirme şirketi yöneticilerin işçilerin söylediklerine göre ne söyleyeceğini seçecektir, çünkü faturalar böyle ödenir. İdeal dünyada, yazılı ve gerçek politikalar arasında empedans uyumsuzluğu yoktur; Gerçek dünyada çoğu ofis işleri gayrı resmi olarak bölümlere ayrılmıştır ve belgelenmemiştir.

Kamp A, Özellik X'in bu şekilde çalışmasını kesin olarak belirleyecektir, ardından Kamp B böyle çalışmadığı için başarısız olacaktır.

CampA ve CampB arasındaki uyumsuzluk bir yazılım sorunu değil politik bir konudur. Sorunu çözmek, insanlarla konuşmak ve bir tane açık kazanan kazanmak anlamına gelecektir.

Yinelemeli gelişimi kullanmanın temel nedenlerinden biri, ne istediği hakkında iyi bir fikri olmayan bir müşteri grubuna sahip olmanızdır.

Bu başarısızlık değil. Birçok müşterinin elinde bir şey bulana kadar tam olarak neye ihtiyaçları olduğu hakkında bir fikri yoktur. Bu nedenle, müşterinin sistemi ilk kez tüm uyum ve bitimden sonra yapmaması gerektiğini gördüğü ilk kez onlar. Erken ve sık görsünler.

Başka bir deyişle, tek sorun buysa, sadece tekrar denemelerinizin olduğu bir durumda olmadıkça panik yapmanıza gerek yok.

Müşteri kuruluşu arasındaki anlaşmazlık sorunu, size sızmaması gereken bir Ürün Yöneticisi sorunudur. En çok görmeniz gerekenler, iş ilanları / görevler / her neyse. Elbette, Başbakan çoğu zaman gelişim alanına girecektir, çünkü onların yapabilecekleri tek yer burasıdır, ancak sizi etkilememelidir.

Nasıl yönetildiği, Kamp A ve Kamp B'nin kim olduğuna bağlı olacaktır.

Eğer A Kampı ve B Kampı iki üst seviyeyi temsil ediyorsa, size neye ihtiyacınız olduğunu söylemek için sistemi kullanacak birini getirin. Bazen yönetim arazisinde nadir bulunan hava ile gerçeğin kopmasına neden olabilirsiniz. Elinde olan bir kişi çoğu zaman idealizmi kesebilir ve gerçekte neye ihtiyaç duyulduğunu gösterebilir.

Öte yandan, eğer A ve B kullanıcı grupları ise, yasayı ortaya koymak için yönetimden birini almanın tersini kullanırsınız.

Her durumda, mükemmellik yeterince iyi olanın düşmanıdır.

Tarif ettiğiniz, Çevik'in tipik bir yanlış uygulamasıdır. Değişimi kucaklamıyorsun, sen onun kölesin .

Ürün sahibiniz var mı? Gerektiği gibi onlarla konuşabilir misiniz? Kullanıcılar ile sprint incelemesi yapıyor musunuz? Kullanıcılar sprint planlamasında sürece dahil oluyor mu (ürün sahibi aracılığıyla)? Ana ekipte test ekipleri var mı?

Çevik bir koç kiralamanızı ve / veya ekibinizi bir eğitime göndermenizi şiddetle tavsiye ederim.

Diğer bir çözüm ise Çevik yapmayı bırakmaktır.

Masa tenisi yapıyorlarsa (A, x yapar, B reddeder, Y diyor, sonra A reddeder ve x'e geri döner), ipuçlarını telafi etmek için ipuçlarının (PO ya da ne varsa) reddetmeleri gerekir. .

İlk gitmek onların ihtiyaçlarını karşılamamakla sonuçlanırsa sorun değil (tüm mesele onlara bakacakları bir şey vermek) ancak orada oturuyorlar ve sonraki yinelemelerde ileri geri sallanırlarsa asla başaramazsınız.

Buradaki problem "Gördüğümde bileceğim" gibi görünmüyor. Tel kafesler bu özel soruna yardımcı olabilir (bir noktaya kadar).

Buradaki sorun, bana öyle geliyor ki, müvekkilinizdeki iki rakip grup. İdeal olarak, A ve B kampları size sunabilecekleri müzakere edilmiş paylaşılan bir vizyon ile karşı karşıya kalacaktır.

Belki de, savaşta A'nın B için ne istediğini (ya da tam tersi) tekrar yaptığınız gibi, savaşta onlara ne kadara mal olacağını açıklamanızla masaya zorlanabilirler.

Zaman harcamanızla ilgili ayrıntılı notların tutulması burada yardımcı olacaktır. (Çalışmam hafif bir zamanlama uygulaması yazdı: kullanımı kolay ve raporlaması kolay ve 15 dakikalık parçalarda zamanı rapor ediyor. "N saatinde X özelliğini kullandım."

Bu, müşteriyi üzme veya kötü görünme riski altında olduğun anlamına gelir, çünkü B için yaptıklarınız A'yı (veya tam tersi) üzebilir.

Umarım müşteride sizin için mücadeleyle ilgilenebilecek bir şampiyon bulabilirsiniz.

Gördüğüm gibi, sorun müşterinin istediği yerde ancak zor olacak şekilde etkin bir şekilde çözülebilir.

Çevik için çabalıyorsunuzdan bahsediyorsunuz, bu yüzden onu en iyi tanıdığım çevik süreç olan scrum perspektifinden alıyorum.

Scrum'a göre, kullanıcı hikayelerini / hatalarını / sürümlerini vb. Önceliklendirmekten sorumlu olan ürün sahibinin belirli bir rolü vardır. Bu, ideal olarak sadece bir kişi olmalıdır. Aynı yazılım üzerinde farklı görüşleri olan ilgili taraflar varsa, ürünün ilgili tüm tarafları sağlaması, ürün sahibinin sorumluluğundadır.

Bana öyle geliyor ki proje yöneticinizin bu rolü var. Ancak, proje sahibi olarak adlandırılan ve bir ürün sahibi olmadığı için, diğer görevlerle de (geleneksel, çevik olmayan, yönetim görevleri?) Yüklendiğine ve sürdürmek için yeterli zamana sahip olmadığına inanmıştım. ürün sahibi rolü.

Dolayısıyla, müşterideki farklı ekipler arasındaki ihtiyaçları koordine etme sorumluluğu olan bir kişiye ihtiyaç duyduğuna ve geliştiricilere sunulan gereksinimlerin / kullanıcı öykülerinin müşterideki her iki ekip tarafından doğrulandığından emin olmanız gerektiğine inanıyorum. Bu rolü izlemek, özellikle sahip olduğunuz müşteriyle kolayca tam zamanlı bir iş olabilir.

Asıl ideal olan, bu sorumluluğu müşteriye taşımak, müşterinizin çalışanlarından birinin ürün sahibi rolü üstlenmesini sağlamak. Müşterinin bu rolü olmadığı sürece, müşteri kendi iç anlaşmazlıklarını çözme konusunda kararsızdır ve bunu çözmeniz için size büyük olasılıkla yapamayacağı şekilde bırakmaktadır. Bu nedenle, tek etkili çözümün müşteriye bu sorumluluğu vermek olduğuna inanıyorum.

Ancak, zaten bir işbirliği başlattığınız gerçeği göz önüne alındığında, bu değişikliği uygulamakta zorlanacağınıza inanıyorum.

Yazılımınızın müşteriniz tarafından kabul edilmesini sağlamak için, müşteri tarafından belirlenen şartları kabul kriterlerine göre yerine getirmesi gerekir.

Öyküler ve kabul kriterleri biçiminde bir dizi kullanıcı gereksiniminiz var, ancak müşteri organizasyonunun bazı bölümleri, belirsizliğe yol açan kullanıcı öykülerinin farklı yorumlarına sahip.

İşlevsel tasarımı ve uygulanan iş kurallarını tanımlayarak ve bunları müşteri tarafından imzalayarak bu durumdan kurtulabilirsiniz. Bunlar daha sonra kabul sırasında test edilecekler olacaktır. Daha sonra tüm dokümantasyonların anlamı hakkındaki tartışmaları önlemek için müşteri tarafından önceden kararlaştırılmalıdır.

Grubunuz, geliştirdiğiniz yazılımı her iki grubun da hemfikir olduğu şekilde tanımlayamadığı sürece, hala projenin gereksinim analizi aşamasındasınız demektir.

Proje yöneticiniz, işlevsel gereksinimlerdeki belirsizliği gidermek için projenin bir parçası olarak ücretli danışmanlık sunabilir / sunmalıdır.

Sanırım hepimiz, kullanıcıdan ayrıntılı gereksinimleri aldığımız, uyguladıkları, daha sonra "Bekle, bu benim için işe yaramaz" kullanıcısını duydukları durumu gördük.

Yardımcı olacak bir şey, beklenen sistem davranışı ile kullanıcıya ayrıntılı örnekler vererek, ihtiyaçlar üzerine bir KG formunu yapmaktır. Örneğin, şöyle diyebilirsiniz: "İşte örnek bir durum. Eğer X uygularsak, sonuç Y, sonuçlardan Z olur." Bu şekilde, sonra yerine kodu yazmadan önce "Bekle, bu işe yaramaz" olur.