50 yıllık yazılım geliştirme deneyiminden 63 ilham
50 yıldır teknoloji çemberinde yer alan geliştiriciler paha biçilmezdir.Bu makalenin yazarı Karl Wiegers, son 50 yılda 63 ders biriktirmiş ve paylaşmıştır. Sana ilham vermeyi umuyorum.
Yazar | Karl Wiegers, Çevirmen | Champagne Supernova
Editör | Tang Xiaoyin
Baş resmi | Oriental IC'den indirilen CSDN
Üretildi | CSDN (ID: CSDNnews)
Aşağıdaki çeviridir:
1970 yılında üniversitede ilk programlama dersini aldım (tabii ki FORTRAN okudum). Geçtiğimiz yarım yüzyılda, zamanımın çoğu yazılım işine harcandı: gereksinimler, tasarım, kullanıcı deneyimi, programlama, test, proje yönetimi, dokümantasyon yazma, lider süreç iyileştirme, 7 kitap ve çok sayıda makale yazma, Danışmanlık, eğitim.
Tabii ki bu süreçte organik kimyada doktora okumak (makalelerimin üçte biri bilgisayar kodları) ve birkaç yıl araştırmacı olarak çalışmak gibi bazı yan görevleri de tamamladım. Ama temelde, yazılım endüstrisinde bir insanım.
Bu kadar uzun bir süre boyunca, yazılım endüstrisi hakkında birçok bilgi biriktirdim. Bu yazıda sizlerle 63 ilham kaynağı paylaşacağım ve belki bunları benim kadar faydalı bulacaksınız.
Talep hakkında
1. Gereksinimleri anlamazsanız, projenin geri kalanını ne kadar iyi yaparsanız yapın, işe yaramaz ve sonunda başarısız olur.
2. Öğle yemeğinden sonra masanızda bulduğunuz post-it notları, kaydedilmiş sesli postalar ve e-postalar ve hatırladığınız koridordaki gündelik konuşmalar aldatıcıdır ve bunların tümü ihtiyaç olarak görülmez. Bu sadece bir grup bilgidir.
3. Tüm proje paydaşları için, çıkarların kesişmesi en çok Gereksinimler Sürecinde gerçekleşir.
4. Yüksek kalite gereksinimlerinin eksikliği varsa, paydaşlar nihai teslimat içeriğinden şaşırabilir. Yazılımda, Kazalar neredeyse her zaman kötü haberlerle eş anlamlıdır .
5. Gereksinimleri araştırırken, sadece mevcut kullanıcıları dikkate almayın. Eski müşterileriniz hala sizin müşterilerinizdir.
6. İnsanlar gereksinimleri sadece "toplamamalı". Talep edinme, sadece basit bir koleksiyon değil, bir keşif, işbirliği, keşif ve icat sürecidir. Bir iş analisti, bir yazardan daha fazlasıdır.
7. Talep edinmenin amacı, müşterinin ses-VOC'sini, müşterinin sesi-geliştiricinin-EOD'nin, geliştiricinin kulağına mümkün olduğunca yakın hale getirmektir. İş analistleri iletişim boşluğunu kapatmaya yardımcı olur.
8. Talep edinimi için insanlar genellikle iki yöntem umarlar: "telepati" ve "basiret". Bunların ikisi de işe yaramaz.
9. Kültürümüzün iddia ettiği şey ne olursa olsun, müşteriler her zaman haklı değildir. Ancak müşterinin her zaman kendi görüşü vardır ve bu görüşü anlamalı ve saygı duymalısınız.
10. Gereksinim geliştirme, yineleme gerektirir. İlk tartışmada tüm gereksinimleri almayı bekleyemezsiniz; bunları asla tam olarak alamayacağınızı bilin. Etkili gereksinim geliştirme, ayrıntı ve netlikte kademeli iyileştirmeleri içerir.
11. Gereksinimleri kaydetmekten korkmayın. Bilgi edinme maliyeti ile karşılaştırıldığında, bilgi kaydetme maliyeti çok düşüktür.
12. Gereksinimlerde tanımlanmamış bir işlev veya özellik varsa, hiç kimse bunu üründe görmeyi beklemez.
13. Gereksinim geliştirmenin çıktıları yalnızca bir dizi yazılı gereksinim değil, aynı zamanda bir fikir birliği ve tutarlı beklentilerdir.
14. Gereksinim geliştirme için daha pratik hedef, yaratılan gereksinimlerin ne kadar mükemmel olduğu değil, takımın kabul edilebilir bir risk seviyesi ile inşa etmesini sağlayacak kadar yaratılan gereksinimlerdir. Risk, ihmal edilmiş, gereksiz, eksik, belirsiz veya yetersiz iletilmiş çıktı talebi nedeniyle çok fazla plansız yeniden çalışmanın yapılması gerektiği durumda yatmaktadır.
15. Bazen ihtiyaçlarımızı daha gelişigüzel ifade ederiz çünkü okuyucuların bizimkine benzer bir "rasyonel filtre" ye sahip olduğunu varsayarız, ancak insanlar genellikle aynı ifadeyi farklı şekillerde yorumlar. Bu belirsizlik, beklentilerde ve beklenmedik teslimatlarda uyumsuzluklara yol açabilir.
16. Gereksinimler stüdyosunu ve inceleme ekibini küçük ölçekte tutun. Büyük bir grup insan, belirli bir gerekliliğin ifade edilmesi bir yana, ateşli bir odadan çıkıp çıkmamaya karar veremez.
17. Birisi yeni bir gereklilik öne sürdüğünde, sorulacak ilk soru şudur: "Bu bizim tartışmamızın kapsamına girer mi?" Eğer öyleyse, çözülmelidir. Değilse, o zaman çözülmemiştir veya en azından şimdi değil. Ancak, yanıt "Hayır, ancak bu konuya dikkat etmeliyiz" ise kapsamı buna uyacak şekilde ayarlamanız gerekir. Bunun maliyet, program, kaynaklar, katılım, öncelik ve fayda uzlaşması üzerinde etkisi vardır.
18. Belgelenmiş ve üzerinde anlaşmaya varılmış bir proje kapsamınız yoksa, kapsam bulaşması yaşayıp yaşamadığınızı nasıl anlayabilirsiniz?
19. Bir ürüne veya yinelemeye hangi özelliklerin dahil edileceğine karar verirken, "desibel önceliği" uygulamasından kaçının (yaygın olarak gürültü ile ayırma olarak bilinir). En gürültülü müşteriler tarafından talep edilen özellikler, işletme açısından her zaman en önemli özellikler olmayabilir.
20. Proje paydaşları, olası ihtiyaçları tartışmakla bunları ürüne dahil etmeyi taahhüt etmek arasında bir fark olduğunu anlayabilmelidir.
21. Bunları duyduğunuzda dikkatli olmanız gereken iki terim vardır: "varsayılan talep" ve "üstü kapalı talep". Talep beklentilerini net bir şekilde iletmeye çalışın.
Proje yönetimi hakkında
22. "Proje yönetimi" belirli bir faaliyet anlamına gelmez. Proje yönetimi, personel yönetimi, talep yönetimi, risk yönetimi, fırsat yönetimi, beklenti yönetimi, taahhüt yönetimi, değişiklik yönetimi, kaynak yönetimi ve tedarikçi yönetiminin bir karışımıdır.
23. Neden bazı şirketlerin iyi bir yazılım yapmak için hiç zamanları olmamakla birlikte, bunu telafi etmek için her zaman zaman, para ve insan gücü harcayabilirler? Bu bir muamma.
24. Herkes takımının en iyi yeteneklere sahip olduğunu düşünmeye isteklidir, ancak gerçek şu ki, yazılım geliştiricilerin yarısı ortalamanın altında yeteneklere sahiptir. Peki bu insanlar nerede çalışıyor?
25. Kimseyi hafife almayın. Biri sizden değerlendirmenizi isterse, en uygun cevap: "Önce düşüneyim ve sonra sizinle iletişime geçeyim."
26. Başkaları size ne kadar baskı yaparsa yapsın, yerine getiremeyeceğiniz sözler vermeyin.
27. İkna edici verileriniz varsa ve karşı taraf neredeyse hiç veriye sahip değilse, müzakerede bir avantaja sahip olacaksınız.
28. Değerlendirmeyi kaydetmez ve gerçekte olanla karşılaştırmazsanız, her zaman tahmin ediyor olacaksınız, değerlendirme yapmayacaksınız.
29. Karşınızdaki kişinin iyi şeyleri dinlemeyi sevdiğini düşündüğünüz için birisine ilişkin değerlendirmenizi etkilemeyin.
Kalite ve süreç iyileştirme hakkında
30. Yazılım kalitesi ile ilgili olarak: Bana şimdi ödeme yapabilir veya daha sonra ödeyebilirsiniz, ancak daha fazla ödemek zorundasınız.
31. Mükemmeli hedefleyin; mükemmelliğin peşinden gidin.
32. Asla patronunuz veya müşteriniz tarafından kötü şeyler yapmaya ikna edilmeyin.
33. Kalite, önceliğiniz olmalıdır. Yüksek kalitenin doğal sonucu, önemli üretkenliktir çünkü ekibin yeniden çalışma için çok fazla zaman harcamasına gerek yoktur.
34. Bir müşterinin değil, bir meslektaşın kusurları bulmasına izin vermeye çalışın. Akran teknik incelemesi, kaliteyi ve üretkenliği artırabilen etkili bir tekniktir.
35. Eğer ilgilendiğiniz insanlar mantıksız ise, yazılım mühendisliği becerileri işe yaramaz.
36. İnsanlardan çalışma şekillerini değiştirmeleri istendiğinde, içgüdüsel tepkileri "Bunun benim için ne faydası var?" Diye sormaktır. Ama aslında bu soru yanlıştır. Doğru soru, "Bu, ekibimize nasıl fayda sağlar?" Olmalıdır.
37. Yazılım geliştiriciler her zaman harika araçlar ararlar, ancak küçük bir aptalın ancak araçlara sahip olduktan sonra büyük bir aptal olacağını lütfen unutmayın.
38. Mevcut çalışma şeklinin neden olduğu sıkıntılı noktaları insanlar anlamadıklarında süreç değişiklikleri yapmak zordur. Tıpkı insanlar evlerinde fare olduğunu bilmiyorlarsa, onlara daha iyi fare kapanları satmak zordur.
39. Soru: Ampulü değiştirmek için kaç yazılım süreci liderine ihtiyaç var? Cevap: Sadece bir tane gereklidir, ancak esas olan ampulün değiştirilmeye istekli olması gerektiğidir.
40. Yeni bir çalışma tarzına doğru gelişme sürecinde, organizasyon kültürünü değiştirmenin gerekliliğini ve zorluğunu küçümsemeyin. Yeni bir süreci uygulamak, yeni bir kültürü aşılamaktan daha hızlıdır. Her iki alanda da başarılı olmanız gerekiyor.
41. İyi niyetli olsun ya da olmasın, iyileştirme planları eyleme dönüştürülemezse yardımcı olmayacaktır.
42. Çoğu durumda, sağduyu, sağduyu ve deneyim resmi prosedürlerden daha önemli olmalıdır. Ancak, bazen bu program iyi nedenlerle mevcuttur. Atlamaya karar vermeden önce araştırmanız gerekir.
43. Kuruluşun yeni çalışma yöntemlerini benimsemesine liderlik ederken, lütfen nazikçe baskı uygulamaya devam edin.
44. İnsanların çalışma şekillerini değiştirmeleri için en iyi motivasyon acıdır. İnsan yapımı, dışarıdan empoze edilen bir acı değil, mevcut çalışma şeklinin takıma getirdiği gerçek acı. Nihayetinde ağrıyı dindirecek iyileştirme aktiviteleri seçin.
45. Gözden geçirmeye, dersleri öğrenmeye ve ekibin süreçlerini sürekli iyileştirmeye zaman ayırmadığınız sürece, bir sonraki projenin öncekinden daha iyi olmasını beklemek için hiçbir neden yoktur.
46. Her şeyi aynı anda değiştiremezsiniz. En fazla faydayı sağlayabilecek süreç değişikliklerini belirleyin ve bunları önümüzdeki Pazartesi uygulamaya başlayın. Şaka yapmıyorum: önümüzdeki Pazartesi!
47. Belge şablonlarına "sığacak şekilde küçült" kavramını benimseyin. Hangi bilgilerin dahil edilebileceği hakkında daha fazla düşünmenizi hatırlatmak için zengin bir şablonla başlayın ve ardından bunu her projenin ölçeğine, doğasına ve ihtiyaçlarına göre yeniden şekillendirin.
48. Çoğu takımın daha azıyla daha fazlasını yapması gerekir. Bununla birlikte, normal şartlar altında, daha azıyla daha fazlasını yapmanın bir yolu yoktur. Verimliliği ve etkinliği artırmak için uygun bir eğitim ve süreç iyileştirmesi yoksa, daha yüksek üretkenliğin kendisini inanılmaz bir şekilde göstermesini beklemeyin.
49. Aynı ofiste çalışan dört kişi için geçerli olan gayri resmi süreç, farklı kıtalarda çalışan birden çok geliştirme ekibine genişletilemez.
50. Yazılım endüstrisinde tekrarlanabilir bir şey varsa, aynı aptalca şeyi her projede tekrar tekrar yapmaktır. Geriye dönük olarak öğrenmeniz, anlamanız ve sürekli olarak gelişmeniz gerekir.
51. İnsanlar yerleşik süreci takip etmediklerinde, yalnızca üç seçeneğiniz vardır: (1) İnsanların süreci izlemeye başlamasına izin verin; (2) Süreci daha etkili ve pratik hale getirmek için ayarlayın ve ardından insanların onu takip etmesine izin verin; (3) Süreci bırakın Ve bu süreci izliyormuşsun gibi davranmayı bırak.
Diğer bilgiler
52. Yapay zeka gerçek şeylerin yerini alamaz.
53. Teknoloji dünyasında, diğerlerinden bir hafta öndeyseniz, o zaman önemli birisiniz.
54. "Hemen yapılması gereken" bugünün geliştirme projeleri, yarının eski sistem bakım kabusu haline gelecektir.
55. Yazılım sistemindeki birçok problem arayüzde ortaya çıkar: yazılım ve yazılım, yazılım ve donanım, yazılım ve insanlar, insanlar ve insanlar. Bu arayüzlerin dikkatlice incelenmesi gerekir.
56. İnsanlar her zaman "hakları" hakkında çok fazla konuşurlar. Her hakkın diğer tarafı sorumluluktur. İşbirlikçi bir zihniyetle düşünün ve hareket edin.
57. Bir ons tasarım, bir pound yeniden inşaa eşdeğerdir.
58. "İş haftası yönetimi yaklaşımı" na dikkat edin - sadece birisi vaat ettiği mükemmel sonuçları okuduğu için, yazılım geliştirmedeki en yeni şeyleri benimsemek için acele ediyorlar.
59. Başparmağınız ile işaret parmağınız arasında bir inçlik bir mesafe bırakın. Çoğu durumda, kalite ve çöp arasındaki tek fark budur. Biraz daha dinleyin, çalışmanızı kontrol edin, testi tekrar çalıştırın, listeye bakın, talimatları okuyun ve bir soru daha sorun. Genellikle çöpü iyileştirmenin tek yolu budur.
60. Yazılım uygulayıcılarının daha önce yaptığı hataları yapacak vaktiniz yok. Literatürü okuyun ve saygı gösterin. Meslektaşlarınızdan öğrenin. Bilginizi başkalarıyla cömertçe paylaşın.
61. Bilgisayar teknolojisi, yazılım geliştirmenin% 50'sini oluşturabilir ve geri kalan% 50 iletişimde yatar. Ancak iş analizi tamamen iletişimle ilgilidir. Bilgi işlemde daha fazlasını hesaba katmalıyız.
62. Kendi başınıza bağımsız bir danışman veya yüklenici olmak istiyorsanız, müsait olduğunuzu dünyaya ilan etmeniz gerekir. Kimse sizi tanımıyorsa, iş becerinizin ne kadar iyi olduğu önemli değildir.
63. Yazılım endüstrisinde sık sık rol yaparız. İş hedeflerini anlayan ve ihtiyaçlarını anlayan doğru paydaşları bulduğumuzu varsayıyoruz. Doğru ihtiyaçları bize iletecek doğru kişi gibi davranırız ve bunu anlar ve doğru bir şekilde kaydederiz. Değerlendirmemizin doğru olduğunu ve gerekli tüm görevleri dikkate aldığımızı varsayıyoruz. Projemize zarar verebilecek tüm risklerin gerçekten ortaya çıkmayacağını iddia ediyoruz. Rol yapmayı sevmiyorum. Bazen gerçeklikten pek hoşlanmam ama gerçeklikten başka hiçbir şeyim yok, bu yüzden onunla yüzleşmek zorundayım. Rol yapmayı bırakalım.
İngilizce: 50 Yıllık Yazılım Deneyiminden 63 Ders
Orijinal: https://medium.com/swlh/62-lessons-from-50-years-of-software-experience-2db0f400f706
Yazar hakkında: Karl Wiegers bir yazardır.Yazılım geliştirme ve yönetimi, danışmanlık, kişisel gelişim, kimya ve askeri tarih gibi konuları kapsayan yazıları, şu anda şüpheli bir roman yazmaktadır.
Çevirmen: Şampanya Süpernova
Bu makale bir CSDN çevirisidir, lütfen yeniden basımın kaynağını belirtin.
