Gerçek çevik geliştirme nedir? Alibaba kıdemli teknik uzmanları şirket içinde ve halka açık olarak paylaştı
Ali Mei'nin Kılavuzu: Özünde, çevik geliştirmenin önemli bir amacı, sürekli değer sunma yeteneğini oluşturmaktır. Bu yetenek nihayetinde iş yeniliğine hizmet etmeli ve iş başarısını teşvik etmelidir.
Bugün, Alibaba Bulut Verimliliği Platformu'nun çevik koçluk ekibinin başkanı ve kıdemli teknik uzman olan Bay He Mian, bizi çevik geliştirmenin hedefleri ve tanımlarından (bu makale Alibaba'nın dahili eğitim kurslarından alınmıştır) çevik Ar-Ge buzdağının ucunu keşfetmeye götürecek. ).
Çevik geliştirme iş hedefleri
Sık sık çevik modelden bahsediyoruz, ancak hangi geliştirme modeli Agile değildir? Evet, genellikle "şelale" nin çevik olmadığını söyleriz.
Şelale geliştirme modeli, geliştirmeyi gereksinimler, tasarım, geliştirme ve test etme gibi bir dizi aşamaya böler. Yukarıdaki resimde olduğu gibi, şelaleye benzediği için şelale geliştirme olarak adlandırılır. Soru şu ki, gereksinimlerin teslimi bu aşamalardan geçmek zorunda değil mi?
Şelale gelişiminin temel sorunu sahne değil, toplu iştir. Birlikte gruplar halinde tasarlamanız, ardından toplu geliştirme, toplu test, teslimat vb. Partinin nesi var? İlk olarak, parti değer teslimatını geciktirir, tüm gereksinimler son aşamada teslim edilebilir ve değer teslimi nispeten gecikir.
Değerin geç teslimi ne olacak? Bu resme bak. Soldaki, Intel'in kurucusu, Moore Yasası'nın yazarı Moore. Moore Yasası bize, 18 ay sonra, aynı parayla hesaplama gücü, depolama kapasitesi ve gofret sayısı gibi iki kat daha fazla şey satın alabileceğinizi söylüyor. Sağdaki de Google İcra Kurulu Başkanı Schmidt. Anti-Moore Yasası'nı önerdi ve şöyle dedi: "Bugünkü aynı şeyleri 18 ayda satabilirsek, gelirin ancak yarısını alabiliriz."
Anti-Moore Yasası, Moore Yasasının basit bir çıkarımıdır ve bize daha sonra verilen değerin daha düşük bir değer olduğunu söyler. Bu, donanım şirketleri için kritiktir ve hatta kader-teknolojik ilerlemelerinin Moore Yasasına ayak uydurması gerektiğini belirler, aksi takdirde kâr Moore Yasası tarafından yutulur ve ürün veya şirket ölür.
Yazılım veya İnternet hizmetleri ne olacak? 1990'larda IBM, bir donanım şirketi olamayacağını fark etti ve bunun yerine hizmet ve yazılım sektörlerine odaklandı ve iyi bir yaşamı vardı. Bununla birlikte, İnternet çağı çok geçmeden geldi ve yazılım ve hizmet sektörlerindeki yenilikler aniden hızlandı. Şu anda, donanım şirketleriyle karşılaştırıldığında, anti-Moore yasasının yazılım ve internet hizmet şirketlerinde oynadığı rol bundan daha fazladır.Zaman sadece değeri belirlemeyebilir, bazen tüm zaman aralığını kaçırabilir ve hiçbir şey elde edemezsiniz.
Anti-Moore Yasası bize daha sonra teslim edilen değerin de daha düşük değer olduğunu söyler. Yani yazılım geliştirme için şelale modeli değer dağıtımını geciktirir ve daha az değer alır. Şelale ile karşılaştırıldığında, yinelemeli teslimat öneriyoruz. Geliştirmeyi yinelemelere ayırıyoruz, her yineleme değerin bir parçasını sunuyor ve daha önce verilen değer genellikle daha fazla değer anlamına geliyor. Bu bağlamda, şelaleye göre yinelemenin özü, daha küçük partilerin daha hızlı teslim edilmesidir, böylece daha önce daha fazla değer elde edilebilir ve pazar rekabeti için fırsatlar elde edilebilir.
Yani çevik geliştirmenin ilk amacı, değeri daha hızlı sunmaktır Burada daha hızlı, mutlak hız değil, daha erken teslimattır.
İkinci nokta, bir koordinat haritasına bakalım.Bu koordinat, projenin zaman geçmişidir. En soldaki projenin başlangıcı ve en sağdaki projenin sonu. Ordinat, kullanıcının ne istediği, hangi ürün çözümünün benimsenmesi gerektiği, hangi işlevin yapılması gerektiği, hangi işbirliği biçimi, ne tür teknik çözümün seçileceği gibi takımın sahip olduğu proje ve ürün bilgisidir.
Ekibin (ürün ve aynı zamanda geliştirme ve iş dahil) ürünler ve projeler hakkında en fazla bilgi ve bilgiye ne zaman sahip olduğunu sormak isteriz? Proje bittiğinde herkesin cevapları tutarlıdır. Proje sürecinde, özellikle ürünü kullanıcıya teslim ettikten sonra bilgi biriktirdiğimiz aşikar, kullanıcı geribildirimi: "Bunu istemiyorum, söylediklerim net ...", şu anda ani bir bilgi artışı yaşıyorsunuz ve "Neden daha önce söylemedin?" Diye bağırdı. Süreçte iletişim sorunları olabilir, ancak kullanıcının şu anda sadece net olması veya ne istediğini açıklayabilmesi daha olasıdır.Ayrıca, başlangıçta kullanıcının kim olduğunu doğru bir şekilde tanımlayamayabiliriz bile. Ürün ve iş geliştirme, doğası gereği keşifsel bir süreçtir ve başlangıçtaki en cahil an olmalıdır.
Başka bir soru sorun. Projedeki kararların çoğu ne zaman alındı? Herkesin cevabı da proje başladığı anda çok net. Burada gömülü büyük bir paradoks var: En cahil bir anda, kararların en önemlisini ve çoğunu verdik ve bunu müteakip infazın temeli olarak kullandık. Belirsiz teknoloji ve pazar ortamları karşısında, geleneksel geliştirme modelleri gereksinimleri karşılayamadı ve paradoks daha belirgin hale geldi.
Bu paradoks için, çevik strateji yinelemektir. Başlangıçta, genel hedefin ne olduğu, genel stratejinin ve oyun tarzının ne olduğu, nereden başlayacağımız, nasıl kontrol edeceğimiz gibi bazı ilk kararları vereceğiz. Ancak bunlar yalnızca ilk kararlardır ve genel yönü tanımlar. Geliştirme süreci boyunca, gereksinimleri yinelemeli olarak sunar, pazar geri bildirimlerini ve en son bilgileri alırız ve bu geri bildirimlere ve bilgilere dayanarak ürün farkındalığını biriktirir ve gözden geçirir, aşamalı kararlar ve ayarlamalar yaparız.
Ürün geliştirme sürecinde teknik ortam, pazar ortamı, rekabetçi ürün stratejisi ve ekip algısı değişecektir. Değişen ortamla yüzleşirken, cehaletimizi kabul etmeli, geliştirme sürecinde aktif ve etkili bir şekilde öğrenmeli, geri bildirimleri sürekli olarak benimsemeli ve esnek bir şekilde ayarlamalıyız. Bu aynı zamanda Çevik'in ikinci iş hedefi, etkili öğrenme ve değişikliklere esnek yanıt.
Çevik geliştirmenin yukarıda bahsedilen iki iş hedefini birleştirerek, çevik geliştirmeyi tanımlayabiliriz. Çevik, değeri daha hızlı (daha erken) sunan ve daha etkili öğrenen ve esnek yanıt veren bir organizasyon yaratma yeteneğini ifade eder.
Yetenek perspektifinden bakıldığında, çevikliğin özü, sürekli olarak değer sağlama yeteneği ve sürekli teslimata dayalı olarak hızlı geri bildirim ve öğrenme becerisidir. Bu kabiliyete sahip olmak için, ürünlerin geliştirilme ve teslim edilme şeklinin temelden değiştirilmesi gerekiyor. Bu resim kavramsal olarak geleneksel toplu geliştirme yöntemlerinden çevik sürekli teslimat yöntemlerine dönüşümü somutlaştırıyor.
Geleneksel geliştirme yönteminde talep, teslimata kadar ürün, UED, geliştirme, test, operasyon vb. Partiler halinde çeşitli aşamalar ve organizasyonel departmanlardan akar.Her fonksiyon kendi işini optimize eder ve bir verimlilik şaftı oluşturur. Parti boyutu nedeniyle, bir sonraki aşamaya geçmeden önce tüm partinin tamamlanmasını beklemek gerekir. Tek bir talep perspektifinden, talebin çoğu bekleme durumundadır.
Yukarıdaki şeklin sağ yarısı bu süreci ifade etmektedir.Tek bir talebin fiili işlem süresi çok kısadır (şekildeki kesik çizginin üzerindeki kısa yeşil çizgi) ve çoğu bekleme durumundadır (şekildeki kesik çizginin altındaki uzun kırmızı çizgi). Sonunda, gerçek teslimat döngüsü çok uzundur.
Çevik uygulama yoluyla, tüm organizasyonun koordine edileceğini, daha yakın işbirliği yapacağını ve teslim süresini kısaltacağını umuyoruz. Resmin sol yarısı, çevik geliştirmenin temel hedeflerini içeren ideal bir çevik geliştirme modelidir - sürekli değer sunumu ve hızlı geri bildirim ve öğrenmenin temeli, sürekli değer sunumu.
Soru, sürekli değer sağlama yeteneklerini nasıl oluşturabilir ve geliştirebiliriz?
tanım
Yönetimin babası Drucker şöyle dedi: "Ölçemezseniz, geliştiremezsiniz." Aynı şey sürekli teslimat yetenekleri için de geçerlidir.
Etkili bir ölçüm sistemi, temel sorunlara odaklanmalıdır. Burada temel soru, ekibin sürekli değer sağlama kabiliyeti nedir? Bu soruyu cevaplamak için beş gösterge seti kullanacağız. Bunlar:
İlk: serbest bırakma yeteneği , İki alt bölüm göstergesi içeren, yani:
1) Serbest bırakma sıklığı, yani takımın ortalama gereksinimleri ne sıklıkla serbest bıraktığı. Ekibin mümkün olan maksimum yanıtını sınırlar;
2) Yayın teslim süresi, yani kodun sunulmasından işlevin başlatılmasına kadar geçen süre. Zaman maliyeti yüksekse, ekibin yayınların sıklığını artırması pek olası değildir.
İkincisi: talep yanıt döngüsü, İki alt bölüme ayrılmış gösterge içerir, yani:
1) Teslimat döngü süresi, yani kullanıcının talebi ileri sürdüğü ve talebin onaylandığı andan itibaren çevrimiçi hale gelene kadar geçen sürenin uzunluğu. Ekibin müşteri sorunlarına veya iş fırsatlarına genel yanıt hızını (iş, geliştirme ve operasyonlar gibi işlevler dahil) yansıtır;
2) Geliştirme döngüsü süresi: Geliştirme ekibinin gereksinimleri anladığı ve onayladığı andan, gereksinimlerin çevrimiçi hale gelebileceği zamana kadar geçen süre. Araştırma ve geliştirmenin duyarlılığını yansıtır.
Üçüncüsü: teslimatın iş hacmi oranı, Yani, birim zamanda teslim edilen gereksinimlerin sayısı.
Dördüncüsü: yerleşik kalite yetenekleri, Bu, tüm teslimat sürecinin kalitesidir. İki alt bölüme ayrılmış gösterge içerir, yani:
1) Geliştirme sürecindeki kusurların oluşma ve onarım süresinin dağılımı. Kusurların zamanında ve sürekli olarak keşfedilebileceğini ve keşiften sonra mümkün olan en kısa sürede onarılabileceğini umuyoruz;
2) Kusur envanteri, tüm geliştirme süreci boyunca kusurlu envanteri kontrol etmeyi umuyoruz, böylece ürün her zaman serbest bırakma durumuna yakın olur ve sürekli teslimat için temel oluşturur. Yerleşik kalite kapasitesinin özel ölçüm yöntemi daha sonra ayrıntılı olarak açıklanacaktır.
Beşinci: Dış teslimatın kalitesi. İki alt bölüme ayrılmış gösterge içerir, yani:
1) Birim zaman başına soru sayısı (çevrimiçi);
2) (Çevrimiçi) Sorunu çözmek için ortalama süre.
İyi bir ölçüm sistemi temel bir soruyu yanıtlamalı ve bunun için eksiksiz bir hikaye anlatmalıdır. Ekibin nasıl teslim edebileceği sorusuna cevap vermek için, yukarıdaki beş gösterge grubu, yanıt verme, verimlilik ve kalitenin üç yönünden tam bir hikaye sunar. Bunlar arasında, iki dizi gösterge, sürekli yayın kapasitesi ve talep yanıt döngüsü, değer akışının verimliliği olan yanıt verebilirliği yansıtır; bir gösterge olan teslimat hacmi, kaynakların çıktı verimliliği olan ekip verimliliğini yansıtır; yerleşik kalite İki gösterge grubu, kapasite ve harici teslimat kalitesi kalite göstergeleridir. Bu göstergelerin kombinasyonu, mevcut teslimat yeteneklerini, hedefle olan boşluğu ve iyileştirme fırsatlarını tam olarak anlamamızı sağlar.
Yukarıdakiler, ölçüm sisteminin genel tasarımıdır Ekibin yanıt verme yeteneğini ölçmek için döngü süresini temel gösterge olarak alıyoruz. Bu resim, iki döngü süresinin hesaplanmasını daha sezgisel olarak göstermektedir.Kanban iş akışına göre, müşteri döngü süresinin başlangıç noktası, talebin seçiminden talep yayınının sonuna kadardır; geliştirme döngüsü süresi, geliştirmeden başlar, Sürümün sonuna kadar.
Yukarıdaki metrik sisteme dayanarak, bu ölçümleri sunmak için ilgili grafikleri seçtik ve tasarladık. Aşağıda bazılarını tanıtıyoruz.
İlki, kümülatif akış grafiğidir. Kümülatif akış şeması, değer sunmak için ekip işbirliği sürecini yeniden üretir. Onun apsisi tarihtir ve ordinat, her aşamada tamamlanan kümülatif gereksinim sayısıdır. Soldan sağa doğru olan satırlar, her aşamada işlenen kümülatif ihtiyaç sayısını yansıtır. Örneğin: Şekildeki en üst satır, hazırlanmış gereksinimlerin sayısıdır, en alt satır, çevrimiçi olan gereksinimlerin sayısıdır ve orta satır, geliştirilen, tamamlanan, test edilen ve Test bitti ve böyle devam ediyor.
Kümülatif akış şeması, ortalama teslimat döngüsünü, devam eden ürün sayısını, varış ve teslimat oranını üç tür göstergeyi kapsamlı bir şekilde yansıtır.
İlk olarak: ortalama teslimat süresi. Teslim süresi, talebin yerine getirilmesinden önce baştan sona kadar geçen süreyi ifade eder. Şekilde, 26 Mart'ta toplam 40 gereksinim planlanmış ve 15 Mayıs'ta 40 gereksinim teslim edilmiştir. Talebin ilk giren ilk çıkar (ilk plan, ilk teslimat) kanununa uygun olduğu varsayıldığında, 40. talebin teslim süresi 15 Mayıs-26 Mart = 50 (gün) şeklindedir. Teslimat süresinden önce "ortalama" eklemenin nedeni, tüm gereksinimlerin ilk giren ilk çıkar olmamasıdır. Kümülatif akış şemasından, her aşamadaki teslimat süresinin dağılımını daha da görebiliriz.
İkincisi: devam eden çalışma sayısı. Devam Eden Çalışma, işlenmekte olan gereksinimlerin sayısını, yani başlatılmış ancak henüz tamamlanmayan gereksinimlerin sayısını ifade eder. Örneğin yukarıdaki şekilde 15 Nisan günü 61 kümülatif başlangıç talebi ve 8 kümülatif çevrimiçi talep var. Devam eden çalışma sayısı = 61-8 = 53 (birim), bunlar başladı, ancak henüz teslim edilmedi. Kümülatif akış şemasından, geliştirme aşamasında, test altında, test altında vb. Gibi çeşitli aşamalardaki süreç içi çalışmanın dağılımını daha da görebiliriz.
Üçüncüsü: Talep geliş ve teslimat oranı. Birim zamanda varış ve teslimat gereksinimlerinin sayısını ifade eder. Şekilde, 1 Mart'tan 30 Mart'a kadar, dört haftalık teslimat gereksinimlerinin sayısı 10'dan 50'ye çıkarıldı ve toplam 40 gereksinim teslim edildi: Geliş oranı = 40/4 = 10 (adet / hafta). 1 Nisan'dan 30 Nisan'a kadar, dört haftalık teslimat gereksinimlerinin sayısı 10'dan 30'a çıktı ve toplam 20 gereksinim teslim edildi: Geliş oranı = 20/4 = 5 (adet / hafta). Kümülatif akış diyagramından, farklı aşamaların çıktı oranlarını ve değişen eğilimlerini de görebiliriz.
Kümülatif akış şeması, ekibin gelişim modelini, gelişim trendini ve iyileştirme fırsatlarını yorumlayabileceğimiz ekip işbirliği ve teslim sürecini yeniden üretir. Örneğin: Şeklin üst tarafından parti planlama modunu görebilirsiniz ve Nisan ayından itibaren planlanan parti küçüldü, serbest bırakma sıklığı arttı, devam eden ilgili paralel iş sayısı da azaldı ve döngü süresi buna göre değişti. Daha kısa, teslimat verimliliği (teslimat hattının eğimi) da iyileşmiştir.
Ekibin kusurları tanıtma, keşfetme ve ortadan kaldırma davranışsal modelini yansıtan hata eğilim şeması olan başka bir grafiğe bakalım. Grafiğin apsisi tarihtir ve apsisin üstündeki kırmızı dikey çubuk o gün bulunan kusurların sayısını temsil eder; apsisin altındaki yeşil dikey çubuk, o gün çözülen kusurların sayısını temsil eder; turuncu eğri kusur envanterini temsil eder. Kusur eğilim çizelgesi aracılığıyla kullanıcılara rehberlik etmeyi umduğumuz davranış, kusur envanterini kontrol etmek, sistemin herhangi bir zamanda serbest bırakma durumuna yakın olmasını sağlamak ve sürekli teslimat için temel oluşturmak amacıyla kusurları sürekli ve erken bulmak ve zamanında ortadan kaldırmaktır. Yukarıdaki şeklin sol ve sağ kısımları, iki teslimat modu altında kusur eğilim grafiklerini karşılaştırır.
Sol kısım: "Yineleme" ekibinin ilk aşaması, kusurları ortaya çıkarmak için tasarım ve kodlamaya odaklandı, ancak anında entegrasyon ve doğrulama eksikliği nedeniyle kusurlar hemen keşfedilmedi. Projenin ilerleyen aşamalarında ekip entegre olmaya ve test etmeye başladı ve kusurlar ortaya çıktı. Kademeli model sürecinin kalitesizliği, birçok yeniden çalışma, gecikme, acele çalışma ve teslimat kalitesi sorunlarına yol açtı. Bu modda, ürünün teslim süresi, kusurun tam olarak ne zaman ortadan kaldırıldığına bağlıdır ve sürekli teslimat sağlanamaz, bu da ekibin dış müdahale kabiliyetini azaltır.
Doğru kısım: Tüm yineleme süreci boyunca ekip, birim olarak küçük taneli gereksinimleri geliştirir, entegre eder ve test eder ve sorunları hemen bulur ve çözer. Bu şekilde, kusur envanteri kontrol edilir ve sistem her zaman serbest bırakma durumuna yakındır, sürekli yayılmayı sağlar ve ekibin dış müdahale yeteneğini geliştirir. Kusur eğilim çizelgesi, ekibin gelişim ve teslimat modelini bir taraftan yansıtabilir, ekibin sürekli teslimat kapasitesini ölçebilir ve ekibi sürekli teslimata geçmesi için yönlendirebilir.
İyi bir ölçüm, temel bir soruyu yanıtlamalı ve eksiksiz bir hikaye anlatmalıdır. Yanıtladığımız soru, ekibin sürekli teslimat kapasitesi ve iyileştirme fırsatlarıydı ve bu sorun için eksiksiz bir hikaye anlattı. Bulut verimliliği proje alanının ölçüm sistemini yeniden yapılandırması da yukarıdaki sisteme dayanmaktadır. Yukarıdaki resim kavramsal bir örnektir, onu kullanabilirsiniz ve geri bildirimlerinize göre ölçüm sisteminin tasarımını optimize etmeye devam edeceğiz.
Ali iç paylaşım sahnesi
Konuk profili: Alibaba Bulut Verimliliği Platformu'nun çevik koçluk ekibi başkanı, kıdemli teknik uzman, Çin'deki yalın ürün geliştirmenin ilk uygulayıcılarından biri ve en çok satan "Yalın Ürün Geliştirme: İlkeler, Yöntemler ve Uygulama" kitabının yazarı Bay He Mian. Kuruluşların Ar-Ge verimliliğini artırmasına yardımcı olmak için yalın ürün teslimi, yalın girişimci inovasyon ve yalın ürün tasarımı alanlarına odaklanın. Alibaba'nın dahili iş birimleri, Huawei, Ping An Technology, China Merchants Bank ve birçok yeni şirketin yalın ürün geliştirme ve inovasyon yöntemlerini oluşturmasına veya tanıtmasına başarıyla yardımcı oldu.
