Un proiect reprezintă un efort temporar asumat în vederea obținerii unui produs, serviciu sau rezultat unic [1]. Caracteristica aceasta de unicitate a rezultatului implică un anumit grad de incertitudine în ceea ce privește derularea activităților și, inclusiv, un anumit nivel de risc. Cu cât gradul de incertitudine este mai mare, cu atât proiectul este mai fragil, mai predispus la eșec. De aceea, în managementul clasic, o bună parte din activitatea de management al unui proiect se focusează pe identificarea, măsurarea, monitorizarea, diminuarea și eliminarea riscurilor. Pe de altă parte, metodologiile Agile folosesc mecanisme ce conduc indirect la controlul riscurilor fără însă a propune practici explicite de eliminare a incertitudinii. Cu toate acestea (sau poate tocmai din această cauză), simțim de multe ori că ne aflăm constant pe nisipuri mișcătoare și că proiectul pare scăpat de sub control. Sunt acestea semne ale fragilității proiectului? Părerea mea este că nu și voi încerca să demonstrez acest lucru de-a lungul următoarelor secțiuni.

Toata lumea vorbește despre vehicule autonome, dar vehiculele electrice nu primesc atenția necesară. Schimbările pe care mașinile electrice (EV) le vor aduce sunt semnificative și importante pentru viața noastră de zi cu zi. Din punct de vedere economic, schimbarea spre EV va aduce creștere economică la o scară globală.

În dezvoltarea sistemelor software, metodologiile seriale de management a proiectelor au fost înlocuite treptat de abordări mai adaptabile, bazate pe paradigma „prototipează – testează (cu utilizatorii) – evaluează – învață – rafinează” (PTEIR / PTELR). În fapt, algoritmul PTELR a fost translatat în urmă cu 20 ani într-o filosofie nouă a procesului de dezvoltare software, articulată într-un set de 14 principii, denumită „agile manifesto”. Principiile au fost mai apoi „traduse” de experți într-o serie de metodologii practice de management de proiect, cunoscute sub numele de „metodologii agile”. Printre formulele lucrative ale metodologiilor agile se numără SCRUM și Kanban.

Îmi place înotul la nebunie. Și mă descurc destul de bine. Dacă nu mă credeți pe cuvânt, am niște povestioare interesante pe pagina de facebook legate de acest subiect. Ani de zile am înotat și am trăit cu impresia că devin tot mai bun. Până când într-o zi mi-am zis: E momentul: azi, înot fluture. Am intrat în bazin și m-am împins cu putere în margine. Am alunecat rapid înainte și brațele au ieșit din apă simetric, elegant. Au intrat în același timp în apă în fața mea într-un sincron perfect. Corpul s-a unduit și a continuat mișcarea brațelor desenând un S demn de invidiat. Poezie în mișcare, nu altceva. Sau cel puțin așa mi-am imaginat eu că se va întâmpla. În realitate, brațul drept s-a izbit de apă undeva în lateral-față la 45 de grade, brațul stâng n-a trecut de umăr și corpul meu se unduia în vreo trei S-uri perfecte, în toate direcțiile. După șapte bătăi din brațe am tras la mal, epuizat. Eram în dreptul scării, așa că am ieșit să mă odihnesc. Înaintasem cam patru metri. Cu tot cu avânt. Ca să vă faceți o idee, un înotător decent ajunge din șase sau șapte bătăi la mijlocul bazinului. Ce m-a determinat să cred că doar înotând “la liber” voi progresa într-un an câți alții în șapte? Sau că am să pot deprinde tehnici noi din zbor? Același motiv care împinge echipele de Scrum să livreze iterație după iterație și să creadă în progres, învățare și creștere a eficienței de cele mai multe ori fără a se baza pe date și metrici adecvate care să conducă progresul.

Totul a început cu o revelație, în momentul în care un coleg dezamăgit de companie, care era pe punctul de a o părăsi, m-a întrebat: “Tu de ce mai ești aici?” M-a pus pe gânduri, căutând un răspuns onest, scurt și rațional. Aceasta m-a determinat să îmi evaluez propriile valori și principii. Colegul despre care vă spuneam este și în prezent în compania respectivă.

Tendința ce se prefigurează în viitorul apropiat, pentru majoritatea firmelor de IT, se bazează pe ideea de a muta resursele în cloud. Pentru cei ce lucrează în sectorul IT, acest lucru înseamnă eliminarea multor probleme cu care se confruntă companiile ce folosesc multe tipuri de hardware și software de la furnizori diferiți.

Care sunt problemele și provocările programatorilor? Ce cărți citesc? Cum reușesc să se adapteze metodologiei Agile dar și tehnologiilor aflate în continuă schimbare ? Sunt câteva din întrebările la care am încercat să găsim un răspuns în panelul de discuții Today Software Magazine. Partenerii de discuții au fost:

• Claudiu Iluțiu-Varvara - Software Arhitect .NET (Siemens Romania R&D)

• Claudiu Arseniu - Senior Java Developer (Siemens Romania R&D)

• Daniel Jecan - Technology Researcher (jpard)

• Dan Săbădiș - Team Lead (SDL)

Mike Butcher: Talentul de aici este fantastic. Totuși, ceea ce tinde să se întâmple, este un focus redus pe produs ca parte a activității curente. Nu este vina nimănui. Managerii de produs cu adevărat extraordinari există pe piețele mai dezvoltate și mai mari. Atât la nivel enterprise, cât și la nivelul pieței de consumatori, tindem să găsim cei mai buni oameni pe piețele mari, deoarece tipul acesta de muncă este esențial pentru acestea. Restul piețelor sunt mai fragmentate. Această problemă poate fi rezolvată prin creșterea vizibilității. Există întâlniri precum Product Tank, destinate managerilor de produs din toată lumea. Accentul pus pe produs este în mare parte o cauză a problemei.

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

Un exercițiu de imaginație prin care devenim personajul principal în seria James Bond, (adică ,,Bond. James Bond”), ne poate facilita înțelegerea optimă a complexului domeniu al criptografiei. Așadar... Suntem în pielea lui James Bond pentru câteva minute. Am primit dosarele a două personaje deosebite, Alice și Bob. Aceștia sunt suspecții care au mereu ceva de ascuns și se fac nevăzuți când cineva e pe urmele lor. După eforturi considerabile, am reușit să interceptăm canalul lor de comunicare, iar acum avem acces la discuțiile lor. Trebuie să aflam ce pun la cale, dar înainte, haideți să punem problema în context.