Kısa bir süre önce bir geliştirme projesine katıldım ve aniden lider geliştirici işi verildi. Başlıca sorumluluğum, projenin programlama kısmını görevlere bölmek, bu işleri diğer geliştiricilere vermek ve ardından parçaların birlikte çalıştığından emin olmak.

Sorun şu ki, bunun nasıl yapılacağına dair hiçbir fikrim yok. Hafta sonumu bir kalem ve kağıtla anlamaya çalışarak geçirdim, ancak paralel olarak yerine sırayla üzerinde çalışılacak bir görev listesi ile geliyorum. Belki de özelliklere bölmeyi düşündüm ama sonra aynı dosyaları düzenlemeyi gerektiren görevlerle bitirdiniz, ki bu geliştirme aşamasında ne kadar erken olduğumuz için tüm görevin tamamen yeniden yazılmasını gerektirebilir. Bazı geliştiricilerin, program oluşturmak için biraz daha eksiksiz ve kolay hale gelinceye kadar beklemelerini sağlayabilirim, ancak daha sonra kaç hafta olduğunu bilenler için ellerinde oturan insanlar olur.

Patronumla bunun için niteliklerim hakkında konuştum ve bu konuda bir seçim yapmamıştım. Ne yaptığım hakkında hiçbir fikrim yok, bu yüzden doğru yönde herhangi bir ipucu ve dürtmek büyük memnuniyetle karşılanacaktır.

Sorunuza uygun bir cevap birkaç kitap doldurur . Bu konuda aklıma gelen bir kelimelerin bir mermi listesi ile geleceğim, Google ve kitaplar gerisini sizin için yapacak.

1. temeller

   • Yalnız gitme . Ekip arkadaşlarınızı mümkün olduğunca dahil etmeye çalışın.
   • Hafif seyahat edin .
   • Demokrasi, ama çok değil. Bazen, en çok sayıda insanı tatmin eden şey değil, en az sayıda insanı inciten şey değil.
   • Neyin (yapılması gerekiyor) ve nasıl (yapıldığı) ayrı tutulması .
   • Öğrenin Scrum ( "ne"), XP (Extreme Programming, "nasıl"), Kanban ( "ne kadar"), Yalın ( "ne değildir") ve DevOps ( "kiminle").
   • Yalın da akışla ilgilidir : Genel verim için akış verimi genellikle bireysel verimden daha önemlidir.
   • Yazılım İşçiliği , Temiz Kod ve Pragmatik Programlama hakkında bilgi edinin .
   • İyi mimari, alınmayan kararların sayısını maksimize etmekle ilgilidir .
   • Scrum / XP / Lean / Agile, yapılmayan iş miktarını en üst düzeye çıkarmakla ilgilidir : YAGNI .
   • Yazılımın İlköğretim Değeri sen olmasıdır kolayca değiştirebilir bunu. Yapması gerekeni yapması önemlidir, ancak bu yalnızca İkincil Değeridir.
   • Yinelemeli ve artımlı bir yaklaşım tercih edin , hemen hemen her şey için zaman kutularını kullanın , özellikle toplantılar yapın, Parkinson Yasasını arkadaşınız yapın, çünkü Hofstadter Yasası geçerlidir.
   • Conway Yasası ve Tuckman'ın Takım Geliştirme Aşamaları anlayışı ile takım yapısını dengeleyin .
   • Programlama dörtlüdür, aynı anda bilim , mühendislik , sanat ve zanaattır ve bunların dengede olmaları gerekir.
   • Sadece Scrum / XP / XYZ'in birileri için iyi olması (benim dahil) mutlaka sizin için iyi bir şey olduğu anlamına gelmiyor / ortamınıza uygun. Hype'ı körü körüne takip etme, önce anla.
   • Denetleyin ve Uyarlayın! (Scrum Mantra)
   • Çoğaltmadan Kaçının - Bir Kez ve Sadece Bir Kez! (XP Mantra) aka KURU - Kendini Tekrar Etme aka SPOT - Tek Nokta Gerçeği

2. "Hangi dünya" iş analizi süreci

   • Gereksinimleri Kullanıcı Öyküleri / İş Öyküleri olarak Ürün İş Listesi olarak toplayın .
   • Kullanıcı benzer (Kullanıcı Story) Erkek Oyuncu (UML) benzer Persona benzer Role .
   • INVEST (Bağımsız, Pazarlık, Değerli, Tahmini, Küçük, Test Edilebilir) bazlı ekibinizin Hazır Tanımını karşılayana kadar Kullanıcı Öykülerini geliştirin . (Scrum Toplantısı: İş Artırma )
   • Ürün İş Listesini İş Değerine göre sıralayın .
   • Hazır olana kadar bir Hikaye üzerinde çalışmaya başlamayın (hazırın tanımına göre hazır).
   • Hikaye Puanlarındaki Hikayelerin çabalarını tahmin etmek için Planning Poker'i kullanın . Tahminlerin tutarlılığını sağlamak için üçgenleme karşılaştırmasını kullanın .
   • Dünkü hava en iyi tahmin, umarım en kötüsüdür.
   • Çok büyüklerse Hikayeleri Böl .
   • Tamamlanan bir Tanım ile dağıtım kültürünü geliştirin .
   • Bir Kullanıcı Hikayesi'nin Bittiğinden (Bitti'nin Tanımı'na göre) uygulanmasını kabul etmeyin .
   • Aynı kod tabanındaki birden fazla ekip aynı Bitti Tanımını (özellikle Kodlama Standartları ) hemfikir ve paylaşmalıdır .
   • Burndown Charts ile gelişiminizi kontrol edin .
   • Ekibin ne sunduğunun gerçekten gerekli olup olmadığını düzenli olarak Paydaşlarınızla kontrol edin. (Scrum Toplantısı: Sprint İnceleme )

3. Öykü Dağılımı

   • Kullanıcıları / Personeleri / Aktörleri / Rolleri Listeleme ve Açıklama (Ürün Sahibi)
   • Epic -> Hikayeler (Kullanıcı Hikayesi veya İş Hikayesi) (Ürün Sahibi)
   • Öykü -> Kabul Kriterleri (Ürün Sahibi)
   • Öykü -> Alt Görevler (Dev Team)
   • Kabul Kriterleri -> Kabul Testleri (Spesifikasyon: Ürün Sahibi, Uygulama: Geliştirme Ekibi)
   • Minimalist bir Baştan Sona (Half-End) olan bir Yürüyüş İskeleti ile başlayın .
   • MVP - Minimum Uygulanabilir Bir Ürün Yaratın .
   • MVP'yi SMURFS - Özel Olarak Pazarlanabilir, Faydalı, Serbest Bırakılabilir Özellik Kümeleri kullanarak genişletin .

4. "Nasıl dünya" gerçeği

   • Kullanım OOA / D , UML ve CRC Kartlar , ancak kaçının büyük tasarım ayarlıyoruz .
   • Uygulamak nesne yönelimli , yapılandırılmış ve işlevsel bağımsız programlama dili, mümkün olduğunca aynı zamanda.
   • Sürüm Kontrolü'nü kullanın (tercihen dağıtılmış ).
   • Kabul Testleri ile başlayın .
   • Uygula TDD icar, TDD üç Yasaları yoluyla sürücüye Eğer Kırmızı-Yeşil-Elden Geçirme-Döngüsü ile, Tek belirt-Kural , 4 A'lar , GWT (Zaman Sonra Verilen) den BDD .
   • " Birim Testleri olan hızlı koşmak testler ." - Michael Tüyler
   • Kuplaj ve Uyum özelliğini yönetmek için SOLID ve paket ilkelerini uygulayın . Örnek: SOLID'deki S, SRP = Tek Sorumluluk Prensibidir, düzenleme sayısını önemli ölçüde azaltır. takımlarda birleştirme çatışmaları.
   • Bilin Demeter Yasasını / söyle, Do not Ask .
   • Devamlı Teslimat (DevOps) bile uygulanabilirse, Sürekli Entegrasyon kullanın .
   • Kararlaştırılmış ortak bir Kodlama Standardı'na ( Tamamlanan Tanımın bir parçası olması gereken) dayanan Toplu Kod Sahipliğini kullanın .
   • Uygula Sürekli Tasarım Improvement (fka Sürekli Refactoring).
   • Kaynak Kodu Tasarımdır . Yine de açık bir düşünce vazgeçilmezdir ve hiç kimse birkaç açıklayıcı UML diyagramına itiraz etmeyecektir.
   • XP, hiçbir günün mimari gün olmadığı, her günün mimari gün olduğu anlamına gelmez. Bu bir odaklanma değil, mimariye odaklanmadır ve odak koddadır.
   • Teknik Borçlarınızı düşük tutun , dört tasarımın Kırılganlık , Sertlik , Hareketsizlik ve Viskozite kokuyorlarından kaçının .
   • Mimarlık, kalıcılık ve teslim mekanizmalarıyla değil, iş mantığıyla da ilgilidir.
   • Mimarlık bir takım sporudur ( Mimarlıkta 'Ben' yoktur ).
   • Tasarım Desenleri , Yeniden Düzenleme ve Dönüşüm Önceliği öncül .
   • Proje Kodu öncelikleri olan ATP-Trinity'dir : 1. Otomasyon Kodu , 2. Test Kodu , 3. Üretim Kodu .
   • Takımın ne şekilde geliştirilebileceğinin iyileştirilip geliştirilemeyeceğini düzenli olarak ekip arkadaşlarınızla kontrol edin. (Scrum Toplantısı: Sprint Retrospektif )
   • Testler İLK - Hızlı, Bağımsız, Tekrarlanabilir, Kendinden Doğrulamalı ve Zamanında Olmalıdır.

Yukarıdaki liste kesinlikle eksik ve bazı kısımlar tartışmalı bile olabilir!

Bütün bu sizi korkutuyor varsa - bu, çünkü merak etmeyin gerektiğini korkutmak! Ekiplerde yazılım geliştirme projelerini başarmak kolay bir iş değildir ve nadiren bu konuda iyi eğitilmiş ve eğitimli insanlardır. Bu sizi korkutuyorsa, sezginiz düzgün çalışıyorsa, dinleyin. Hazırlanmak istiyorsun. Patronunla konuş, biraz zaman kazan ve antrenman yap.

Ayrıca bakınız

• Teknik 'kullanıcı hikayelerini' kim yazıyor?

Daha fazla okuma (çevrimiçi)

• Ward Cunningham et al tarafından Portland Desen Deposu
• OOD İlkeleri Robert "Bob Amca" C. Martin
• Pragmatik Programcı İpuçları

Daha fazla okuma (kitap)

• Robert C. Martin tarafından Temiz Kod
• Çevik Yazılım Geliştirme: Prensipler, Desenler ve Uygulamalar Robert C. Martin
• Pragmatik Programcı - Yolcudan Ustaya Andrew Hunt ve David Thomas
• Michael Feathers'ın Eski Koduyla Etkili Çalışma
• Refactoring - Martin Fowler Tarafından Mevcut Kod Tasarımının Geliştirilmesi
• Joshua Kerievsky'den Desenlere Yeniden Dönüş
• Steven Silbiger tarafından On Gün MBA (sic!)
• Eric Evans'ın Domain-Driven Design
• Mike Cohn Tarafından Uygulanan Kullanıcı Hikayeleri
• Gray Booch ve arkadaşlarının Uygulamaları ile Nesne Yönelimli Analiz ve Tasarım
• Dörtlü Çetenin Tasarım Desenleri
• Kent Beck tarafından Test Odaklı Geliştirme
• Kent Beck tarafından Extreme Programlama
• [eğer Java] Etkili Java, Joshua Bloch tarafından

Çevik Ol

Aşağıdakileri öneririm:

Aynı dosyaları düzenleme

İlk önce Git (veya benzeri bir eşzamanlı sürüm sistemi) kullanın. Aynı dosyaların farklı kısımlarını düzenlediğiniz sürece, çatışmalarla karşılaşmazsınız. Çatışma yaparsanız, açıkça açıkça işaretlenir.

Git olmadan çoklu geliştirici bir projeyi yönetmeye çalışmak bir puding kasesi olmadan bir puding yapmaya çalışmak gibi. Mümkün, ama oldukça çabuk dağınık olacak.

Yorumlarda da belirtildiği gibi Git her derde deva değil, otomatik testlerle birleştiğinde kesinlikle çok yardımcı oluyor.

Tüm özellikleri listele

İkincisi, projeyi kullanıcı tarafından görülebilir özelliklere ayırın. Örneğin, "kullanıcı kaydolduğunda bir e-posta almalıdır" veya "Kullanıcı bir öğe ekleyebilir". Tüm paydaşları buraya dahil edin. Herkesi bir odaya sokun ve herkesin özelliklerini söylemesini isteyin.

Bunlar kullanıcı tarafından görülebilen özellikler olmalı, daha sonra uygulama stratejisi hakkında konuşabilirsiniz.

Tüm önerileri indeks kartlarına, hatta salak olanlara bile yazın. Kopyaları çıkarmak için listeyi hızla rasyonelleştirin ve tüm kartları büyük bir masaya, hatta yere koyun.

Gerekli olan ek kartları ekleyin. Uygulamanızın SMS metin uyarıları göndereceğini söyleyin. Bunu nasıl yapacağınızı bilemeyebilirsiniz, bu yüzden bir sorunuz var. Bir kartta "SMS portallarını araştır" yazın. Aynı şekilde diğer büyük bilinmeyenler için. Bunları daha sonra açmak zorunda kalacaksınız. Bu özellikler muhtemelen ilk süratinize giremez.

Şimdi kartlarınızı gruplara ayırın, karıştırın, onlar için bir fikir edinin . Bu senin proje kapsamın.

Poker planlama

Poker planlamaya bir göz atın. Yine de herkesle birlikte, tüm geliştiricilere "1 puan", "2 puan", vb. "4 puana" kadar kart verin. Ayrıca bir "daha fazla" kart. Bir nokta kabaca bir saate eşittir.

Özellik listesine birer birer göz atın. Bir özelliği okurken, herkes kart oynamak zorunda. Bir kişi 1, diğer kişi 4 oynuyorsa orada bir iletişim sorunu var. Bir kişi diğerinden farklı bir şey ifade etme özelliğini anlar. Bir tartışma yapın ve gerçekte ne anlama geldiğini öğrenin ve bunu kartta not edin.

Bir özelliğin "daha" olduğunu kabul ederseniz, bu özellik çok büyük demektir. Bu özelliği yıkmak zorundasın. Bunu daha önce yaptığınız gibi yapın.

Anlaştıkça, kartların üzerindeki numaraları farklı bir renkte yazınız.

Puanlar saatlerden daha iyi

Saat yerine nokta kullanmak, maçoları “geliştirenlerin ne kadar hızlı kodlayabildiğime bak” gibi gösterdiği şeyleri ortadan kaldırıyor.

Şimdi bir sprint oluştur

Sprint bir hedefe doğru hızlı bir patlama. Sprint uzunluğu, belki de 5 veya 10 gün karar verin. Gün sayısını, geliştirici sayısına göre, günlük sayı sayısına göre çarpın.

Başlangıçta geliştirici başına günde 6 puan alın. Bu, ulaşılabilir bir sayıdır. Eğer 5 kişiniz varsa, bu 5 * 5 * 6 = 150 puandır. Tüm geliştiriciler ve yönetim ile birlikte, listeden 150 noktaya kadar özellikler seçin. Bu senin sprintin.

Asla sığacak olandan daha fazla sıkmak için asla cazip olmayın. Aşırı umut verici, siz de dahil, uzun vadede herkesi incitir.

Burada bağımlılıkları hesaba katmanız gerekecek. Örneğin, çevre ayarlarının ilk sprint'te açıkça yer alması gerekiyor. Bu aslında herkes varken yapmak nispeten kolay. Odada, “buna bağlı” diyen 6 beyin var, vs.

Sprintinizi aldıktan sonra, hiçbir şey eklenemez, 5 gün boyunca kilitli kalır. Özellik sürünmesi ekibi zorlayacak, morali bozacak ve herkesi yavaşlatacak. Sonunda, sürünme bir projeyi durdurur. Takım lideri olarak, ekibinizi özellik sürünmesinden korumak zorundasınız. Yeni bir özellik isteği gelirse, bir sonraki sprint'e eklenmelidir. Bir sonraki sprint zaten dolu ise, başka bir şey çıkarılmalıdır.

Asla ekstra sıkmak için cazip olmayın. Aşırı umut verici olmak, yaklaşık 1 günlük mutlu müşteriyi, ardından 4 günlük takım stresini ve sonunda takımın zamanında teslim edemediği çoğu mutsuz müşteriyi verir.

Şimdi git ona.

Kartları dağıtın, kimin ne yapmak istediğini sorun. Neler yapıldığına dair tam bir görüş hakkınız var ve geçiş yapan noktaları sıfıra kadar sayabilirsiniz. Her gün başında herkesin konuşmasını isteyin, böylece herkes kimin neyin üzerinde çalıştığını ve neyin yapıldığını bilir.

Açıkça tanımlanabilir yönetilebilir hedefler üzerine bir birim olarak birlikte çalışan 5 veya 6 iyi motive edilmiş geliştirici, 5 günlük bir sprintte oldukça tıknaz miktarda bir şey başarabilir.

Görünürlüğü korumak

Herkesin projenin durumunu görebildiğinden emin olun. Tüm kartları duvara yapıştırın. Solda henüz üzerinde çalışılmamış kartlar var. Sağ tarafta kartlar yapılır.

Bir geliştirici bir kart üzerinde çalışırken, duvardan çıkarır ve masalarına koyar. Bu görünürlük sağlar ve insanların birbirlerinin üstüne çok fazla ayak basmalarını önler.

Dizin kartlarına teknolojik alternatifler var, ancak duvarda proje durumunu gösteren çok büyük bir kâğıt ekrana sahip hiçbir şey yenmiyor.

Mümkünse, proje süresince herkesi aynı odada tutun. Paydaşlara mümkün olduğunca etrafta, her gün ideal şekilde sahip olun.

Kül olmak

Bir yakma tablosunda sıfıra doğru ilerleyen puanlarınızı grafik olarak çizebilirsiniz. En iyi uyum sıranız zaman sınırınıza ulaşmadan önce sıfırı geçerse, büyük olasılıkla pistte olursunuz. Aksi taktirde müvekkilinize şimdi bildirmeniz gerekebilir, son tarihe yaklaşmadan önce.

Eğer başarısız olacaksan, erken başarısız ol.

Yazılımı kullanarak yazma işlemi yapabilirsiniz, ancak duvardaki büyük bir kağıt parçasını tercih ederim. Üzerine çizin ve yazın.

Otomatik test

Aynı şey üzerinde aynı anda çalışan birden fazla geliştiriciniz varsa, muhtemelen zaman zaman birbirlerinin kodunu kıracaklar. İletişim ve görünürlük bu konuda yardımcı olur, ancak muhtemelen sorunların çözümüne yardımcı olacak bazı teknolojiler sunmak isteyeceksiniz.

Birim testi, kod tabanınızın her bir parçası için test yazma işlemidir (ideal olarak her yöntem). Ünite testleriniz, mümkünse her tasarrufta sık sık yapılmalıdır. Buna yardımcı olabilecek birçok araç var, örneğin Karma veya Rspec.

Uçtan uca test, projenizi bir bütün olarak test etmeyi, içselleri kara kutu olarak görmeyi içerir. Bu testleri yüksek işletme gereksinimlerinize göre ayarlayın, örneğin: "Kullanıcı kaydolabilir" veya "Kullanıcı bir öğe listesi görebilir". İletki, web tabanlı test çerçevesinin uçtan uca güzel bir örneğidir.

Test üzerine yazılmış bütün kitaplar var, ancak en azından bazı kabul testlerinin yapılması, projeniz üzerinde çalışırken hiçbir şeyin kırılmamasını sağlamaya yardımcı olabilir.

Teknik borçlardan kaçınmak ve yapılması gerekenler

Teknik borç, daha sonra temizlenmesi gereken şeyleri tanımlayan bir kavramdır. Ortak bir borç kaynağı, yapılan gibi işaretlenmiş, ancak asla "bitmemiş" olan özelliklerdir. Git'te yapılan bir özellik kontrol edildi, paydaş tarafından onaylandı ve test edildi.

Yapılmadıkça özelliklerinizi kontrol etmeyin. Grafiğe asla masaj yapmayın. Yine, bu sizleri de içeren uzun vadede herkesi incitiyor.

Bu, başlangıçta günde yalnızca geliştirici başına 6 puan teklif etmemizin bir nedenidir. Bittiğinde fazladan iş var, ama harika hissediyor ve takıma destek veriyor.

Aynı dosyaları düzenlemek kendi başına bir sorun değildir. Yalnızca iki farklı şey yapmak için aynı işlevi düzenlerseniz sorun olur.

Temelde yapacağım şey, projeyi ayrı olan 'özelliklere' bölmek. Biri ağ protokolü kullanımıyla ilgili, diğeri bir yapılandırma dosyasına, diğeri de DB kullanımıyla ilgili bir şey olabilir. Özellikler büyük şeylerdir.

Sonra, bu özellikleri görevlere (hikayeler) bölmek istersiniz. Bunlar "kullanıcı bir düğmeyi tıkladığında, program dosyayı yükleyecektir", "program başladığında, yapılandırma dosyasını yükleyecektir" gibi basit şeyler olmalıdır.

Bazı görevlerin sırayla tamamlanması gerekir ("program, yapılandırma dosyasındaki tüm alanları ayrıştırır", "program, yapılandırma dosyasını yükler" den sonra gelmek zorundadır). Diğerleri çalışmaz (aynı anda DB ve ağ üzerinde çalışabilirsiniz).

Ama büyük olasılıkla, yanlış yapacaksın ve deneyimin gerçekleştiği yer orası. Sadece küçük bir parça (veya çok fazla) başarısız olacak, zaman tahminlerini yanlış anlayacaksınız ve projeniz olması gerekenden biraz daha fazla zaman alacaktır. Bir dahaki sefere daha iyi olacaksın.

Kent Beck'in “Extreme Programming” kitabını okumayı da öneririm. Proje yöneticisi olmak üzereyken bana yardımcı olan harika kitap.

Asıl konu, uygulamanızı işlevsel modüllere ayırmanız ve ardından farklı modüller arasında sözleşmeler (arayüzler ve veri sözleşmeleri) uygulamanız gerektiğidir. Her modül daha sonra farklı bir geliştiriciye dağıtılabilir. Her şeyi bir araya getirdiğinizde, sözleşmeler bu modüllerin birbirleriyle doğru iletişim kurmasını sağlayacaktır.

Tüm modüllerin ayrı ayrı çalışmasını sağlamak için TDD'yi geliştiriciler üzerinde uyguladığınızdan emin olun.

Ne demek istediğime bir örnek vermek gerekirse:

Diyelim ki geliştiricilerinizden birinin bir SQL logger oluşturmasını istiyorsunuz.

Bir arabirim tanımlar ve geliştiricilerinizden birine ( ya da Çevik kullanıyorsanız bir hikaye oluşturun ) aşağıdaki belirtime göre SQL'e özgü bir kayıt cihazı isteyip istemediğinizi sorarsınız :

interface ILogger
{
    void Log(string message, int level);
}

Bir geliştiriciden geri beklediğim şey şudur:

1. Logger için SQL'e özgü uygulama

   class SqlLogger : ILogger
   {
       private readonly SqlLogRepository _logRepository;
   
       public SqlLogger(SqlLogRepository _logRepository)
       {
           this._logRepository = _logRepository;
       }
   
       public void Log(string message, int level)
       {
           _logRepository.CreateLog(message,level);
       }
   }

2. Bir uygulama gibi herhangi bir bağımlı kod SqlLogRepository

3. Neyin istendiğine bağlı olarak birim veya alay testleri. Yukarıdaki durumda (başka dış bağımlılıkların olduğu yerlerde) yapılan sahte bir test veya örneğin basit bir fonksiyon olarak String.ReverseCharacters(string input), o zaman sadece birkaç farklı senaryoyu test eden ünite testlerini görmek istiyorum.

Bu şu demek:

Siz ve ekibiniz bu arayüzü kullanarak geliştirmeye devam edebilirsiniz. Örneğin

class SomeModuleThatUsesLogging
{
    private readonly ILogger logger;

    public SomeModuleThatUsesLogging(ILogger logger)
    {
        this.logger = logger;
    }

    public void DeleteFiles()
    {
        logger.Log("user deleted files",1);
    }
}

ve kodunuzu girmeden önce çalıştırmanız gerekiyorsa SqlLogger, basit bir işlem oluşturabilirsiniz NullLogger:

class NullLogger : ILogger
{
    public void Log(string message, int level)
    {
    }
}

Ve bu arada bunu nasıl test edebileceğinizi (bağımlılık enjeksiyonunda ICO'ya bakmanızı öneririm)

void Run()
{
    var someModuleThatUsesLogging = new SomeModuleThatUsesLogging(new NullLogger());
    someModuleThatUsesLogging.DeleteFiles();
}

özet

Projenizin büyüklüğü hakkında hiçbir fikrim yok, ancak bu oldukça göz korkutucu bir iş olabilir ve daha önce hiç gelişme sağlamadıysanız, bu görevi çok ciddiye almanızı ve önümüzdeki birkaç haftayı sizin kadar okumak için harcamanızı öneririm. Yazılım tasarımı ve mimarisini yapabilir. Ve işiniz hakkında çok şeffaf olun ( yazılım kalitesi vb. ) Aksi takdirde, çabucak nasıl çıkacağınızı bilmediğiniz derin bir karmaşa içinde bulacaksınız.

Ayrıca, tasarımı ve nesneye yönelik paradigmayı okumanızı da şiddetle tavsiye ederim. Bu proje için yoğun olarak OOP'a güveneceksiniz.

Diğer cevaplar programlama yönlerinden bahsetti, ama ben sadece program yönetimi yönünden bahsetmek istedim. Bir feragatname ile başlayacağım: Bir program yöneticisi değilim. Program yönetimi için lisans düzeyinde bir ders aldım ve iş tecrübem genellikle 500 saatin altında ve asla 1000 saatin üzerinde olmayan küçük projeler için teklif saatleri içeriyor.

Ancak 2-3 kişiyi 2-4 ay (yarı zamanlı ve tam zamanlı) meşgul tutmak zorunda kaldığım bir laboratuar görevini tanımlamam gerekti. Bana gerçekten yardımcı olan bir şey, Microsoft Project gibi bir proje yönetimi yazılımı kullanıyordu (orada ücretsiz bir sürüm olup olmadığından emin değilim, ancak işvereninizin muhtemelen onun gibi bir şeyleri var ... süpervizörünüze ne tür bir program yönetimi yazılımı kullanıldığını sorun. Şirketinizde). Özellikle, Gantt grafiklerini biraz kullanıyorum, bu da Microsoft Project'teki varsayılan görünümdür. Tüm görevleri ve ne kadar süreceklerini düşündüğünüzü tanımlayarak oynayabileceğiniz görselleştirme elde edebilirsiniz.

Gantt grafiği, görselleştirmesinden dolayı bana çok yardımcı oluyor. Görevleri kağıt üzerinde görmek bana pek yardımcı olmaz, ama güzel resimler ve bir grafik görmek kesinlikle işe yarar. Microsoft Project ayrıca, önceleri ve başlangıç ​​tarihlerini ayarlamanıza olanak tanır; ana fikir "X görevinin başlaması için gereken asgari miktarda görevi bulun" şeklindedir. En azından küçük projelerimde, 'gerçek' öncüllerin miktarı oldukça küçük. Aslında, bir projede hemen hemen her şeyin aynı anda yapılabileceği problemi yaşadım ve biraz uyumlu iki eşzamanlı yolu sentezlemek zorunda kaldım. Örneğin, eğer A geliştiricisi GUI'ye dokunursa, GUI'ye yakın olan görevlerde de çalıştıklarından emin olmaya çalıştım.

Bu zaten kalem ve kağıdın gittiği kadar çok şey yapıyormuşsunuz gibi geliyor, ama Gantt listelerinde gerçekten görmeyi her zaman gerçekten faydalı buluyorum. Sıralı olarak sıralanan görevlere bakmak, beni "Görev X'in görev Y'den önce gerçekten yapılması gerekiyor mu?" (Şu ana kadarki deneyimlerime göre cevabın aslında 'hayır' olmadığına şaşırdım) ”diye düşünmemi sağlıyor.

Geliştirici olmaktan yazılım mühendisi olmaktan mezun gibisiniz. Çalışmayı yönetmenin bir tasarım alıştırması olmadığını ama ikisinin el ele gittiğini anlayın. Yapılmakta olan işleri yönetmeniz gerekir ve bu, şirketinizin nasıl gelişim gösterdiğine bağlıdır. Zamanınız ve kaynaklarınız varsa, çevik bir metodoloji benimseyin - internette yazılı materyallerin dağları var. Sizin için işe yarayan bir tane bulun, ancak her şeyin olduğu gibi ücretsiz olmadığını unutmayın. Herhangi bir tekniğin benimsenmesi, başarılı olmadan önce eğitim, öğrenme ve başarısız olmayı içerir. Daha kapsamlı bir teknik benimsemek için bant genişliği yoksa, o zaman dönüm noktası planlaması yapmak sizin için cevap olabilir. Bir sıralı görevler listeniz varsa, bu diziyi bulamadığınız dizileri bulamamış olabilirsiniz.paralelleştirilmek. Ayrıca, gelişiminizi test etme ve uygulama gibi daha genel görevlere bölmek istediğiniz de olabilir. Bu, tek başına raporlama sorununu çözmez, ancak kaliteyi yönetiyorsunuz. İlerlemeniz sıralı bir liste olabilir, ancak rolleriniz paraleldir. Sadece bir öneri. İnsanlar tarafından yapılan işi haritalayan bir tasarıma, çalışma dökümü yapısı denir.

Diğer insanların önerdiği birçok iyi öneri var, ancak işleri yönettiğinizi unutmayın. Bazen iş kavramlarını tasarıma / mimariye eşleyebilir, bazen bu kadar kolay yapamazsınız. Çalışmayı her zaman izlenebilir şekilde yapılandırmanın bir yolu vardır. Yöneticinize geri dönmenizi ve projenin durumunu iletme konusunda kendisine neyin önemli olduğunu sormanızı öneririm. Bu size yaptığınız işe nasıl yaklaşacağınızı anlatmaya başlayacaktır. Zamanlanmışsa, ilerlemeyi rapor etmeye odaklanmak istersiniz. Kalite ise, o zaman ortaya çıkmanız gereken bir metrikler paketi hakkında rapor vermek istersiniz. Maliyeti varsa, muhtemelen çabaya bakmak isteyeceksiniz. Bu şeylerin hepsi aynı zamanda görevlerin içine veya dışına haritalanabilir.