Blog
CTO jako kovboj. Jak zavést standardy kódu v rostoucím týmu
První měsíce a roky startupu jsou často směsicí rychlého vývoje, intenzivního soustředění a zdravé dávky chaosu. Když jste malý, dravý tým, který se často sestává jenom z CEO a CTO, rychlost je klíčová k tomu, abyste nalezli shodu produktu s trhem (product-market fit) je prvořadý.
Jak na technický dluh: strategie pro udržitelný vývoj
Technický dluh (z anglického technical debt) definoval Ward Cunningham v roce 1992. Použil metaforu z finančního světa. Ve finančním světě si půjčíte peníze a počítáte s tím, že je někdy splatíte. Po dobu výpůjčky vám z půjčených peněz běží úrok a vy musíte vracet půjčenou částku i s úrokem. Když máte půjčeno na dlouhou dobu a nesplácíte, tak úroky nabíhají a dluh tím narůstá.
User Story Mapping na TestCrunch 2024
26.3. 2024 jsem měl možnost pořádat workshop User Story Mapping v rámci konference TestCrunch. Workshopu se účastnilo 25 účastníků z 18 firem a konal se v prostorách firmy SolarWinds v Brně.
CZ Dev Radar
Velký průzkum technik používaných v českých softwarových firmách zvaný “CZ Dev Radar” měl za cíl zmapovat, jaké nástroje, metody a technické a manažerské postupy se používají při vývoji software v Česku v roce 2024.
Opravdu potřebujete druhý produkt?
Mnoho firem při svém růstu dospěje do bodu, kdy jejich produkt se prodává dobře a začnou uvažovat o tom, že začnou vyvíjet další produkt. Jak ale poznat, že je ta správná chvíle? A záleží vůbec na tom, jestli budu mít dva produkty nebo jen jeden? Záleží a hodně.
Software bez chyb - Test-Driven Development
V posledním článku jsme si řekli, proč vznikají chyby v softwaru a čemu se vyhnout, abyste chyby nevznikaly. Víme, že odstranění chyb bude tím účinnější, čím blíže bude k tzv. bodu ovlivnění. Jednou z technik, které ovlivňují kód už při jeho vzniku je Test-Driven Development, neboli programování řízené testy.
Software bez chyb - proč vznikají chyby
Možná jste už slyšeli o tom, že existují firmy, které vydávají software bez chyb. Možná jste už dokonce četli nějaké případové studie. Když to tedy jde, proč to nedělají všichni? Proč tolik softwarových firem vydává svoje produkty s chybami a způsobují tím frustraci svých zákazníků a programátorů, kteří předávají nekvalitní produkt zákazníkům jen velmi neochotně a pod manažerským tlakem.
V čem je týmové programování lepší než pull requesty
Mnoho softwarových firem dnes používá pull requesty v té podobě, jak je zavedl github, jako standardní mechanismus pro sdílení informací o kódu mezi vývojáři. Typicky: programátor Jirka píše kód celý den (dejme tomu 5 hodin čistého času) a až mu připadá, že je “hotov”, pošle kód jinému programátorovi, Ondrovi, k revizi. Věnuje tomu většinou řádově kratší čas, dejme tomu půl hodiny neboli 10%.
