Știați că 457 de milioane de oameni sunt supraponderali și, în total, transportă 2,3 milioane de tone de grăsime în exces! Un studiu realizat de The Economist a constatat că dimensiunea a 14 pantaloni pentru femei în Marea Britanie este cu 10 cm mai mult la talie decât în ​​1970. Numărul actual 14 este la fel de mare ca și 18 anterioare, iar 10 este egal cu 14 ani în urmă. Producătorii înțeleg că femeile se vor simți mai bine (și au mai multe șanse să cumpere) dacă pot „obține” aceeași sumă ca în tinerețe.

scăpați

Nina Prodanova-Yotseva, Managing Partner, ITCE

Datele privind obezitatea în Bulgaria, deși ușor mai bune decât în ​​Marea Britanie și SUA, sunt de asemenea șocante - 50,6% dintre bulgarii peste 18 ani sunt supraponderali.

Nu este un secret că atunci când vine vorba de diete, majoritatea sunt înșelătoare. Puteți pierde mult în greutate doar pentru a vă vedea revenirea în greutate.

Chiar și în ultimii 15 ani, statisticile sumbre privind obezitatea au fost relativ constante.

Există un mod universal de lucru pentru a face față obezității. Luați, de exemplu, Japonia, unde doar 1,5% din populație este obeză. Ai cunoscut un chinez gras sau un suedez? Vă pot asigura că puteți mânca de 6 ori pe zi și nu aveți un gram de grăsime.

Ce legătură au toate acestea cu proiectele IT?

În 1970, Winston Royce a definit formal Waterfall sau ciclul de viață secvențial al proiectelor. Se bazează pe modelul de producție a mașinilor, în care fazele sunt clare și schimbările sunt foarte dificile. Cascada înseamnă să detaliați toate cerințele complet înainte de a trece la proiectarea completă, urmată de netezire completă, testare și acceptare, iar începutul fazei următoare se face după finalizarea completă și acceptarea formală a rezultatelor celei anterioare.

În ultimii 15 ani, companiile au introdus treptat reglementări interne pentru proiecte în locul haosului anterior, bazându-le pe cascadă. Problema este că și-au făcut metodologiile prea definitive și au introdus prea multe cerințe documentare fără prea mult spațiu pentru variații. Acest lucru a format treptat o grămadă semnificativă de documente inutile sau activități de proiect, care le îmbolnăvește.

Statisticile privind proiectele eșuate în lume rămân în permanență în intervalul 30-70%, ceea ce arată că cascada tradițională pe scară largă, care merge împreună cu contractele cu preț fix, nu a dat rezultate satisfăcătoare în ultimii 15 ani.

Excesul de grăsime

Iată câțiva dintre principalii factori care măresc „greutatea” proiectelor:

Planuri și evaluări detaliate - sunt atât de departe de momentul implementării, încât cu siguranță se schimbă de multe ori.

30% din specificațiile detaliate nu sunt de fapt implementate sau deloc utilizate - suntem paralizați în analiză și ne este frică să trecem la faza următoare până când clarificăm toate detaliile. Apoi realizăm o medie de 70% din specificații și se folosește doar 64%.

Remodelare - dacă facem ceva prea nou pentru client, acesta nu poate să știe ce vrea la început și să aducă modificări soluției terminate.

Așteptări lungi pentru aprobări de specificații atunci când proiectele sunt oprite.

Rapoarte de stare lungi neclare pentru client - sunt raportate sarcini tehnologice care nu spun prea multe afaceri.

Acestea sunt defecte inerente în abordarea cascadei, pe care companiile o atacă adesea cu mai multe detalii despre proces și mai multe formulare de completat, dar statistici persistente nesatisfăcătoare pentru mai mult de un deceniu dovedesc doar că este necesară schimbarea.

Un mare imbold pentru îmbunătățirea proiectelor IT este dat de conceptul de producție Lean, introdus pentru prima dată în industria automobilelor din Japonia în anii optzeci, al cărui principiu principal este eliminarea acțiunilor nevrednice fără sens în producție.

Lean este o filozofie care se concentrează pe minimizarea deșeurilor. Lean înseamnă slab, atletic, fără exces de grăsime.

Cum să slăbești în proiecte?

O modalitate dovedită este trecerea de la cascadă la un mod adaptiv în proiecte IT precum SCRUM și Lean și prin aplicarea unor tehnici precum Kanban sau o combinație a tuturor. Putem economisi cascada pentru cazurile pentru care este cu adevărat adecvată - numai atunci când cerințele pot fi într-adevăr detaliate la începutul proiectului. Abordările adaptative transformă tot ceea ce obișnuim să dăm peste cap, dar garantează un rezultat rapid și de calitate și nu este dificil de implementat.

Iată contribuția incontestabilă a sistemului de producție Toyota și abordarea Kanban introdusă de Taiichi Ohno (1988). Minimizați disponibilitatea, astfel încât cantitățile din fabrică să fie livrate la punctul de utilizare chiar înainte de a fi efectiv necesare. Toyota cercetează magazinele alimentare americane și își adaptează metoda de realimentare. Tehnica lui Ono este cunoscută sub numele de producție just-in-time (JIT). A face lucrurile în avans este o risipă de efort. Fă-le exact atunci când ai cu adevărat nevoie de ele. Acesta introduce ca mecanism pentru JIT - placa vizuală Kanban cu hărți care sunt semnale de acțiune în proces.

Companiile americane de software precum Microsoft și Yahoo au adaptat Kanban la producția de software din 1988.

Cel mai rapid mod de a înțelege Kanban este de a lua exemplul reședinței împăratului japonez din Tokyo - o atracție turistică extrem de populară. În timpul sărbătorilor sau în weekend, mii de oameni vor să viziteze palatul. Dar conducerea complexului a decis la ce număr maxim de vizitatori, sentimentul lor nu va fi stricat. La reședință, ei folosesc Kanban ca metodă de control al încărcăturii. Un angajat al complexului distribuie fiecărui vizitator un card de plastic, care trebuie returnat la ieșire. Numărul maxim de vizitatori este atins atunci când cardurile de plastic se epuizează. În acest caz, cardul are un simbol de capacitate vizuală.

Exemplu ilustrativ de Kanban în IT

Coloanele plăcii (Fig. 1) sunt faze în care poate fi găsită o funcționalitate sau un defect. Kanban nu definește fazele sau regulile pentru trecerea de la o fază la alta, ci limitează doar fizic numărul de sarcini pe care le puteți avea într-o fază dată în funcție de capacitatea resurselor. Scopul este de a limita Work In Progress. Un efect direct al acestui fapt este creșterea sarcinilor efectuate, precum și claritatea timpului de execuție. Un detaliu important este că Kanban nu face o estimare preliminară a timpului necesar, deoarece acest lucru nu adaugă valoare în acest caz.

Dar permiteți-mi să vă prezint procesul pas cu pas.

Dezvoltatorii anunță câte posturi vacante au în prima fază (fie că este vorba de analiză, proiectare sau altceva);

Afacerea acordă prioritate sarcinilor din coadă;

Sarcinile sunt lipite în coloana corespunzătoare. În partea de jos a coloanei sunt criteriile pe care o sarcină trebuie să le îndeplinească pentru a trece la o altă fază. Culorile pliantelor definesc un alt tip de sarcină - de exemplu: funcționalitate albă, roz întreținere, defect albastru.

SCRUM - mai multe idei

Istoria SCRUM poate fi urmărită în 1986, când Harvard Business Review a publicat un articol intitulat „Proces de dezvoltare produs nou, nou” care descrie modul în care Honda, Canon și Fuji-Xerox produc produse de clasă mondială. SCRUM este prezentat ca un stil de management de proiect. În 1995, Ken Schwabber a oficializat regulile SCRUM pentru producția de software. SCRUM nu este un acronim, ci un termen preluat din rugby (tradus ca „corp la corp”).

SCRUM se bazează pe câteva principii simple:

Interacțiune - comunicarea reciprocă a statutului și interacțiunea strânsă a managerilor de produs/analiștilor de afaceri și a clientului este esențială pentru evoluția cerințelor și pentru soluționarea rapidă a problemelor cu cerințele

Product backlog - o listă prioritară de funcționalități și alte cerințe. Evaluarea eforturilor este minimizată - o dimensiune relativă este exprimată, exprimată în puncte (Fig. 2). Una dintre tehnicile în acest scop este pokerul - participanții primesc cărți cu dimensiunile tricourilor S, M, L, XL, XXL și aruncă o carte cu scorul lor, apoi discută doar dacă există diferențe. După prima iterație, puteți vedea exact câte ore are fiecare persoană o mărime a tricoului.

Abordare iterativă - începem producția cât mai curând posibil, creând o versiune parțială a produsului și actualizându-l la intervale scurte. O iterație este adesea efectuată timp de 2 sau 4 săptămâni. Fiecare iterație începe cu planificarea și se termină cu revizuirea și adaptarea clienților. Cerințele detaliate sunt clarificate fie în timpul iterației, fie devin clare aproape de iterația în care vor fi dezvoltate. Aceasta este aplicația JIT din proiectele de aici. În cadrul iterației efectuăm analiza, proiectarea, dezvoltarea și stabilizarea funcționalităților incluse în iterație. Funcționalitatea de lucru arată un progres real, nu artificial.

Ritualul întâlnirilor zilnice de scurtă durată în jurul tabloului cu sarcini scrise pe note lipicioase (de exemplu, Kanban). Toată lumea răspunde la 3 întrebări: „Ce am făcut ieri?” „Ce am să fac azi?” „Ce mă deranjează?” Dacă se desfășoară în mod corespunzător, aceste întâlniri dau o energie puternică echipei și mențin un sentiment de urgență.

Timebox - creăm rezultate pe parcursul întregului proiect în intervale fixe de timp, stabilim cea mai mare prioritate a termenului și nu îl amânăm. Dacă este necesar, amânăm funcționalitatea pentru următoarea iterație. Acest lucru ajută la luarea unor decizii urgente dificile într-un proiect. Această abordare rezolvă cu succes problema amânării și întârzierii.

Metode adaptive

În 2001, mai mulți practicanți și autori de seamă au semnat celebrul Manifest Agile, impunând astfel Agile ca denumire comună pentru metodele adaptative.

Expresia „Lean for development software” apare în cartea cu același nume a lui Marie și Tom Popendiek din 2003. Acesta este un nou pas care critică unele dintre conceptele originale SCRUM pentru o planificare inutilă.

Utilizarea modalităților adaptive (Agile) pentru managementul proiectelor a crescut semnificativ în ultimii 2 ani. Gartner prezice că până la sfârșitul acestui an, metodele vor fi utilizate de 80% dintre companiile de software. Un studiu PMI arată că, din decembrie 2008 până în mai 2009, utilizarea agilă sa triplat. Acest studiu demonstrează, de asemenea, că beneficiile metodelor adaptive sunt reducerea defectelor, creșterea productivității și creșterea valorii utile a produselor.

Agile s-au dovedit eficiente în companii precum Amazon, Microsoft și Bank of America. Această abordare a trecut mult timp dincolo de producția de software și IT și devine un model pentru gestionarea proiectelor de diferite tipuri. Echipele care implementează Agile creează produse cu o calitate superioară, randamente mai mari, o satisfacție mai mare a clienților și sunt mult mai rapide decât abordarea tradițională a cascadei sau haosul. Calitatea înaltă este obținută cu tehnici precum integrarea continuă, testarea continuă de regresie, dezvoltarea test-driven (TDD) și refactoring (îmbunătățirea arhitecturii și designului). Rentabilitatea investiției mai mare provine din concentrarea pe activități care aduc valoare reală produsului final, prioritizarea muncii pe funcționalități, automatizarea maximă a testării, interacțiunea de calitate cu echipa și clienții și, în general, munca mai inteligentă și mai concentrată, mai degrabă decât mai grea și mai lungă. Satisfacția clienților este sporită prin implicarea lor activă, prin demonstrarea funcționalității complete și funcționale cu fiecare iterație, permițând evoluția cerințelor în timpul proiectului.

In concluzie

La fel ca Agile în proiecte, secretul pierderii în greutate este, de asemenea, în câteva principii simple, dar radical diferit de opinia general acceptată.

Cercetătorii de la Universitatea din Boston au descoperit că persoanelor cu niveluri ridicate de insulină le este foarte greu să piardă grăsime în comparație cu persoanele cu niveluri scăzute. Dacă vă mențineți secreția de insulină scăzută, puteți face metabolismul să funcționeze într-un ritm rapid și chiar și atunci când vă odihniți pentru a arde grăsimile automat. Iată cum:

Nu mai muri de foame, nu cădea sub 1500 de calorii pe zi

A lua micul dejun

Mănâncă cel puțin 3 și, de preferință, de 5 ori pe zi

Înlocuiți pâinea albă și orezul cu cereale integrale și, în general, căutați alimente cu un indice glicemic scăzut

Înlocuiți ciocolata cu lapte cu cea neagră cu cel puțin 70% cacao

Faceți prăjiturile cu făină integrală și ulei de cocos

Consumați regulat mirodenii și fasole fierbinți

Mănâncă cu plăcere și atenție, nu apropo

Bea multă apă, rece dacă este posibil

Nu mâncați cu 2 ore înainte de culcare

Puteți găsi analogia fiecăreia dintre aceste recomandări în ceea ce privește gestionarea proiectelor dvs.

* Mai multe despre efectul insulinei asupra metabolismului: http://blogs.mercola.com/sites/vitalvotes/archive/2007/06/04/Finally-Science-Confirms-the-Secret-Key-to-Weight-Loss. aspx

** Mai multe despre Agile: http://www.agilealliance.org/

Nina Prodanova-Yotseva este partener de conducere în ITCE. Experiența sa profesională în industria IT a fost acumulată de 19 ani. S-a alăturat ITCE acum 12 ani. Ea consultă și formează numeroase organizații din sectorul financiar, telecomunicații și industria IT din Bulgaria și din alte țări din regiunea noastră. Nina a fost inclusă în clasamentul primilor 15 instructori pentru Microsoft SQL din Europa în 2000 și a fost printre primii cu certificare ITIL în 2005. Este membră a secțiunilor bulgare ale forumului internațional ITSM, PMI, IIBA și a fost nominalizată în primii 20 în premiile pentru „Omul de afaceri al anului 2010”. El deține o serie de certificări, inclusiv: PMI Agile Certified Practitioner; Certificat PMP; Expert ITIL v.3, auditor oficial pentru ISO 20000. Acreditat de Exin și FoxIT ca instructor ITIL, lector pentru PMP, UML și BPMN, MSF și MOF, are un certificat Microsoft Professional IT: DB Admin

În număr

Înregistrați-vă și obțineți acces la cele mai noi știri și tendințe din lumea tehnologiei din țara noastră