Görevleri Parçalama
(jacobian.org)- Proje tahmini yapmak veya bir işi devretmek, “bunu yapmak” gibi büyük bir isteği net bir görev listesine dönüştürmekle başlar; her madde istenen değişimi ve tamamlanmış hâlini göstermelidir
- Parçalama süreci, fikirler, eskizler ve ilk listelerden başlayarak gerekli adımları yazmak ve her madde yeterince tanımlanana kadar özyinelemeli olarak ayrıntılandırmak şeklinde ilerler
- Dış mekân aktiviteleri için bir streak tracker örneği; veri modeli, takvim görünümü, aktivite kaydı, streak hesaplama ve streak freeze olarak giderek ayrışır ve belirsiz noktaları da ortaya çıkarır
- “Yeterince tanımlanmış görev”, istenen değişim, tamamlanmış hâlin nasıl göründüğü, tamamlanana kadar gereken tüm adımlar ve hemen başlamak için gerekli bilgiler konusunda her soruya evet denebilen durumdur
- Görevleri parçalamak, deneyime dayalı pattern matching gerektiren bir beceridir; bu yüzden yeni ekiplerin plan yapmayı deneyebilecekleri ve geri bildirim alabilecekleri güvenli pratik fırsatlarına ihtiyacı vardır
Büyük bir projeyi görev listesine dönüştürmek
- Proje tahminine dair önceki tartışmalar, zaten net bir görev listesi olduğunu varsayıyordu; ancak pratikte bundan önce gelen görev parçalama aşaması önce gerekebilir
- Görev parçalama, büyük bir projeyi onu oluşturan işlere ayırma sürecidir; tahmin yapmak veya devretmek için “bu görseli yapmak” gibi tek bir görevden daha ayrıntılı birimlere ihtiyaç vardır
- Tek başına yürütülen kişisel bir projede bir eskiz yeterli olabilir; ancak işi başkasına verecek veya süre tahmini yapacaksanız ayrıntı düzeyini artırmanız gerekir
Örnek: kişisel bir streak tracker
- Dışarıda yapılan aktivitelerin işlendiği kişisel bir streak tracker örnek olarak kullanılıyor
- Streaks uygulamasına benzer bir yapı isteniyor
- Koşu, bisiklet, kayak gibi dış mekân aktivite seçenekleri eklenmek isteniyor
- Duolingo’nun streak freeze özelliği de dâhil edilmek isteniyor
-
1. tur: eskizle başlamak
- Görsel bir mockup, yapılacak işlevleri anlaşılır biçimde gösteren iyi bir başlangıç noktasıdır
- Tek başına yapılan bir projede bu düzeyde bir eskizle doğrudan kod yazmaya başlanabilir
- Amaç tahmin yapmak veya devretmekse, “bu görseli yapmak”tan daha küçük parçalara bölünmüş bir görev listesi gerekir
-
2. tur: büyük özellik birimlerine ayırmak
- İlk parçalamada proje kabaca ana bileşenlere ayrılır
- Veri modelleme
- İçinde bulunulan haftanın tarihlerini gösteren takvim görünümü
- Simgelere tıklayarak aktivite kaydı oluşturan ve ilgili tarihi streak takibinde tamamlandı olarak işaretleyen etkileşimli takvim
- Mevcut streak uzunluğunu hesaplama ve gösterme
- streak freeze uygulaması
- Örneği basitleştirmek için dağıtım, veritabanı kurulumu gibi operasyonel işler dışarıda bırakılmıştır
- Gerçek projelerde, özellikle de birden fazla kişinin yer aldığı projelerde, dağıtım, frontend ve backend işlerini ayrı maddelere ayırmak daha uygun olabilir
- Bu aşamada bile bir miktar tahmin yapılabilir; ancak freeze birikimi ve takibi, geçmiş kayıtlar, aktivite türü ekleme ve silme gibi belirsizlikler hâlâ vardır
-
3. tur: tamamlanma ölçütü görünecek kadar daha da ayırmak
- Veri modeli; aktivite türleri, kaydedilmiş aktiviteler, freeze ve streak olarak ayrılır
- Aktivite türleri için run/bike/ski/climb gibi sabit kodlanmış bir liste yeterlidir
- Kaydedilmiş aktiviteler tarih ve tür bilgisine sahiptir
- freeze, kazanıldığı tarih ile kullanıldığı tarihe sahiptir
- streak; başlangıç tarihi, bitiş tarihi ve aktivite türüne göre özet bilgileri içerir
- Statik takvim görünümü; haftalık görünüm, ana ekran, aylık görünüm, gezinme ve tarih taşıma girdisine ayrılır
- Tarih taşıma için karmaşık bir fuzzy date girişi yerine HTML5 date bileşeni kullanılabilir
- Dinamik haftalık takvim, aylık görünüme dinamik girdi eklemek yerine belirli bir tarihin aktivite türüne tıklanarak tamamlanma kaydı bırakır
- streak hesaplama ve gösterme; aktivite kayıtlarını tarayarak streak hesaplamayı, mevcut streak’i arayüzde göstermeyi ve arayüzden aktivite kaydedildiğinde streak’i yeniden hesaplamayı içerir
- streak freeze; birikim, mükerrer birikimi engelleme ve arayüzde kullanım ile kalan sayıyı göstermeyi kapsar
- freeze kazanma eşiği olan X gün şimdilik sabit kodlanabilir
- freeze bir sonraki streak’e devredilebilir
- Geçmiş aktiviteler düzenlenip streak yeniden hesaplandığında, freeze’in tekrar kazanılmasına bağlı mükerrer birikim engellenmelidir
Tekrarlanan parçalama süreci
- Görev parçalama, tek seferde biten bir tasarım değil, yinelemeli bir süreçtir
- Bir görev listesiyle veya tek bir büyük projeyle başlanır
- Bu işi bitirmek için gereken adımlar düşünülür ve yazılır
- Her adımın yeterince tanımlı olup olmadığı kontrol edilir
- Yeterli değilse ilgili madde yeniden parçalanır
- Her yinelemenin eksiksiz ya da kusursuz olması gerekmez; bir önceki listeden biraz daha genişlemesi yeterlidir
- Tüm görevler yeterince tanımlanana kadar aynı süreç tekrarlanır
“Görev” ve “yeterince tanımlı” olma ölçütü
- Yazılım geliştirme ve proje tahmini bağlamında görev, yeterince tanımlanmış, tam ve bir değişim aktaran iş birimidir
- “bir şeyler üzerinde çalışmak”, gereksinimlerin çerçevesi belli olmadığı için görev değildir
- “ağaç kesmek”, elinizde yalnızca motorlu testere varsa tam bir görev değildir
- İş bağlamında bir görevin anlamlı olması için yapıldıktan sonra bir şeyin değişmiş olması gerekir
- Bir görevin yeterince tanımlı olup olmadığı, işi yapacak kişinin şu soruların hepsine “evet” diyebilmesiyle anlaşılır
- İstenen değişimin ne olduğunu anlıyor muyum
- “Tamamlandı” hâlinin nasıl görüneceğini anlıyor muyum
- Tamamlanmak için gereken tüm adımları tanımlayabiliyor muyum
- Engelleyici veya bağımlılık olmadığını varsayarsak, hemen başlamak için gereken tüm bilgiye sahip miyim
- Kurumsal bağlama göre proje yöneticisi, ana paydaşlar veya denetçi gibi gözlemcilerin de bu sorulara “evet” diyebilmesi gerekebilir
- Hata düzeltme gibi, daha fazla alt parçalara ayrılması zor bilinmeyenler içeren görevler de vardır
- Böyle durumlarda timeboxing gibi teknikler kullanılabilir
Deneyimle gelişen parçalama sezgisi
- Görev parçalama, pratik gerektiren bir beceridir ve başta kolay gelmemesi normaldir
- Örnekte veri modellemenin önce gelmesinin nedeni, açık bir algoritma değil, deneyime dayalı sezgidir
- Benzer araçlar yapılırken veri modelini önce kurmanın işleri daha iyi ilerlettiğine dair bir deneyim vardır
- Django, model-veri öncelikli akışa daha uygun affordance’lar sunar
- Çok sayıda proje görme veya yapma deneyimi yoksa başlangıç noktasını belirlemek zor olabilir
- Bir ekibin bu yeteneği geliştirebilmesi için güvenli bir ortamda proje planı hazırlaması, onu parçalamayı denemesi ve geri bildirim alması gerekir
- İlk planlar çok hatalı olsa bile bunun cezalandırılmaması, o hataların bir sonraki pattern matching için deneyim verisi olmasını sağlar
Örnek projenin tahmin sonucu
- Bonus tahminde, görevler alt parçalara ayrıldıktan sonra her birine karmaşıklık, belirsizlik, beklenen gün sayısı ve en kötü durum gün sayısı eklenir
- Toplam tahmin 15,5 gün, en kötü durum ise 23,5 gün olarak hesaplanır
- Ana kalemlerden streak hesaplama ve freeze birikimi, orta karmaşıklık ve orta düzey belirsizlikle ayrı ayrı 3 gün; en kötü durumda 4,5 gün olarak tahmin edilir
- freeze’de mükerrer birikimi önleme, küçük karmaşıklığa sahip olsa da aşırı belirsizlik nedeniyle 1 gün; en kötü durumda 5 gün olarak ele alınır
- Gerçekte yaklaşık on iki akşam ve bir uzun uçuşta tamamlandı; ancak tasarım büyük ölçüde atlandı ve freeze algoritmasında daha sonra ortaya çıkabilecek hatalar bulunma ihtimali var
1 yorum
Hacker News görüşleri
Birincisi, gerçek adımları planlandığı gibi sonuna kadar uyguladığım neredeyse hiç olmadı. Birkaç adımdan sonra yeni bir şey fark ediyor, bir şeyi atladığımı görüyor ya da daha kolay bir yol buluyorum; bu yüzden planı izlememeye başlıyorum
İkincisi, nasıl yapılacağını düşünmeye dair yaratıcı çabanın tamamen baş tarafa yığılmış gibi gelmesi; bu yüzden böyle çalışmaktan hoşlanmıyorum. Geri kalanı hâlâ işin büyük kısmı ama geriye sadece en sıkıcı bölüm kalıyor. Yaratıcılığı ve sıkıcılığı daha dengeli karıştırmak daha eğlenceli oluyor; bu yüzden daha hızlı ve sonuç da daha iyi oluyor
Bu ikisi muhtemelen bağlantılı ve bende ADHD olma ihtimali de yok değil
Kendi projenizi keşfediyor ya da inşa ediyor ve belirgin bir hesap verme yapınız yoksa, planlamanın kendisini sevmiyorsanız o kadar da plan yapmanız gerekmez
Ama patron “Ne kadar sürer? Kim ne yapar? Nereden başlarız?” diye sorduğu anda bir çerçeve gerekli olur
Ben de keyfi ya da aşırı katı sistemlere uymaktan hoşlanmıyorum ama sistemler basit ve esnek olmalı; üretkenlik sistemleri insanlara yardım etmek içindir
Yazarın bunu ayrıntılı bir tarif gibi sunmaktan çok, kendi yaklaşımını gösterip başkalarının kendi fikirlerini üretmesine yardımcı olmak istediğini düşünüyorum
“Plan asla aynen takip edilmez” demekten daha kötü durumlar da oluyor. Uygulama sırasında sürekli yeni işler eklediğinizde, sonunda planlama sırasında oluşturulan görevlerle karışıp artık gerekli olmayan yarım kalmış bir görev listesi dağınıklığı kalıyor
Çünkü o görevler, yalnızca uygulama sırasında ortaya çıkan bütün bağlam olmadan oluşturulmuş oluyor
Programlamanın eğlencesi, esnek ve akışkan biçimde ilerleyen yaratıcı bir etkinlik olması. İlerlerken bir şeyler kuruyor ve bunu organik biçimde deneyimliyorsunuz
İş ortamında ise gözetim ve sorumluluk takibi gerektiği için bu organiklik çoğunlukla ortadan kaldırılıyor
Bir dahaki sefere aynı ya da benzer bir işi planladığınızda, gelecekteki planınız daha iyi olur
Proje yöneticilerinin de “Planlamada başarısız olmak, başarısızlığı planlamaktır” diye bir sözü vardır
Çünkü hatırlamam gereken onca şey arasında bir şeyleri kaçırdığımı sık sık fark ediyorum
Plan, geçmişteki benim düşündüğü ideal sonucu gelecekteki bana hatırlatmanın bir yolu sadece; sürekli plan değiştirip ateş böceği kovalamak yerine
“İşi parçalara ayırmak”, kitap türü ya da podcast türü olacak kadar büyük bir konu. Kişisel gelişim ya da organizasyonla ilgili kitaplarda, işi parçalamanın okurların zaten sahip olduğu ilkel bir insan yeteneği olduğu varsayılıyor
Ama benim deneyimime ve grup oturumlarında duyduklarıma göre, işi parçalamak çok zordur ve kaçınma duygusu ya da umutsuzluk yaratabilir
Gördüğüm en geniş uygulanabilir tavsiye, o işi başarıyla tamamlayabileceğinize dair güveniniz %90 seviyesine ulaşana kadar onu daha küçük parçalara bölmeye devam etmenizdir. Bu güven seviyesi öz güveninize ve risk alma eğiliminize göre değişir; bazı insanlar işi başarı olasılığı %70 civarına gelene kadar bölebilir
Bir günde gerçekten kullanılabilir zaman yaklaşık 6 saattir; biri bir işin “yarım gün” süreceğini kendinden emin biçimde söylediğinde bunun yaklaşık 3 saat olduğunu hatırlatınca bir anda çok daha az emin oluyor ya da rahatsız oluyor. Ve 3 gün sonra hâlâ onunla uğraşıyor oluyor
Bu yaklaşım zaman tahmininde şaşırtıcı derecede doğru çıktı ama toplamda doğruydu; tek tek tahminler ciddi biçimde sapıyordu
Sonuçta bu bir olasılık tahmini. Çok sayıda olay üzerinden geçince ortalamaya yakınsıyor
Çoğu kişinin anlamadığı sorun, yazılım geliştirmenin her şeyden önce yaratıcı bir faaliyete yakın olmasıdır. Elbette ciddi teknik yönleri vardır ama problemin kendisi sanaldır ve inşaat mühendisliği gibi gerçek dünyanın kısıtlarına bağlı olmadığı için tek bir en iyi çözüm yoktur
Problemi düzgünce incelemeden çözümü tanımlamaya çalışmak, sadece nihai çıktıyı kısıtlar. Keşfin büyük bölümü aslında kod yazmaya başladıktan sonra olur
Yazılımda nihai çıktının ve sürenin net tanımlı olmaması o kadar önemli değildir çünkü birim başına maliyet yoktur. Yazılım mühendisliği geçmişi olmayan yöneticiler bunu pek anlayamaz
Genellenebilir bir ürün, ek geliştirme maliyeti olmadan birçok müşteriye satılabilir
Ama çoğu şirket fabrika gibi çalıştığı için, bütün süreçler sonunda belirli bir müşteriyi hedefleyen çok sınırlı ürünler üretir. Büyük teknoloji şirketlerinin kaçındığı şey tam da budur
Sektörün tamamı bu kalıbı benimsemiş gibi görünüyor
Ama dürüst olmak gerekirse, çoğumuzu durduran şeyin asıl olarak bunu yapmama becerisinin eksikliği olduğunu düşünüyorum. Yapmak istediğiniz bir şey varsa, bütün parçaları planlamayın; değer üretebilecek en küçük şeyi gidip yapın yeter
Mesela “Bugün” ekranı ve 4 düğmeyle başlayabilirsiniz. Her gün basılacak 4 egzersiz düğmesini gösterecek şeyi bugün yapabilirsiniz. Seri, dondurma, takvim görünümü olmak zorunda değil
Bu fikirlerin hepsi güzel ve sonra yine yapılır ama önce ivme gerekir. Birkaç gün sonra o takvim görünümünü zaten beğenmediğinize karar verebilirsiniz
Daha fazla proje için “küçük de olsa sadece yap” diye itmek gerekir. Bugün bitir ve o noktada bir sonraki işin ne olduğuna bak. Planlama aşamasında düşündüğünden farklı olma ihtimali yüksektir
Elbette bu da kolay değil. En küçük şeyi bulmak ve dağılmadan yayınlamaya karar vermek düşünce ve disiplin gerektirir. Yine de pratik etmeye değer
Belirsizlikle karşılaşınca “sıradaki doğru şeye” odaklanmak gerektiği ilkesi [0]
Bunu önemsiz göstermek istemiyorum. Sıradaki doğru şeyi bulmak zordur ve benim bakış açıma göre planlamanın en değerli kısmıdır
0: https://en.wikipedia.org/wiki/The_Next_Right_Thing#Synopsis
Örneğin bir kişi test için karşılaştırma yöntemi oluşturur, bir başkası bir yaklaşımı, bir diğeri başka bir yaklaşımı, üçüncü bir kişi de başka bir yaklaşımı dener; ardından belirlenen bir sürenin sonunda hepsi değerlendirilir
Elbette bu ancak zaten tercih edilen ya da açıkça üstün olan bir yaklaşım yoksa anlamlıdır
Gerçek geliştirme sırasında modülerleştirme paralelleştirme yöntemi olabilir. Kişi veya takım başına bir bileşen vermek gibi
Kendi işimde özellikle yönü hâlâ anlamaya çalışırken, insanın karşısına çıkan kısımla teknik iç yapıyı dönüşümlü ilerletmeyi seviyorum. Kullanımını bilmeden sadece teknoloji geliştirmek, kullanılabilir biçimi belli bir yöne zorlar; teknolojiyi bilmeden sadece arayüz tasarlamanın da tuzakları vardır
Ama araştırma gibi önceden bilinmeyen bir şeyi doğrulamak için yaratıcı deneyler ve kavram kanıtı gereken işlerde, iş ayrıştırmanın kendisi çöker
Bu yüzden kavram kanıtı çalışmalarının çoğunu gizli yürütme ve kimseye söylememe alışkanlığım oluştu
İyi giderse yayınlayabilirim; iyi gitmezse de rezil olmadan ya da devam edilmemesi gerektiği netleştiği hâlde bir şekilde oldurmam söylenmeden çöpe atıp geçebilirim
“X’i araştırmaya 3 saat, Y’ye 3 saat, Z’ye 3 saat ayıralım; sonra sırada ne olacağını planlamak için toplantı yapalım” denebilir
Sonuç dört tanedir. Ya birincisi çözer, ya ikincisi çözer, ya üçüncüsü çözer, ya da hiçbiri çözmez
Biraz çabayla çözülebilecek bir sorunsa, ikinci denemede yani 6 saat içinde çözülme olasılığı %50’dir
Ve bir noktadan sonra sadece yapmak gerekiyor
İşi ayrıştırmak ve tahmin etmek neredeyse aynı şeydir. Ayrıştırma bitince, birkaç yıllık deneyimi olan birinin küçük işler için standart tahminleri vardır; bu yüzden her parçaya tahmin yapıştırması birkaç dakika sürer
Benim durumumda, işi tahmin edebileceğim parçalara bölerim; tahmin edemediğim yerlerde başkalarının fikrini alırım
Yine de ustalığa giden asıl yolun iş ayrıştırma olduğunu düşünmüyorum. Kötü bir ayrıştırma planı herkes yapabilir
Asıl ustalık, kanıtlar bu iş ayrıştırmanın sorun çıkaracak kadar yanlış olduğunu gösterdiğinde bunu fark etmek ve bunu iletmek ya da yeniden tahmin etmektir [0]
Ve bunun olacağını rahatça kabul etmek, bu yüzden en baştan değişme ihtimali yüksek bir takvim vermekten strese girmemek de önemlidir
Yöneticiler genelde baştan net bir yol haritası ister ama bu imkânsız olanı istemektir. İyi yönetimin esneklikte olduğunu ve zaman geçtikçe geliştirici öğrendikçe beklenen işin niteliğinin değiştiğini anlamakta yattığını düşünüyorum
Yazının sonundaki küçük örnek de düşünmeye değer. Biri tam bir tahmin, yani “uçak yolculuklarındaki şu kadar akşamda biter” demiş olsa bile, muhtemelen bunu fazla riskli bulup reddederdi
Bu da tahminin yalnızca doğruluk meselesi olmadığını gösterir. İçinde risk yönetimi, beklenti yönetimi, işe aşinalık gibi kelimelere tam dökülemeyen pek çok unsur vardır
[0] https://jacobian.org/2021/jun/8/incorrect-estimates/ - bu konu hakkında bir yazı da var
Bunlar iyi yeni yazılım çalışanları, ama alan onlar için yeni olduğunda temel işlevleri nasıl kuracaklarını gerçekten bilemeyebiliyorlar. Benim deneyimime göre öğrenebilecekleri ve başarabilecekleri işler istiyorlar ve bu onların gelişmesine katkı sağlıyor
Kesinlikle hatırlanması gereken şey, süreç maliyetinin takıma göre ayarlanan bir süreklilik olduğudur. NBA oyuncuları maç sırasında engelin üzerinden top atmayı öğrenmez ama ilkokul 3. sınıf çocukları öğrenir
Her iki planlama ve koçluk biçimi de kendi takımına uygun olduğunda yerindedir
Belki de bu yazılım mühendisliğinin temel gerçeğidir. Yazarın yapmaya çalıştığı Streak uygulamasının açık kaynak sürümü zaten vardır ve aslında tekerleği yeniden icat ediyor olabilir
Beyin galiba iş listelerini sevmiyor. Liste yapmak keyifli olabilir ama girişim kurmanın ya da kodlamanın büyük bölümü keşiftir
Ve iş listeleri keşfi engeller
Etmezseniz, yazılım geliştirmede farklı olan ne ki bizim mesleğimizde “bilmiyorum” makul bir cevap olabiliyor?
Bazen bu doğrudur, bazen değildir. “Harita, arazinin kendisi değildir”
İşi daha küçük işlere bölmek için yinelenen iş yapmak gerekir; püf noktası bunu en aza indirmektir
Hiç gereksiz iş yapmamaya çalışırsanız sonunda her şeyi tek seferde yapmak zorunda kalırsınız
Örneğin B’nin A’ya bağlı olduğu A ve B modüllerine sahip bir programı yeniden düzenlediğinizi düşünün. En az israfa yol açan yöntem iki modülü birlikte yeniden düzenlemektir. Ama bu aynı zamanda en riskli ve tahmin etmesi en zor yöntemdir
Bölme biçimi, A’yı refactor etmek ve B’yi refactor edilmiş A ile çalışacak şekilde uyarlamak. Sonra A’yı yeniden refactor ederseniz, daha önce yapılan bu uyarlama işinin kısa sürede çöpe gitme riski doğar
Çöpe gidecek işi sıfıra indirmek istiyorsanız, çoğu zaman işi parçalamak mümkün olmaz. 20 yıllık deneyimim olsa da ben hâlâ işi bölmek için sonradan atılacak geçici işler yapma konusunda sık sık tereddüt ediyorum
Bunun yerine birkaç haftalık bir iş yaparken, geride tek bir yak kılı bile bırakmadan hepsini birden tıraş etme tarzına kayabiliyorum
Başlamadan önce çözmeye çalıştığınız problemi düşünmek mantıklı ve kabaca dönüm noktaları da önemli. Ama çoğu durumda bilinmeyen bilinmeyenler o kadar fazla ki tamamen parçalamak ya hiç işe yaramıyor ya da imkânsız oluyor
Projeyi parçalamaya harcanan zamanı doğrudan çözümü bulmaya ya da inşa etmeye harcasaydım muhtemelen çok daha çabuk biterdi. En azından bana öyle geliyor
Ben genelde farklı yaklaşıyorum. Asıl amaç, en başta bunu yapıp yapmamaya karar verebilmek için gereken emeği tahmin etmek. Yani ilk neden, maliyet-fayda değerlendirmesine yardımcı olmak
Ekip için de çok faydalı olabilir. Özellikle daha az deneyimli insanlarla çalışırken işi çok sayıda parçaya bölüp paralelleştirebilirsiniz
Jacob da muhtemelen kendi Streak uygulamasını geliştirirken böyle bir ayrıştırmayı çok yapmamıştır; bu yüzden açıklama için özyinelemeli bir örnek vermiş gibi görünüyor
Böyle durumlarda daha küçük görevlere bölüp tek tek tamamlamak faydalı oldu. Böylece tıkanmış ya da çalışmak istemeyen bir halde olsanız bile ilerleme kaydediliyor ve bu ilerleme devam etmek için momentum yaratıyor
Yöneticilerin hızı tahmin edebilmesinin de kesinlikle bir değeri var. Ama bir kez buna alışınca “emin değiliz” sözünü gerçekten anlayamaz hâle gelmeleri sorun oluyor
Ben de danışmanım; bu yüzden “agile” çalışıyor olsak bile “bunu şu süre içinde teslim edeceğiz” diyebilmek çok önemli