Cum ne raportăm azi la ideea de Craftsmanship din perspectiva folosirii IA și care sunt noile strategii de dezvoltare de produse sunt câteva din problemele dezbătute împreună cu invitații noștri:

• Adrian Moldovan - Head of AI & Automation Solutions,

• Alin Turcu - Data & AI Engineering Director @ Cognizant,

• Marian Gradea - Development Manager @ Banca Transilvania.

În ultimii ani, rolul de QA a depășit de mult zona clasică de „testare”. Un QA modern nu mai validează doar funcționalități, ci navighează constant între requirements, acceptance criteria, buguri, automatizare, raportare și comunicare cross-team. De multe ori, timpul petrecut efectiv testând este mai mic decât timpul petrecut reconstruind contextul din jurul testării. Provocarea care apare este volumul de context care trebuie urmărit simultan: Jira, Confluence, Slack sau Teams, browser, logs, pipeline-uri CI/CD și frameworkuri de automatizare. Într-o singură zi, aceeași persoană poate ajunge să analizeze/scrie documentație, să investigheze un bug, să execute scenarii manuale, să repare/scrie teste automate și să centralizeze rezultatele pentru restul echipei. Uneori, pe mai multe medii. Toate fac parte din același proces, dar cer moduri diferite de gândire.

Publicat în Numărul 167 Citeşte mai mult

Modelele semantice au rolul de a face datele mai ușor de consumat prin Business Intelligence (BI). În Microsoft Fabric, ele devin baza pentru o utilizare mai largă a datelor, inclusiv de către sisteme automate. Articolul analizează cum modelele semantice, Semantic Link, Fabric IQ și Data Agents formează o arhitectură guvernată și reutilizabilă. Folosind un limbaj de business bine definit și componenta de artificial intelligence, se obține operaționalizarea unui raționament consecvent. Scopul articolului este de a clarifica ce este posibil astăzi, ce se află în evoluție și de ce semantica devine critică pentru BI și AI.

Publicat în Numărul 167 Citeşte mai mult

Dacă echipele de produs ar înțelege cu adevărat utilizatorii, cercetarea în domeniul UX aproape că nu și-ar mai avea rostul. Nu am avea nevoie de interviuri cu utilizatorii, teste de utilizabilitate, journey mapping, analiză comportamentală, prototipare iterativă sau bucle continue de validare. Deciziile ar putea fi luate într-un mod firesc pe baza experienței, intuiției sau a unor convingeri proprii. Doar că realitatea ne arată, din nou și din nou, exact contrariul: echipe întregi construiesc funcționalități pe care nimeni nu le folosește, anumite interfețe sunt simplificate până în punctul în care anumite taskuri devin – paradoxal – mai greu de realizat, roadmapurile de produs se aglomerează cu presupuneri ambalate drept nevoi reale ale utilizatorilor. Iar distanța dintre ceea ce cred echipele că își doresc utilizatorii și ceea ce aceștia au nevoie, de fapt, este adesea mult mai mare decât am vrea să recunoaștem.

Nu este o noutate pentru nimeni că dezvoltarea software a fost schimbată permanent de instrumentele de IA pentru generarea de cod. Sunt, fără exagerare, cel mai mare salt de productivitate pe care l-am văzut în cariera mea și cred cu tărie că pot fi folosite în avantajul nostru. Dar tocmai pentru că sunt atât de eficiente, viteza pe care o oferă poate scăpa ușor de sub control.

Publicat în Numărul 167 Citeşte mai mult

Când lucrezi cu colegi din trei țări, pe două continente și trei fusuri orare, fiecare zi începe cu aceleași întrebări: ce s-a întâmplat peste noapte, cine preia mai departe, unde sunt blocajele și cum păstrezi un ritm comun de lucru între locații care nu împart același program, același context și, uneori, nici același mod de lucru. În astfel de echipe, organizarea nu mai este doar un avantaj, ci o condiție de funcționare.

Publicat în Numărul 167 Citeşte mai mult

Producerea unor release notes corecte și consecvente într-un mediu de producție modern este surprinzător de dificilă. Echipele de dezvoltatori gestionează în mod obișnuit patru sau mai multe sisteme deconectate: Jira pentru urmărirea sarcinilor, GitHub Enterprise pentru pull requesturi, baze de date Oracle pentru modificări de schemă și Confluence ca destinație canonică de publicare - fără niciun instrument care să le integreze simultan. Rezultatul este un proces manual, predispus la erori, care întârzie lansările, produce documente inconsistente și consumă timp prețios de dezvoltare cu muncă de rutină. Acest articol prezintă Release Notes Automation, un lanț intern de instrumente care elimină complet acest proces, bazat pe o arhitectură pe trei layere: un generator CLI în Java 17, microservicii Spring Boot de tip MCP(Model Context Protocol) și un Wizard de introducere a datelor găzduit pe GitHub Pages.

Publicat în Numărul 167 Citeşte mai mult

Discuția despre IA în software development ajunge inevitabil la aceeași întrebare: va mai fi nevoie de dezvoltatori? Experiența noastră cu Spec Kit arată că întrebarea este greșit formulată. Nu dezvoltatorul dispare, ci se schimbă locul în care acesta aduce valoare: mai puțin în scrierea manuală a codului și mai mult în definirea corectă a problemei.

Publicat în Numărul 167 Citeşte mai mult

În multe companii, cele mai valoroase informații se află într-un PDF uitat într-un folder partajat. Proceduri, rapoarte, contracte, specificații tehnice sau documente de conformitate conțin răspunsuri importante, însă accesul la ele depinde adesea de structura arhivelor interne, de denumiri de fișiere, de versiuni păstrate în paralel și de memoria oamenilor care știu „unde trebuie căutat”. Informația există, dar nu este întotdeauna pregătită pentru a fi folosită în mod sistematic.