Hızlı prototipleme çevik bir metodolojiye nasıl uyum sağlar?

Çevik süreçlerin kullanımını belirleyen büyük bir şirkette çalışıyorum. Örneğin, projelerimiz için, özellikle çevik gelişimi yönetmeyi hedefleyen bulut tabanlı hizmetler kullanıyoruz.

Çalıştığım belirli mühendislik grubu geleneksel olarak yazılım geliştirmedi (bunun yerine projeleri çok daha fazla kuş bakışı bakış açısıyla yönlendirmeye yardımcı oluyoruz), ancak bu değişiyor. Çoğunlukla veri merkezli olan çok çeşitli yaklaşan / planlanan yazılım projelerimiz var - örneğin, veri izleme, toplama, toplama ve bazı raporlama yapacağız. Diğer görevler, özel donanım ve çeşitli istemci / sunucu (çok katmanlı) mimariler ile otomasyonu içerir. Birkaç kişiyi işe alma ve ilerlemede planlarımızın çoğunu formüle etme sürecine yardımcı olacağım.

Benim sorum, hızlı prototip (atma kodu) yapmanın çevik bir felsefeye uyup uymadığıdır. Örneğin, Python'u ve geniş paket yelpazesini seviyorum. Python tabanlı bir iş akışı ile birçok fikrimizi çok hızlı bir şekilde uygulama olasılığını görüyorum. Ancak, Python'un "kurumsal kalitede" olmadığı konusunda çok fazla algı olacağını ve bu çalışmanın çoğunun Java veya belki de C ++ ile yeniden yazılması gerektiğini düşünüyorum.

Bununla birlikte, Python prototiplerini oluşturmak, bize hızlı bir şekilde gerçek sonuçlar verebilmemizi sağlamak için paranızın karşılığını verir.

Hızlı bir prototiplemeyi - umarım Python'da - bir kurumsal ortamda sağlam bir çevik iş akışına dahil edebildiniz mi?

RAD'de amaçlandığı gibi "prototip" kavramı çevik gelişmeye biraz yabancıdır. Bu, yapılamayacağı anlamına gelmez, ancak olağandışıdır.

Araştırılması gereken farklı durumlar vardır:

1. Prototip, bir ürünün nasıl görüneceği hakkında bir fikir vermek için oluşturulmuş bir "boş kabuk", bir model veya bir demo mu? Kesinlikle bir veya daha fazla hikaye ile yapabilirsiniz - ancak gerçek geri bildirimlerden bir ürün inşa etmek değil, kendi hayal gücünüzden bir şey inşa ediyorsunuz. İnsanlar bir ürünü değerlendiriyormuş gibi bir demoyu değerlendirmez. Örneğin, üst çubuk prototipimiz ve gerçek üst çubuk uygulamamız hakkındaki geri bildirimlere bakın .

2. Prototip, problem alanını daha iyi anlamak için inşa edilmesi gereken bir şey mi? O zaman başak olarak ele alınmalı ve sadece sonuçları korunmalıdır (kaynak kodu geçicidir).

3. Prototip 0.x sürümü mü? Bir mininimum uygulanabilir bir ürün ? Sonra bunun için seçtiğiniz çevik süreci kullanın. Başka bir dilde yeniden oluşturmanız gerekirse, farklı bir ürünü tedavi ederseniz daha iyi durumda olursunuz. Bazen bunun bir özellik yazmanın kısayol yöntemi olarak ele alındığını unutmayın ("prototip ile aynı şeyi yapmalıdır!"). Bu, bir ürünü belgelemenin gerçekten kötü bir yoludur, ancak bu muhtemelen ayrı bir soru ve cevap olarak daha iyi açıklanabilir :-)

Is not hızlı prototip (yani iteratif ve artımlı geliştirme) tür Çevik bütün mesele?

Organizasyonunuzda "algı gerçektir" ile ilgili sorunlarınız olduğu anlaşılıyor. Herkese, Agile'ın "tüm planları atmak" anlamına gelmediğini hatırlatmak isteyebilirsiniz, Test Odaklı Gelişim'den "tüm mimariyi atmak" anlamına gelmekten daha fazlası.

Ve Python (eğer olsaydı) bir oyuncak dili değildir. NASA ve müteahhitleri Python kullanıyor ve eğer onlar için yeterince iyi ise, benim için yeterince iyi.

Extreme Programing'de Spike adı verilen oldukça istikrarlı bir uygulama var . Bu, bunun bir kod kodu olduğu anlamına gelir. İçinde özel bir şey yok. Beklenen sonucun atılabilir kod hakkında bilgi olduğu bir Sprint.

Yukarıdaki bağlantı, iyi uygulamalar, ani tuzaklar hakkında yeterli bilgiye sahiptir.

Özel kullanım durumunuz iyi bir örnek gibi görünüyor: arayüzü tasarlamak, yardımcı programı doğrulamak ve bazı kullanıcılara göstermek yararlı olabilir.

Kodu atacak ve üretime sokmayacaksınız (bunu HERKES'e mükemmel bir şekilde açıklayın), bu yüzden çevik olup olmamanız önemli değildir. Herhangi bir çevik uygulama prototipler için tamamen isteğe bağlıdır: sprintler, burn-down, test, çift programlama veya kullanmayı planladığınız başka herhangi bir şey.

Esas olarak, ürün sahiplerinin ve diğer karar vericilerin projeyi kavramsallaştırmasına yardımcı olmak için Python'da fonksiyonel modeller oluşturacaksanız, kurumsal kullanıma hazır olmanıza gerek yoktur. Ancak, kavram kanıtı oluşturuyorsanız veya belirli performans düzeyleriyle başa çıkıp çıkamayacağınızı görmeye çalışıyorsanız, muhtemelen üretim diline bağlı kalmalısınız. Bu Python'da deneyemeyeceğiniz anlamına gelmez.

Ne olursa olsun, kodu atacaksınız, ancak bu çalışmayı sahiplerin ne istediğini daha iyi anlayabilmeniz için yapabilme bilgisine sahip olacaksınız. Şimdi istediğiniz herhangi bir yöntemi kullanabilirsiniz.

Prototiplerin öğrenme için ve ayrıca Agile ruhunda çok önemli olduğunu ekliyorum. Prototip, özellikle daha hızlı geri bildirim döngüleri içinde öğrenmenize izin veriyorsa, devam edin. Her şey öğrenmeyi en üst düzeye çıkarmak ve öğrenmeleri ekiple paylaşmakla ilgilidir.

Öğrenme açısından, prototiplemenin sizi daha hızlı öğrenmeye götürdüğünü de eklerim. Bu şekilde, insanların çözmeye çalıştığınız sorunu umursadığını ve aklınızdaki çözümün aradıkları şey olup olmadığını doğrulayabilirsiniz - tam bir çözüm oluşturmak için çok fazla zaman kaybetmeden , sonunda, yeterince acı verici bir sorunu çözmemek veya doğru şekilde çözmemek.

Çevik'in gerçek ruhu etkileşim ve iletişim ile ilgilidir. Prototip, iletişime yardımcı olacak bir araç olarak iyi çalışırsa, Agile dünyasında kullanmak için yanlış bir şey olmadığını söyleyebilirim. Ekibimizde (5 yıldan fazla bir süredir Agile uyguluyoruz) zaman zaman kullandık. Ve bundan görebildiğim bazı faydalar var

1) Yardımcı iletişim

2) Kullanıcıları çözüm mülakatlarına alın ve erken geri bildirim alın

Uyarı:

UX ve mühendisler arasındaki doğrudan iletişim ASLA herhangi bir prototip yapay eserle değiştirilmemelidir. Mümkünse mühendisle eşleştirme, bir arabulucu (prototip) ile iletişim kurmaktan çok daha iyi çalışır.

Diğerleri zaten sivri uçların öğrenme amacından bahsetmiştir. Eksik olan, hızlı başarısız olan temel çevik prensibidir .

Çevik geliştirmedeki temel direklerden biri, sert kısımları tanımak ve kavramların kanıtını bulmak, bunu yapıp yapamayacağınıza bakın. Bazı "mantıksal" sırayla tüm görevlerin üstesinden gelmenin klasik yolu, projede geç bir şey yapamayacağınızı fark ederseniz gerçekten pahalı olabilir. Şimdiye kadar yapılan her şey bir atık olabilir.

Bu şekilde bitmesi gerekiyorsa, mümkün olduğunca çabuk bilmek istersiniz. Daha sonra paydaşlar, henüz çok fazla yanmamışken sadece para yakmayı bırakmayı ve istediklerinin uygun olmadığını kabul etmeyi veya yeni bir başarı şansı olacak soruna kökten farklı bir yaklaşım denemeyi seçebilirler. Prototipleriniz bu amaca hizmet ediyorsa, gerçekten de en çeviktirler.