Çok hızlı değişimin maliyetleri ile nasıl başa çıkıyorsunuz?


11

Çoğu modern geliştirici gibi, müşteri işbirliği ve değişime yanıt verme gibi Agile prensiplerine değer veriyorum, ancak bir ürün sahibi (veya gereksinimleri ve öncelikleri belirleyen) gereksinimleri ve öncelikleri çok sık değiştirdiğinde ne olur? Günde birkaç kez gibi mi?

Kısa bir süre önce buggy, eksik ve hatta olması gereken en basit senaryoyu ele alamayan ufacık bir kod tabanı miras aldım. Teknik konularla başa çıkabilirim ama bir gün birkaç e-posta, kısa mesaj veya telefon görüşmesi alıyorum. Daha da kötüsü, çoğu şeyin, yazılımın gerçekten yapması gerekenlerle bile ilgili olmayan ve yine de uygulanması günler süren küçük ayrıntılar olmasıdır. Sadece çok fazla zaman olduğunu ve önce en önemli şeylere odaklanmamız gerektiğini açıklamaya çalıştım, ancak bir şey bir iki gün sonra gerçekleştiği için çeviri sırasında bir şeyler kayboluyor gibi görünüyor.

Boşa harcanan miktarı azaltmama veya en azından bu kaotik davranışın maliyetlerini açıklamama yardımcı olabilecek bir tür Ürün Sahibi-İşleyici rolü, derinlemesine çalışma, metafor veya alıntı var mı?


Ekibiniz bir tür çevik metodolojiyi takip ediyor mu?
Aaron Kurtzhals

Çevikliğe benzediğimizi söyleyebilirim, ancak araçların (PivotalTracker, Jenkins, vb.) Ne empoze ettiği veya desteklediği dışında belirli bir çevik metodolojiyi takip etmeyin.
Trystan Spangler

Çevik gibi diyorsun, çevik diyebilirim; ama;)
Marcin Sanecki

Yanıtlar:


12

Biriktirme listesi bunun içindir. Yeni talepler biriktirme listesine alınır ve öncelikler yalnızca yineleme sınırlarında değişebilir. Ortalama bir haftalık gecikme (iki haftalık bir sprint'in yarısı), en korkunç acil durumların hepsini ele alacak kadar çeviktir.


5
Tek ve tek doğru cevap için +1. Nasıl dersiniz - "Bir yineleme başladıktan sonra değiştiremezsiniz." 'CANNOT' un hangi kısmını anlamıyorsunuz?
mattnz

Cevap ve mattnz'ın yorumuna +1 ("'CANNOT' un hangi bölümünü anlamıyorsunuz?"): Benzer bir sorunum vardı: üç hafta yineleme ve üçüncü hafta boyunca bir meslektaşım son derece yaratıcı ve değişmeye başlar / hareket ettirmek. Çeviklik çok fazla esneklik anlamına gelir, ancak bunun için daha düşük sınırlar vardır: bazı minimum iş birimlerini düzelttikten sonra dikkatiniz dağılmadan bunlara odaklanmalısınız.
Giorgio

İş birikiminin bunun için olduğunu kabul ediyorum, ancak, bırakılan / değiştirilen öğeler üzerinde çalışmaya başlamadığınız sürece, bir yinelemeden öğeleri bırakmanıza veya hatta eşit çabada öğeler için takas etmenize izin verilir .
Joshua Drake

Takımın , sprint ortasında yapılan değişikliklere izin verip vermemeyi seçebileceğini kabul ediyorum . Dışarıdan dayatılan çok fazla değişiklik, başlasanız da başlamasanız da yıkıcıdır. Ne kadarının "çok fazla" olduğuna karar vermek bireysel ekiplere bağlıdır. Bazen insanların resmi alabilmesi için bu sayıyı sıfır olarak ayarlamanız gerekir.
Karl Bielefeldt

9

Benzer bir problemle nasıl başa çıkacağım .. Agile'dan önce çevik olduğumuz günlerde.

Herhangi bir değişiklik talebi için müşteri önceliği belirler. Geliştirici, daha yüksek öncelikli bir görev üzerinde çalışmak için yalnızca bir görev üzerinde çalışmayı durdurabilir ve bırakmalıdır. Eşit öncelikli görevler varış sırasına göre programlardır. (Çalışma başladıktan sonra Görev Önceliği değiştirilemez.)

Müşteriye görevinde çalışamayacağınızı söylediğinizde acı çekecektir, çünkü en son isteği ile aynı önceliğe sahip önemsiz X görevi üzerinde çalışıyorsunuz. Daha sonra ona, bu öncelik düzeyinde, son talebinden önce 50 önemsiz ve önemsiz görev olduğunu söylersiniz. Şimdi gerçek yakalama - tüm bu görevler öncelik seviyesi 1'de (En Yüksek), tarafından ayarlandı ... HIM ... Böylece yaptığınız görevden kurtulamıyor. Şimdi, nadiren kullanılan yapılandırma seçeneğinde İzlandaca çeviride daha uzun kelimeye yer açmak için pencere çerçevesini 3 piksel sola taşımayı bitirdiğinizde .....

Ayrıca SD ofisinin kapısını kapattım, kilitledim ve telefonları çengelden çıkardım. E-postalar 10: 00, 12: 00 ve 14: 00'a kadar yok sayıldı. İnsanların düşündüklerine ve hissettiklerine rağmen, dünya hala güneşin etrafında dolaşıyordu, işimizi yaptık ve "Müşteriler", onlara geçmişte her zamankinden daha hızlı ve daha iyi yazılım teslim etti.

Önceliklerin daha gerçekçi bir şeye yerleşmesi birkaç hafta sürdü, kapının kilidini vb. Açabildik .... Ama sistem oldukça uzun bir süre kaldı. Bu kadar aşırı olmanıza gerek olmayabilir (yaptık) ve Üst yönetimin desteğine ihtiyacınız olacak. Ama işe yarayacak ....


+1 "Görev Önceliği çalışma başladıktan sonra değiştirilemez." Agile, bir geliştiricinin yalnızca üzerinde çalışmaya başlamadığı bir yinelemeden öğeleri bırakmasına izin verir.
Joshua Drake

Müşterinin önceliği belirleme fikrini seviyorum, zor kısım yasayı
koyuyor

2

SOP. Standart Çalışma Prosedürü (veya en azından yönetim ekibiniz tarafından imzalanmış gevşek bir protokol). Bölümünüzün bir tane geliştirmesi veya bir tane geliştirmek için yönetim ekibinizle birlikte çalışması gerekir. Konuşmanız gereken kişiler ürün sahibi / hesap yöneticisinin üzerindedir.

SÇP'nizin neyi tanımlayacağına dair bazı örnekler.

  • Bir müşteri veya dahili varlık bir değişiklik istediğinde hangi prosedürlere uyulması gerekir
  • Bu ürünün kalite kontrolü veya doğrulanması üzerindeki etkileri ve / veya etkileri nelerdir?
  • Teslimat için bir zaman çerçevesini makul bir şekilde belirleme yöntemi nedir? Bu yineleme? Sonraki sürüm mü?

Bu tür prosedürler olmadan, herkes zombi tarafından kovalanıyor ve ŞİMDİ ŞİMDİ ŞİMDİ bekle gibi koşacak. Böyle insanlar kibarınıza 'hayır' ya da 'lütfen beklemez. Sağlam bir politika uygulandığında, bu kod özlemli mutantlar, böyle gevşek bir temelde bir şey isterken yanlış olduklarını anlayacaklardır.

Sonuçta mutsuzsunuz ve bu sizin şirketinizin çıkarları için geçerli değil.

Bir yan notta, konumu ve görevi için böylesine bariz saygısızlıktan kaynaklanan bir karışıklığı miras almış olabilirsiniz. Bu durumda insanlar kaliteli ürün üretmekte zorlanıyorlar. Merak ediyor mu? Yazılım mühendisliği 101.


2

Bu "hazır, ateş, nişan al" koşulları altında çalışmak çok zordur. Bana çok güvensiz bir insandan gereksinimler alıyormuşsunuz gibi geliyor, daha yüksek bir insan kavramsal bir fikir önerdiğinde fikri değişiyor.

Bu tür durumlarda, e-postalara yanıt vermeden önce bir saat LEAST'ta beklemeyi değerli buldum. (Kısa mesaj, kuruluşunuz tarafından bir bütün olarak e-postanın yerini almadıkça, metinleri görmezden gelirim.) Onları okuyun, belki yanıt verin. Bu şekilde zamanınızı, yarın ilgisiz hale gelebilecek rastgele aciliyetlerin tartışmasına değil, hatta iki veya üç e-postaya odaklanarak yapmanız gereken gerçek işe odaklanarak geçirebilirsiniz. Son işimde, bir şey GERÇEKTEN acil olsaydı, e-postaları henüz görmediğimi varsayarak birileri gelip benimle konuşurdu (uzaktan çalışırsanız, gerçek bir iki yönlü konuşmaya sahip bir telefon görüşmesi olabilir. eşdeğer).

Yüz yüze veya telefon görüşmesi yaptığınızda, kişinin ne istediğini tekrarlamak ve ardından yeni gereksinimler ve öncelik hakkında sorularınızı sormak yararlı olacaktır. "Doğru anlarsam, Mevcut En öncelikli X üzerinde çalışmayı bırakmalı ve şimdi Dakika Y Önceliği'ne odaklanmalıyız diyorsunuz. Bu büyük bir değişiklik. İşteki değişikliği açıklayabilir misiniz? Daha fazla arka plan yapmam gerekebilir yalnızca kullanıcı arayüzünü değiştirmekten daha fazla. Faturalandırma veya envanter gibi diğer iş süreçlerinde değişiklikler olacak mı (örneğin)? Bu yeni veri öğelerinin tüm aylık raporlarda görünmesini bekleyecek misiniz? " "Bu yeni çabaya devam edersek, Mevcut En yüksek öncelikli X'in yayınlanmasını en az bir (hafta, ay,

Bu gerçek bir acil durum ise, talep eden kişi bu tür soruları cevaplayabilmeli veya sizi derhal yapabilen birine yönlendirebilmelidir. Bu gerçek bir acil durum değilse, bu tür bir konuşma, size daha fazla bilgi almaları gerektiğinden, istekte bulunanı yavaşlamaya ve değişikliğin ne kadar önemli olduğunu belirlemeye zorlar. Genellikle boruda olanın daha önemli olduğunu veya en azından durmaya değmeyeceğini görürler ve yeni istek listeye gidebilir.

Değişikliklerin gerekli olduğu belirlenirse, istenenleri ve bir e-postadaki değişiklikleri anladığınızı yazmanın ve değişikliği talep edip etmediklerini sorarak orijinal istekte bulunana göndermenin yararlı olduğunu gördüm, yine, açıklama olarak. Bu şekilde, neden En İyi Öncelik X üzerinde artık çalışmadığınız veya herhangi bir nedenin son teslim tarihlerinin neden gitmediğini açıklamanız gerektiğinde, ne yapılması gerektiğine ve neden talep edildiğine dair belgeler yazdınız. tanışmak.

Bilginizi gösterdiğinizden ve istedikleri şey üzerinde çalıştığınızdan emin olduğunuz için bu istekte bulunanla olan ilişkinizi geliştirmelidir, ancak değişiklik yapmak için gerekenlere karşı dürüst davranıyorsunuz. İsteği ayrıntılı olarak sorarak, ileriyi düşündüğünüzü görürler ve başlangıçta sahip olmadıkları şeyleri düşünürler.


0

Henüz kimseden bahsetmemiş gibi görünüyor, Sprint ve kullanıcı hikayeleri ideally should be locked till the next sprint(tipik sprint 2-4 hafta sürer). Kilitleme ile - yani, zaten başlamış olan Sprint'e hiçbir ek görev eklenmemelidir.

Kullanıcı hikayesi sprint'e sığmayacak kadar büyükse, sprint sırasında daha küçük, ulaşılabilir görevlere frenleyin. Ayrıca, belirtildiği gibi, öncelikli görevlerin bile biriktirme listesinde tutulması ve bir sonraki sprint planlama sırasında bayrağın kalkması durumunda yüksek öncelikli olması gerekir :)

Düzenleme: bahar boyunca sadece küçük değişiklikler yapılabilir. acil durum taşırlarsa. Ancak, sprint sırasında her zaman birkaç acil durum varsa, Sprint planlamasının kendisinde bir değişiklik yapılması gerekir.


0

Scrum, Scrum Master rolüne sahiptir, bu sizin bahsettiğiniz sorunları çözmesi gereken kişi olacaktır.

Sorumlu bir takım lideri, proje yöneticisi, scrum ustası vb. Biri varsa, o kişiyle konuşurdum.

Sadece çok fazla zamanın olduğunu ve önce en önemli şeylere odaklanmamız gerektiğini anlatmaya çalıştım, ama bir şey bir iki gün sonra gerçekleştiği için çeviri sırasında bir şeyler kayboluyor gibi görünüyor.

Bunu tekrar tekrar açıklamaya devam edeceğinizi düşünüyorum. Birlikte çalıştığınız bazı kişilerin yararsız alışkanlıklara sahip olduğunu kabul etmeniz gerekebilir. Şanslıysanız, sonunda bir değişiklik göreceksiniz.


0

Agile Manifesto , en temel ilkelerden birinin:

Değişen gereksinimlere hoş geldiniz, geliştirme aşamasında bile. Çevik süreçler, müşterinin rekabet avantajı için değişimi kullanır.

Ancak, günlük olarak değişmek istediklerine inanmıyorum. Bir ürünün taban fiyatını günde birçok kez değiştirmeniz gerekebilir, ancak bu ürünün günde birçok kez nasıl satılabileceğini değiştirmezsiniz. Aksine, bir ürünün satış iş akışı hafta bazında değişebilir (oldukça duyarlı ve dinamik işlerde).

Yine, bir ürünün satış iş akışı her hafta değişebilse de, genel ürünün her hafta değişmeyeceğini düşünüyorum. Bugün bize Office veren bir Microsoft düşünemiyorum, ancak yarın bize Offooose ve bir hafta sonra Offasooooooooooos verecek.

Hayır, çevikliğin değişimden kastettiği bu değil. Bunun kötü vizyonlardan ve değişim kavramının derinlemesine yanlış anlaşılmasından geldiğine inanıyorum.

Değişimin, geliştiricilerin mağaralarına gittikleri ve yaptıkları şeye konsantre olmaları gereken bir sprintte bahsetmediğini belirtmek isterim . Bunun yerine, değişiklikler Ürün İş Listesi'ne eklenmeli ve scrum ekibinin ellerine teslim edilmeden önce analiz edilmeli ve önceliklendirilmelidir. Başka bir deyişle, bir Sprint İş Listesi değişmez değildir. Doğrudan geliştirici odalarına günde birkaç kez değiştirilerek değil, daha kısa sprintler kullanılarak daha fazla çeviklik aranmalıdır.

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.