Çevik bir çalışma sistemini değiştirirken nasıl çalışır?

İdeal bir Agile dünyasında, hızlı bir şekilde istenen son sistemin küçük ama kullanışlı bir alt kümesini oluşturur ve kullanıcılara verirsiniz. Heyecanlılar, çünkü faydalı, kullanmaya başlıyor ve geri bildirim veriyorlar. Daha sonra, üzerine ne ekleyeceğinizi, onu inşa edip zamanınız bitene kadar tekrarlayın.

Son zamanlarda bir tür çalışma sisteminin değiştirilmesini içeren birkaç projem oldu. Yukarıdaki model hiç işe yaramadı: mevcut sistemin neredeyse tüm işlevlerini içeren bir sistem inşa edene kadar, kullanıcıların hiçbir ilgisi yoktu. Kullanmazlardı.

"En küçük yararlı alt küme" "hepsi" olduğunda Agile'ı nasıl uygularsınız?

Çevik çözüm olabilir değil tek seferde her yerine, ancak yavaş yavaş içinde değiştirme faz.

Eski sistemin parçalarını çalışır durumda tutarak yeni sistemi yavaş yavaş, yavaş yavaş tanıtın. Eski sistem tek seferde kapatılmaz, sadece kaybolur. Yeni parçalar yeni işlevler veya başka avantajlar sağlar, böylece kullanıcılar bunları kullanmaktan memnun olurlar. Her zaman% 100 çalışma sisteminiz olduğundan, bu daha az risklidir.

• Martin Fowler'den daha fazla bilgi edinin .
• Michael Feather'ın Eski Kod ile Etkili Çalışma Stratejileri Yararlı Olabilir

Mevcut sistemi yeniden yazmak yerine (bahsettiğiniz gibi yeni sistem mevcut işlevsellikle eşleşmeden önce biraz çaba harcayacaktır), boğucu asma yaklaşımını düşünün . Temel olarak, mevcut uygulamanın üstünde yeni yaklaşımınızı kullanarak yeni işlevler uygularsınız . Sonunda, yeni işlevselliği ele almak için eski sistemin eksikliklerini giderdikçe, yeni kod eskisinin yerini alacaktır.

Bu, eski uygulamanın "yeniden başlatılmasından" daha fazla hassasiyet ve çaba gerektirir. Ancak YG'ye daha kısa bir zamanınız olur. Ayrıca, süreç boyunca, "yeni" sistemin bir sonraki "yeni" sistem tarafından daha kolay boğulmasını sağlamak için kancaları yerleştirebilirsiniz.

Dünyaya küçük artışlar bırakmak yeşil alan projeleri için işe yarayabilir, ancak o zaman bile az sayıda özellik çok yararlı olmayabilir.

Scrum, her sprintten sonra ürünün "Potansiyel Olarak Sevk Edilebilir" olduğunu savunur. Sevk edilmesi gerekmiyor, ancak sevk edilebilir bir ürün kalitesine sahip olması gerekiyor.

Kullanıcılara uygulamanın artımlı bir sürümünü vermek istiyorsanız, daha sonra Alpha olarak Beta'ya, ardından da hala gerçek Üretim uygulaması kullanılmaya devam ederken Aday sürümlerini serbest bırakabilirsiniz.

Kullanıcılardan geri bildirim eklerseniz yeni özelliklerin eklendiğini ve eski özelliklerin düştüğünü görebilirsiniz.

Büyük bir ulusal kablo tv ağı için büyük bir iş uygulaması yerine çalıştım. Yeni sistem geliştirme SCRUM ile yapıldı, neredeyse tüm büyük alt sistemleri yeniden uygulamak 18-24 aylık bir geliştirme projesiydi; 10 yaşına yaklaşıyordu.

Geliştirme başlamadan yaklaşık 6 ay önce bir planlama aşaması vardı, ama buna SCRUM olarak yaklaşıldı. Ürün sahibi, mevcut sistem analizi ve müşterilerle görüştükten sonra üst düzey mağazalar ve destanlar yazdı.

Mevcut sistem kritik bakım moduna geçtiğinden son derece kararlıydı; yalnızca durdurucu sorunlarının giderildiğini, her şeyin tarihsel amaçlarla kaydedildiğini ve aynı sorunların yeni sistemde görünmediğinden emin olmak için gösterin.

Yeni sistem Çevik bir süreçte tarif edildiği gibi gelişti, çoğunlukla son derece pürüzsüzdü. İkame sistemi özellik parçasına ulaştığında üretime geçmedi, paralel üretim denemelerine girdi. Kritik olmayan işçilerin bir alt kümesi , yeni sistemin eskisi gibi davrandığını doğrulamak için her iki sistemi de kullanmaya başladı ; tabii ki eski hatalar düzeltildi.

Yeni sistem neredeyse% 100 yeni özelliklere ulaştığında, birkaç ay süren genel paralel üretim çalışmaları için piyasaya sürüldü.

Müşteri, ihtiyaçlarını karşıladığında, eski sistem yedeklendi, kapatıldı ve oturdu. Eski sistem donanımını yeniden tasarladıklarını varsayıyorum çünkü kesildikten sonra eski sisteme geri dönmeleri gerekmiyordu.

Ben hala çevik bu senaryoda çok değer katıyor düşünüyorum.

Sadece 'mevcut sistemi değiştir' olarak tanımlanmış bir nihai hedefiniz var.

Çevik teknikler ve süreçler sizi daha etkili bir şekilde oraya götürebilir .

Örneğin:

Yine de sisteme yinelemeli ve küçük sprintler halinde teslim edebilirsiniz.

Kilit kişilerle iletişim kurduktan sonra çalışmaya öncelik vermek için çevik teknikler kullanmaya devam edebilirsiniz.

Yine de gözlemlenen hıza göre planlama yapmak için çevik kullanabilirsiniz.

Projenin kalitesini ve iç tasarımını geliştirmek için bilgi yayma, TDD, temiz kodlama gibi çevik teknikler ve felsefeler kullanmaya devam edebilirsiniz.

Projeyle gerçekten ilgilenmeyen ve mükemmel bir yer değiştirene kadar projeyle ilgilenmeyen insanlarınız varsa, şelale, çevik veya gerçekten herhangi bir işlem kullanıp kullanmadığınıza bakılmaksızın daha büyük bir probleminiz var.

Aynı şekilde çalışır, ancak bu yaklaşımın mevcut kullanıcılara satılması daha zor olacaktır. Yeni sistemi istemeyebilirler ve periyodik testlerle kesintiye uğramak istemezler. Mümkün olduğunca uzun süre beklemek ve daha sonra sonunda test etmek isterler. Çoğu kullanıcı belirli bir şekilde bu şekilde hissedebilir, ancak onları eğitmek sorumlu olanlara bağlıdır. Onların zihninde, mevcut bir uygulama ile çalışıyorsunuz, bu yüzden ne yapması gerektiğini bilmelisiniz, neden onları rahatsız ettiniz?

Onları bu şekilde yapmak istemediğinizi anlamalarını sağlayın çünkü eğlenceli olacağını ve bir şelale sürecini kullanarak yalnız kaldığınızı düşünüyorsunuz. Uzun vadede daha iyi bir uygulama yapacak.

Önemli bir satış noktası, bu değişikliği her zaman istedikleri yeni uygulamanın oluşturulması sırasında uygulamak, ancak eski sisteme asla girememek olabilir.

İşe gitmek için sürmem gereken eski bir paslanmış arabam varsa ve yeni bir araba satın almak için bayiye gidiyorum. İstediğim model stokta yok, bu yüzden fabrikadan sipariş etmek zorundalar ve gelmeden önce biraz zaman alacak.

Bayi daha sonra iyi niyetle, sipariş ettiğiniz araba gelene kadar size araba motor bloğu vermeye karar verir. Bir araba motoruyla ne yapmalısınız? Elbette test etmek ve çalışmasını sağlamak için bazı bileşenleri bağlayabilirim, ancak eski paslı arabanın yaptığı yerde yarın çalışmama gerçekten yardımcı olmuyor.

Bir araba inşa etmek ve özel yazılım oluşturmak arasında çok farklı bir ağlama var , ancak tartışma uğruna bunu görmezden gelelim. Hikayenin amacı, müşterinin işi şimdi yapmak için yeterince iyi bir yazılıma sahip olması durumunda müşterinin artan değişiklikler için hiçbir fayda bulamadığı konusunda şaşkına dönmemek. Şu an için ihtiyaçlarını zaten karşılıyor.

Bu, Agile'ın buradaki sürecin önemli bir parçası olmadığı anlamına gelmez, çünkü projenin durumu hakkında müşteriye sürekli geri bildirim yapılmasına izin verir. Önemli kilometre taşlarından ve teslimatlardan önce ilerleme kaydedilmesini sağlayabilirler. Düzeltilmesi çok maliyetli bir hata haline gelmeden önce olası sorunları ve sorunları daha erken belirleyebilirler.

Belki de araba müşterisi olarak, sadece tahmin ettiğiniz şeyi elde edeceğinizden emin olmak için motoru incelemek ve değerlendirmek istersiniz. Hata! Aslında 4 silindirli motor yerine 6 silindirli bir motor istedim! Bunu daha önce söylemedim mi? Sorun değil, fabrika siparişinde bir değişiklik yapalım.

Yeni yazılım sürümlerini henüz bir yedek olarak değil, değerlendirmek ve yoldaki her adımdan memnun olduklarından emin olmak için müşterilere en iyi çıkarlarının olduğu fikrini satmak.