Geliştiricilere Proje Yönetimi yapan Yazılım Yöneticisi

Gömülü bir sistem şirketinde çalışan bir yazılım geliştiricisiyim. Genel proje çizelgesine (elektrik, kalite, yazılım ve üretim dahil) bakan bir Proje Yöneticimiz var, bu nedenle yazılım çizelgesi çok kısa.

Ayrıca patronum olan bir Yazılım Yöneticimiz var. Yazılım programını, tasarım belgelerini (yüksek ve düşük seviyeli tasarım), SRS'yi, değişim yönetimini, doğrulama planlarını ve raporlarını, sürüm yönetimini, incelemeleri ve elbette yazılımı yazmamı ve korumamı sağlıyor.

Tüm yazılım ekibi (10 üye) için sadece bir Test Mühendisimiz var ve herhangi bir zamanda birkaç proje devam ediyor.

Zamanımın% 80'ini bu belgeleri yapmak için harcıyorum. Patronum bir Süreç geçmişinden geliyor ve ihtiyacımız olan şeyin yazılımı geliştirmek için daha iyi belgeler olduğuna inanıyor:

1. Tasarımın çok önemli olduğunu düşünüyor, kodlama "sadece tasarımı yazıyor", çok uzun sürmemeli ve "donanım hazır olmadan önce tüm kodlar yazılmalıdır".
2. Dağıtılmış bir modelle işbirliği yapmanın daha kolay olduğunu söyledikten sonra bile, Merkezi ve Dağıtılmış Sürüm kontrolü arasındaki farkı anlamıyor.
3. Kodu anlamıyor ve her hatayı ve önerilen çözümünü anlamak istiyor.
4. Doğrulamanın geliştirici tarafından yapılması ve Test Cihazının doğrulanması gerektiğine inanmaktadır. Ancak, doğrulamamız yalnızca uygulamanın doğru olup olmadığını kontrol eder (birim testleri yazmayız, programda asla dikkate alınmaz) ve doğrulama kara kutu testidir, bu nedenle birim testleri eksiktir.

Gerçekten kafam karıştı.

1. Tüm bu belgelerin saklanmasından sorumlu muyum? Özünde Yazılım Proje Yönetimi'ni yaptığımı hissettiriyor. Teknik dokümantasyon konusunda iyiyim, ancak planlama / planlama geliştirici tarafından yapılmamalıdır.
2. Gerçekten belge oluşturmayı sevmiyorum, sorunları çözmek ve kod yazmak istiyorum. Deneyimlerime göre, tasarım belgeleri oluşturmak sadece bir dereceye kadar yardımcı olur, asla daha iyi veya daha hızlı kod için çözüm değildir.
3. Patronun daha iyi ürünler üretmeyi gerçekten umursamadığını, ancak yönetimin gözünde iyi bir yönetici olmakla ilgili olduğunu düşünüyorum.

Ne yapabilirim? Bu yıl 3 ay gerçek kodlama yaptım, geri kalanı sadece belge yapmak ve müşterilerden hata raporları beklemek için harcadım.

Bir Yazılım Mühendisi gibi konuşuyorsunuz.

Bir Proje Yöneticisi daha çok projenin durumu ve dönüm noktalarının yerine getirildiğinden emin olmak için kaynakları etkin bir şekilde tahsis etmeye odaklanır. Ayrıca engelleri kaldırır ve proje kaynaklarının belirli iş işlevlerine odaklanmasına yardımcı olurlar.

Tasarım ve teknik belgelerin yazılması ve bakımı, yazılım mühendisi olmanın önemli bir parçasıdır ve rolünüz için uygundur. Yine de çok iyi bir şey kötü olabilir (Bkz. Analiz Paralizi ).

Tasarımın çok önemli olduğunu düşünüyor, kodlama "sadece tasarımı yazıyor"

Proje yöneticisi tasarım belgelerinin çok önemli olduğunu düşünürse, bu süreçte belgelerin teslim edilebilir olmasını bekler. Zamanınızın% 80'ini buna ayıracak kadar önemli olduğunu düşünüyorsa, sizin tarafınızdan boşa harcanan bir zaman değildir.

çok uzun sürmemeli ve "donanım hazır olmadan tüm kodlar yazılmalıdır".

Bu, arzulu düşünme ve yazılım geliştirmenin nasıl çalıştığına dair oldukça eski bir Şelale tarzı görünümdür. Ne kadar tasarım ve hazırlık yaparsanız yapın asla değişmez. Bununla birlikte, bu notta, kodunuzun etkileşime girmesi için açık donanım özellikleri ve uygun test ortamları ve sahte donanım simülasyonlarına sahip olmalısınız, ancak yine de gerçek dünya dağınık.

Mükemmel bir dünyada proje yönetimi inanılmaz derecede kolaydır. Ancak ne kadar olmasını istediğinize bakılmaksızın dünya mükemmel değildir, bu nedenle gerçek proje yönetimini inanılmaz derecede zorlaştırır. Bu yüzden onlara büyük paralar ödeniyor.

(2) Merkezi ve Dağıtılmış Sürüm kontrolü arasındaki farkı anlamıyor.

Neden umursasın ki? Kilometre taşlarını nasıl etkiler? Öyle değil.

3) Kodu anlamıyor ve her hatayı ve önerilen çözümünü anlamak istiyor

Amacı çalışan yazılımlar içindir ve sizin de öyle olmalıdır. Kodu anlaması gerekmez, ancak çalışan yazılımı engelleyen sorunları anlaması gerekir. İkiniz bu temel seviyede gözünüzü gördükten sonra, karşılıklı hedefiniz birlikte daha etkili bir şekilde çalışmanıza yardımcı olacaktır.

(4) Doğrulamanın geliştirici tarafından yapılması ve Test Cihazının onaylanması gerektiğine inanır.

Bu düşüncede yanlış olan ne? Kalite güvence rolündeki test uzmanları, özelliklerin ve gereksinimlerin doğrulanmasıyla ilgilenmelidir. Geliştiriciler, teste başlamadan önce çalışmalarını doğrulamak ve test etmek için her türlü çabayı göstermelidir.

Gerçekten belge oluşturmayı sevmiyorum, sorunları çözmek ve kod yazmak istiyorum.

Basit bir programcı olmayı tercih ediyorsanız, belki de patronunuzla bu konuda konuşmalı ve projede sizin için daha iyi bir rol olup olmadığını görmelisiniz. Birisinin teknik belgeleri yazması ve bakımını yapması gerekir, bu nedenle belki de diğer geliştiricilerden biri bu görevlerin bazılarında size yardımcı olabilir, böylece belgelerinizi yazmak için zamanınızın% 80'ini harcamazsınız.

Deneyimlerime göre, tasarım belgeleri oluşturmak sadece bir dereceye kadar yardımcı olur, asla daha iyi veya daha hızlı kod için çözüm değildir.

Bu çoğunlukla doğrudur ... ancak on geliştiricinin tümü zamanlarının% 80'ini hiç kimsenin okumadıkları teknik belgeler yazarak geçiriyorsa. Bu, daha önce içinde yaşadığım muazzam bir yönetim karşıtı model. Takım için belgelerin çoğunu yaptığınızı fark ederseniz, daha fazla kodlama çalışması yapma hakkınız reddedildiğini söylemek adil görünmüyor.

Mesele şu ki, en iyi teknik dokümantasyon kodun kendisidir.

Patronun daha iyi ürünler üretmeyi gerçekten umursamadığını hissediyorum, ancak sadece yönetimin gözünde iyi bir yönetici olmakla ilgili

Onun hissediyorum yapar ürünün Mıntıka ve projeler ve özellikleri tamamlamamış ve istemciler mutlu değildir eğer o zaman üst yönetim çok umurumda da değil çünkü dikkat. Sorun, gerekli kalite iyileştirmeleri konusundaki bakış açınızın onun ve üst yönetimiyle uyuşmaması ve müşterilerin ne hissettiklerini algılamaları önemlidir.

Ürün için gerçekten neyin önemli olduğunu anlamaya çalışın, çünkü bir sürecin verimliliğini 3 kat artırabilirken, bunu yapmak için bir hafta geçirirseniz, müşterinin talep ettiği başka bir önemli özellik pahasına olur.

Hepimiz amirimizin gözlerine iyi bakmak istiyoruz. Bunda yanlış bir şey yok, kendi kendine hizmet etmek insan doğasıdır. Bu hayatın bir gerçeği.

Bir dereceye kadar proje yöneticinize katılıyorum. Yazılım geliştirme, kodlama özelliklerinin ötesine geçer. :-)

Durumunuz göz önüne alındığında, ona gidip isteklerinin zamanınızın% 80'ini aldığını açıklarım ve bu zamanı geliştirmekten (kodlamanın ötesine geçen) belgeleri korumak için harcamanın neden önemli olduğunu anlamaya çalışacağım.

Bir yazılım şirketi olan Atlassion , bir QA kişisi için 13 geliştiriciye sahiptir ve testlerin çoğu (planlama ve yürütme) geliştiriciler tarafından yapılır. Bunu Agile 2012'deki sunumlarından birinde öğrendim ve şu anda ekiplerimiz bu uygulamayı taklit etmeye çalışıyorum.

Bununla birlikte, tüm ekibi ileriye taşımak için bir metodoloji olarak Scrum'ı denemeye açık olup olmadığını proje yöneticinizle görüşürüm. Açıklamanız göz önüne alındığında, Scrum kullandığınızı sanmıyorum.

Senin gibi ben de sürekli değişen planları sürdürme konusunda son derece hayal kırıklığına uğradım ve Scrum hafif yaklaşımı bu hayal kırıklığını aşmama yardımcı oldu.

Deneyimlerime göre en yüksek performans gösteren takımlar, işlerini yapmak için gerekli olan en az işlemle karşılaşan takımlardır. Bir noktada ek süreç kaliteyi üründen almaya başlar. KG, evrakları yoldan çıkarmakla daha fazla ilgili oldukları için hataları özlemeye başlarsa ve DEV, belgeleri yazdığı için özellikleri kodlamaz veya hataları düzeltmezse, bir sorununuz vardır. Ancak, bu durumun şirketinizdeki durumun gerçekte olup olmadığını anlamak, yalnızca ekibinizdeki kişilerin bize (biz değil) cevap verebileceği oldukça yerel bir sorudur.

Patronunuzun çok yanlış olduğu bir şey var ve bu da çok az KG'ye sahip olduğunuz ve birim testleriniz olmadığı gerçeğidir. Adeveloper tarafından yaratılan bir hata, tanım gereği, onların adına bir gözetimdir. Geliştiricilerin her zaman kendi özelliklerini test etmelerini beklemek ve bunun dışında çok az test yapmak bir süreç problemidir. KG, alan adınıza bağlı olarak otomatik testle değiştirilebilir, ancak hiçbiriniz yoksa muhtemelen hataların geçmesine izin veriyorsunuzdur (ve genellikle bunları erken bulmaktan daha pahalıya mal olur).

Ayrıca, sıkı bir iş perspektifinden bakıldığında, KG'yi işe almak geliştiricileri işe almaktan daha ucuzdur. Takımların iyi bir KG / DEV oranı varsa, harcanan para için daha fazla zemin sağlayabileceksiniz.

Gördüğüm veya doğrudan duyduğum CMMI uygulamaları, süreç ve dokümantasyonun ağır olduğunu; patronlarınız, belgelerin uygulamayı önemsiz kılacak kadar ayrıntılı olması gerektiğine inanıyor ve beklentisinin benzer olduğunu ima ediyor.

Doküman yazma / bakımında orantısız bir pay alıyorsanız, daha eşit dağıtılmasını istemek mantıklıdır. Diğer geliştiriciler kodlama oranlarına benzer belgelere sahipse ve zamanınızın çoğunu kod yazarak geçirmek istiyorsanız; yeni bir işveren bulmanın zamanı gelmiş olabilir.

Tıbbi sistemlerden bahsediyorsunuz ... bu yüzden güvenlik çok önemlidir - bu nedenle dokümantasyon (özellikle izlenebilirlik) esastır.

Bir test cihazı biraz hafif görünüyor, ancak bunun dışında, evet - belgelerin yerinde olmasını sağlamaktan sorumlusunuz.

Tıp dünyasındaki deneyimim sınırlı, ancak havacılık / savunma dünyasında, gerekli belgeleri ve test düzeyini belirten bir yaşam döngüsü modeli (güvenlik kritikliğine bağlı olarak [daha spesifik olarak, yazılımın tasarım güvencesi düzeyi) ve otomotiv dünyasında da benzer şekilde ISO26262'ye sahibiz.

Dokümantasyon yerinde değilse, ürün sertifikalandırılmaz.

Ancak önemli olan, ürününüzü daha iyi hale getirmek için gerekli belgelerle çalışmaktır ... belgeleri bir düşünce olarak tersine çevirmeye çalışmayın çünkü o zaman gerçek dünya amacına hizmet etmez.