Kötü yapılandırılmış bir yazılım geliştirme modelinin üstesinden nasıl gelebilirim?


11

Şu an şirkete katıldım, daha taze olarak çalışıyorum. CBS yazılım geliştirmedeki sınırlı sayıda kişi nedeniyle ve ben de onlardan biri olduğum için doğrudan Proje Yöneticisi olarak işe alındım.

Java ve CBS konusunda oldukça bilgiliydim ve lokasyon tabanlı hizmetler üzerine kendi kendini motive eden araştırmalar yaptım, ancak proje yönetimi ve yapılandırılmış yazılım geliştirme ile değil. Jeoloji özel bölümünden mezun olduğumdan bir yıl sonra geçtiğimiz yıl bir üniversitede akademisyen olarak çalışıyordum.

İş hayatımdaki ilgi sayesinde bir fırsat ortaya çıktı ve sonunda şirketin İş Zekası departmanından da sorumlu oldum. Şirket bana inandı. Kendim veri ambarı ve BI kavramlarını inceledim ve CBS'yi BI ile birleştirmede başarılı oldum.

Ayrıca şu anda iki geliştirici ile C # WPF'deki BI aracımız üzerinde çalışıyorum, burada da bir geliştirici rolünü oynuyorum (ki bu benim gibi).

Çevik proje yönetimi ile iyi yazılım geliştirme metodolojilerini benimsemek için çok uğraştım, ancak çok başarılı değildi. Ayrıca, bir ürünle ilgili olarak iyi tasarlanmış koda inanmama rağmen, CEO'mun sahip olduğu teknik bilgi eksikliğinden (doğrudan üstümde olan), normalde bunu yapmak için gereken süreyi alamıyorum. Geçen süre, bir bütün olarak belirli kodlama dilinde sahip olduğumuz uzmanlık eksikliğiyle büyük ölçüde artırılmıştır (örneğin, Java'ya karşı WPF). Ayrıca herhangi bir versiyon kontrol sistemi de mevcut değildir.

Yapılandırılmadığı için işlerin gidişatından son derece bıkmış durumdayım ve zamanımın çoğunun işleri nasıl yapılandırılacağı konusunda çalışmaktan daha çok düşündüğümü düşünüyorum. Umarım iyi bir profesyonel deneyime sahip sizler bu durumun üstesinden gelmeme yardımcı olabilirsiniz.


4
Zaten sahip olup olmadığınızdan emin değilim, ancak durumu yakın meslektaşlarınızla tartıştınız mı?
Fanatic23

Yanıtlar:


14

Yaklaşık iki yıl önce çalıştığım şirkette de benzer bir sorun yaşadık (teknik detaylar olmadan).

Her seferinde bir adım yapmanız yeterlidir. Hızlı bir şekilde çevik yazılım geliştirmeyi benimsemeye çalışmayın. Öğrenilecek ve uygulanacak çok şey var. Uzmanlık eksikliğinin sizi de aşağı çekmesine izin vermeyin.

Yavaşça ve kesin olarak yavaşça (ama olabildiğince hızlı: P) inşa edin.

Sonraki adımları tavsiye ederim (bunu yapmak için bir süre yönetimden gelişime geçebilirsiniz, ancak bu iyi olmalı)

  1. İyi bir sürüm kontrol sistemi öğrenin ve iyi öğrenin. Şahsen git veya mercurial tavsiye ederim. Her ikisinde de çok fazla belge var.
  2. Uygulamalar ve kalıplar üzerine sağlam bir çekirdek oluşturun . Ekip üyeleriyle kitap okuyun, bloglar okuyun, ekran görüntüleri izleyin. Bu gelişmeye yeni bir hava verecektir.
  3. TDD / BDD'yi öğrenin ve yeni kodda ve yeni bir özellik yaparken dokunabileceğiniz eski kodda uygulamayı deneyin .
  4. Do çifti programlama . İki kafa birinden daha iyi düşünür ve 4 göz 2'den daha iyidir :).
  5. Şu anda geliştirmekte olduğunuz dilin en son ve en yaygın kullanılan araçları hakkında bilgi edinin . Onlar hakkında bilgi edinin ve bazılarını projeye dahil etmeye çalışın. Bunların nasıl yapıldığını görün ve öğrenin.
  6. Scrum kullan . Yinelemeler, hikayeler, hikaye noktaları, engeller, aşina olmanız gereken kavramlardır. Scrum benim için yazılım geliştirme ve yönetimi için en iyi iş akışı olduğunu kanıtladı. Uygulayın ve her gün deneyimlerinden öğrenin.
  7. Örnek olarak öğretin . Yeni başlayan geliştiricilerin çoğu yeni şeyler öğrenmeye heveslidir, ancak bazıları çok tembeldir. Her neyse, onlara öğrendiğiniz ve uyguladığınız yeni şeyleri gösterin ve umarım bu onların beyinlerini gıdıklar.

Ayrıca, mümkünse, süreci kontrol edebilmesi ve daha iyi tavsiye verebilmesi için bir danışman kiralayın.

Tembel ya da cesaret kırmayın. Sadece hatalarınızdan ders alın ve farklı yaklaşımları deneyin. Bu sadece başlangıç!

Düzenle:

İşte son zamanlarda okuduğum / kullandığım bazı bağlantılar ve kitaplar ...

Öğrenme git: Pro Git

Bunlar tavsiye ederim blogların bazıları (çoğu .NET odaklı):

Kitaplar için Amazon'daki Buiding A Solid Programming Core listesini görebilirsiniz . Ayrıca bu tavsiye ederim:


@Edgar, çok teşekkür ederim. Havalı ve açıkladığınız şeyin benim için iyi çalışacağını düşünüyorum. Başka bir yol görmediğim için cevabınızı doğru olarak almanın ve körü körüne yapışmanın uygun olup olmadığını bana bildirin.
picmate

1
@picmate Elbette dostum, bu senin çağrın. Ayrıca, örnekleme yaparken, geliştiricilerin kaydettiği ilerlemeyi övdüğinizden emin olun.
Edgar Gonzalez

@Edgar, tabii ki. Kullanabileceğim iyi bir kaynak biliyorsanız, lütfen bunları yanıta verdiğiniz her noktaya da uygulayın (varsa). Ayrıca bu iyi bir geliştirme firması kendi yazılım geliştirme ile almak bu şekilde mi? (iyi bir geliştirme şirketinde olma şansım olmadı.)
picmate

1
@picmate her şeyden önce, bu adımlar ayrı ayrı uygulanmamalıdır. Birbirleriyle örtüşüyorlar, belirli bir sırada değiller (birincisi hariç). Günün ilerleyen saatlerinde bazı bağlantılar yayınlayacağım
Edgar Gonzalez

2
@picmate. CEO ne yaptığınız konusunda teknik bilgiye sahip olmadığından, bildikleriyle onu ikna edebilirsiniz. Örneğin, sürüm kontrolü varsa, iş kaybından kaçınabileceğinizi ve böylece kayıp kodu geri yüklemede gelir kaybını finansal olarak önleyebileceğinizi açıklayabilirsiniz veya en iyi geliştirme uygulamalarını öğrenerek, verimli ve böylece şirkete yardımcı olabilirsiniz. bir özellik geliştirme süresini kısaltır.
OnesimusUnbound

6

Yönetici olarak, bir projeyi düzgün bir şekilde tamamlamak için gereken zamanı elde etmek sizin işiniz . CEO'ya yaklaşırken, sizi destekleyen tüm rakamlara sahip olduğunuzdan ve tahminlerin neden bu kadar uzun olduklarından emin olun . Öyle sizin için yönetici olarak sorumluluk yapmak Tek gereken neden CEO'su anlamaya n belirli bir görevi tamamlamak için saat / gün / hafta. Bu bazen zor olabilir, ancak şirketinin henüz başarısız olmasını isteyen bir CEO ile tanışmadım ve eğer bu tür terimlerle (her şey başarısız olursa) ayarını değiştirirseniz bahsi değiştirebilir.

CEO size görevleri tamamlamanız için gereken zamanı vermek istemiyorsa, IMHO, başka bir işe geçmeye veya sürekli ölüm yürüyüşlerine hazırlanmaya hazır olun. Son çare olarak, CEO'ya şüphesiz gerçekçi olmayan beklentilerden gelecek olan tükenmişliği açıklayın.

Bunu söyledikten sonra , geliştiricilerinizin size doğru tahminler sunduğundan emin olmanız gerekir (muazzam derecede zor, uygun teknik tasarımlar yapılmadan neredeyse imkansızdır , bu da bir yerde olmalıdır).

Çevik tüm geliştirme alanlarında iyi değildir. Bazı proje türleri için çalışır, diğerlerinde sefil başarısız olur. Sen olanı bulmadan önce birkaç farklı metodolojiler denemek gerekebilir iyi .

Sürüm kontrolü ayarlarını yapın . Gerçekten, Git'i kurmak 5-10 dakika, temel işlemleri indirmek için birkaç dakika ve daha gelişmiş kavramları indirmek için bir veya iki gün okuma.


1

Hmm, Toronto'da bir Agile / XP etkinliğinde tanıştığımdan emin değilim - bu tanıdık geliyor

Ara vermeniz gerektiği anlaşılıyor. Uzun bir hafta sonu geçirin, isterseniz sarhoş olun ve birkaç gün çalışmayı unutun.

Kendinizi rahatlatın. Kendi kendine öğretme iyidir ve bir metodoloji ilgili kişiliklerle çalışmadığı için yanlış yaptığınız anlamına gelmez ve kişisel bir başarısızlık değildir.

Proje Yönetimini hedefleyen bir (beta) pm.stackexchange.com sitesi var, orada bazı yararlı tavsiyeler / destek alabilirsiniz - ancak elbette soruyu burada da saklayın.

Teknisyenlere geçelim:

mevcut sürüm kontrol sistemi yok

Birini en öncelikli konu olarak koyun. Git / mercurial yerine SVN (Subversion) gibi merkezi sistemleri tercih ediyorum, çünkü çalınan bir dizüstü bilgisayarın yerel olarak çok fazla geçmişi olmayacak. Özellikle gizli olan herhangi bir şeyin (şifreler ve ssh tuşları gibi) yanlışlıkla teslim edilmesi durumunda özellikle önemlidir. Ama bu bir zevk meselesi. Hiçbir şey 'manuel sürüm kontrolü' hatalarından daha fazla zaman kaybetmez - örneğin kodu düşündüğünüz şekilde geri koymak.

İyi şanslar


Merhaba, cevap için teşekkürler ve muhtemelen Toronto'da tanıştığın kişi ben değildim. Neredeyse bir buçuk yıldır bu görevdeyim. Sence hiç başarı olmadan zaman harcıyorum?
picmate

0

Birkaç sorununuz olduğu anlaşılıyor: 1. Geliştirme programınızı destekleyecek şekilde teknik olmayan bir üst yönetim ile iletişim kurmak; ve 2. Başarı için iyileştirme programını yürütmek.

1 numarasının en zor kısmı, üst yönetimin genellikle üzerinde çalıştığınız şeyin ayrıntılarıyla ilgilenmeyeceğini hatırlamaktır. (Eğer olsaydı, size teslim etmek yerine kendileri yapıyorlardı!) Büyük engel 'neden' gibi görünüyor ve bir süreç iyileştirmenin iş yararlarının açıklaması için CMM 1.1'e bakmak isteyebilirsiniz. programı. İşleminizi gerçekten geliştirmek için CMM veya başka bir şey kullansanız da, bu tartışmanın önemi yoktur, sadece daha olgun organizasyonların teslim süresinde daha az değişiklikle projeleri daha hızlı teslim ettiğini gösteren Carnegie-Mellon çalışmasının verileri.

Süreç iyileştirmede başarıya giden birçok yol var, hepsi çok uzun olma eğilimindedir. CMM ile ilgili deneyim, seviye 1'den 5'e geçmenin 8 ila 10 yıl alabileceğini göstermektedir. 6 sigma ile deneyim, her yinelemenin bir miktar iyileşme sağladığını, ancak potansiyel sorunların çoğunu ve 6 sigma kalite, her şeyi aynı anda değiştirme riskini almak zorunda kalmadan iş tamamen farklı bir şekilde yapılıyor.

Sektörünüzde yaygın olarak kullanılan bir kalite iyileştirme yaklaşımı varsa, yazılım için nasıl uygulandığını görmek için zaman ayırın ve şirketin geri kalanı zaten aşina oldukları ve destekledikleri bir şey hakkında işitmesini sağlayın. Belirli yazılım araçları ve uygulamaları hakkında saatlerce konuşabiliriz, ancak yazılım dışı CEO'lar bunu hızlı bir şekilde ayarlayacaktır. Endüstrinin standart uygulamaları hakkında konuşursanız, dilini anlarsınız çünkü dilini konuşuyorsunuz. Sektörün ortak terimlerindeki yazılımlar hakkında konuşun, zorluklarınızı ve şirketlerin sonuçlarını daha iyi hale getirme planlarınızı daha iyi anlamak için ilgili sorular sormaya başlayacaktır.

Bu şekilde her destek talebini kazanamayacaksınız, muhtemelen çok daha az boş görünüm ve daha fazla kazanç elde edeceksiniz!

İyi şanslar efendim!


0

Tüm önerileriniz gerçekten mantıklı ve birçok şirkete gitmenin yolu. Ama evrensel değiller, özellikle de deneyimli olmayan ekiplerle. Olmamalarının sebebi, birçoğunun herhangi bir yazılım projesi için masa bahisleri olduğunu varsaymak için - hatta sürüm kontrolü - kurmak ve korumak için bir miktar çalışma gerektirmesidir. Biraz çalışma gerektirdiklerinden, biraz da yarar sağlamaları gerekir. Ve sizin durumunuzda böyle olmuyor olabilir! Ya da en azından karar vermekle görevli insanlar fayda görmüyor!

Diğerlerinin işaret ettiği gibi:

  • Uygulamaları sırayla benimsemeyi deneyin. Hepsini aynı anda denemeyin çünkü insanları bunaltır.
  • Bunun için iyi bir sipariş bulmanız gerekiyor. Sürüm kontrolü ile başlardım. O zaman daha kolay olanlarla da gidin. İnsanlar iyi kararlar verdiğinize güvenmeye başladığında ve faydalarını gördüklerinde riskli değişiklikleri benimseme olasılıkları daha yüksek olacaktır.
  • Bir şeyin neden uygulanması gerektiğine dair sağlam bir durum oluşturun. Son kullanıcılar için sürekli ilerleme kaydeden 2-3 geliştirici ile, örneğin daha ayrıntılı bir geliştirme metodolojisi benimsemeyi haklı çıkarmak zor. Sonuç odaklı olmaktan ziyade süreç odaklı olarak görüleceksiniz.
  • Kimi ikna etmeniz gerektiğini unutmayın. Devs? CEO?
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.