Yinelenen gelişimi (çok daha az Çevik) anlamayan üst düzey bir yönetmenle sorunum var. Herhangi bir kod satırı yazılmadan önce yazılım tasarım şartnamemizin (SDS) eksiksiz olması konusunda ısrarcıdır. Komple, ona göre, tüm fonksiyonel detaylar oradadır. Ayrıca eski bir Cobol programcısı olan "modülleri" ve akış şemalarını görmek istiyor. Bu yüksek sesle ağlamak için bir Java web uygulaması!

Her neyse, kodlamaya başlamadan önce SDS'nin% 100 tamamlanması gerekmediğini göstermek için hafifçe işaret etmek için basit bir yer bulmaya çalışıyorum (ne de tamamlanmış olabilir). Herhangi bir öneri?

Teşekkürler!

Bir danışman olarak, basit bir danışmanlık kuralını anlıyorum:

• Yardım etmek istemeyen insanlara yardım edemezsiniz.

Sahip olmadığınız otorite gücü dışında hiç kimsenin yapmak istemediği hiçbir şeyi yapmasını sağlayamazsınız.

Bir koç olarak Agile'ı üç kuralla tanıştırıyorum:

1. Projenin başında tüm gereklilikleri toplamak imkansızdır.

2. Ne olursa olsun gereksinimleri yapmak değişikliği garanti edilir toplamak.

3. Zaman ve paranın izin vereceğinden çok daha fazlası yapılacaktır.

ve bir hedef:

• Her hafta değerli bir şey sunun.

Başlamak için tek ihtiyacınız olan bu.

Yöneticinizi ikna etmek başka bir şeydir.

Bir yöneticinin, bir geliştiricinin bunu anlamasını sağlayabildiğinden farklı bir şekilde çevik bir şekilde anlaşmasını sağlayamazsınız. Ona argümanları sunmanız gerekiyor (Kent Beck'in kitapları iyi bir başlangıçtır) ve kendi kararını vermesine izin verin.

Alternatif olarak, bir deneme yapmanıza izin vermesini isteyebilirsiniz. Küçük bir proje alın ve yinelemeli geliştirme ile çalıştırın ve zaman, bütçe, kalite sorunları ve ekip memnuniyeti konularında yakın sekmeler tutun. Önceki projelerle (veya sürümlerle) karşılaştırın ve daha iyi, daha kötü veya tarafsız olup olmadığını görün.

Yapmazsın

Her şeyden önce, Kıdemli Müdür neden yazılım geliştirme metodolojisinin seçimine dahil oluyor? Bu karar maaş derecesinin çok altında, mikro yönetimin şaplakları ve güvensizlik hacimleri hakkında konuşuyor.

İkincisi, neden onu anlaması gerekiyor? Yazılım özellikleri taşa sabitlenirse, tam olarak bir yineleme olacaktır. Eğer değilse, o zaman birden fazla yineleme olacaktır. Bu onun kararı değil .

Bunun onun kararı olduğunu düşünüyorsa, BT Yöneticisi, proje yöneticisi, BT mimarı, ekip liderleri ve geliştirme ekibinin otoritesini baltalıyor. Bu yüzden @ # $ ing ing yazılımını veya STFU'yu kendisi yazmalı ve profesyonellerin dinozor beyinleri tarafından işlenmemiş işlerini yapmasına izin vermelidir.

Şaka yapmıyorum. Eğer işini yapmana güvenemezse, bunu kendisi yapmalı ve çığlık atmalısın .

"Yazılım yapmak bir film yapmak gibidir, önceden planlama yapmanız gerekir, ancak çekim sırasında iyi bir sonuç elde etmek için yeniden çekim yapmanız, eski sahneleri tekrar ziyaret etmeniz ve nihai ürünü düzenlemeniz gerekir"

Sonra tekrar, o bir yönetici, yani sözleriyle:

"Tam zamanında tam hizmet çözümü oluşturmak için sinerjik esnekliğimizden faydalanmamız gerekiyor"

Eski deyiş geçerlidir: Atı suya götürebilirsin, ama içemezsin.

Diğerlerinin de belirttiği gibi, bu üst düzey yönetici için asıl önemli olan iş değeridir. Akış şemalarını ve modül diyagramlarını hazırlamak ve "tam" bir SDS (saçma bir kavram, ama ona ne istediğini vermek) yazmak için ne kadar zaman harcayacağınıza dair hızlı bir tahmin sağlamaya çalışabilirsiniz. Bu şeyler hakkında bir şey biliyorsam (ve yazılım yazmaya başladığımda, bu şekilde yapıldı), o zaman tahmininiz, büyük bir proje için daha fazla olmasa bile, birkaç adam hafta olacak. Bu rakamı para ile ifade edin.

O zaman ona aynı anda ne kadar işlevsellik sağlayabileceğinizi gösterin. İşletmedeki birkaç kişiyle, aynı zamanda teslim edebileceğiniz şeyleri yapan temel bir web uygulamasına sahip olmanın ne kadar zaman kazandıracağı hakkında konuşun. Daha sonra bu tasarrufları çoğaltın ancak 3 yıl içinde bu işlevi kullanırlar. Bunu para ile ifade edin.

Muhtemelen para ile ifade edilebilecek başka ticari faydalar da vardır. Benim favorim her zaman "goofball" önleme. Yazılımınız felaketleri en aza indirmeye veya bunları tamamen önlemeye yardımcı olabilirse, yakın tarihli bir felaketi bulun ve parayla ifade edin. Öyleyse patronunuza söyleyin: Eğer şimdi böyle olsaydık, bu parayı biriktirirdik.

Para hilesi işe yaramazsa, belki de ona doğru yürümeli ve ekibine mikro yönetimini durdurmasını söylemelidir. Deneyimlerime göre, bu, her şeyden daha kovulmanız daha olasıdır.

Basit yer Çevik Yazılım Geliştirme Manifestosu olabilir .

Bu yer hakkında bulduğunuz bilgiler, bir grup tanınmış profesyonel tarafından tanımlanan çevik yazılım geliştirmenin temel ilkeleri hakkındadır.

Yani

• Bireyler ve süreçler ve araçlar üzerindeki etkileşimler
• Kapsamlı belgeler üzerinde çalışan yazılımlar
• Sözleşme görüşmesi üzerinden müşteri işbirliği
• Bir planın ardından değişime tepki vermek

Ancak amacın tamamını öğrenmek için lütfen sayfaya detaylı bir şekilde göz atın.

Ona "Hızlı Prototipleme" (ilk birkaç yinelemeyi kodlamaya başlayarak) yaparak SDS'nizi daha hızlı ve doğru bir şekilde (daha sonra daha az yeniden çalışma anlamına gelir) ve daha önce iş değeri sunmaya başlayabileceğinizi göstermeye çalışmanızı öneririm. Gerçekten, büyük olasılıkla iş değeri bu yönetmen için önemli olan tek şeydir ve bunu başarmanın en iyi yolunun bu ardışık süreç yoluyla olduğuna karar vermiştir. Ona yaklaşımınızın neden daha iyi olduğunu göstermelisiniz.

Bu yardımcı olabilir - http://www.youtube.com/watch?v=4u5N00ApR_k

"Çevik bir proje yürütmek istiyorum" filminde, bu cesur proje lideri Luke'un deneyimlerini takip ediyoruz, çünkü işletme boyunca birçok farklı karşılaşması var, Agile projesini kurmak ve sunmak için çalışıyor.