blog.testowka.pl

Archiwum wiadomości z Lipiec, 2011

Dług technologiczny

opublikowany przez 14, Lip, 2011, w kategoriach Agile, Automatyzacja, Testowanie

„Blog o jakości oprogramowania” – chyba łatwiej mi się pisze ostatnio o brakach w jakości oprogramowania niż o samej jakości.

Rozwój oprogramowania to bardzo złożony proces, na który wpływ ma wiele czynników, jednym z najważniejszych są szeroko rozumiane wymagania biznesowe. Wiadomo, jeśli nie wiadomo o co chodzi to pieniądze – po coś oprogramowanie się tworzy i przeważnie robi się to właśnie dla pieniędzy (nawet oprogramowanie Open Source jest w pewnym sensie tworzone dla pieniędzy, w mniej lub bardzie pośredni sposób ktoś na tym zawsze zarabia). W większości przypadków to tak zwany „Biznes” steruje rozwojem oprogramowania (w odpowiedzi na właśnie takie zapotrzebowanie powstały zwinne metodyki wytwarzania oprogramowania – by Biznes mógł jeszcze częściej i szybciej reagować na zmiany rynkowe). Niestety często bywa tak, że presja ze strony Biznesu jest na tyle duża, że zapomina się o tym by o wspomnianą na początku tej notki jakość dbać. Tworzy się nowe funkcjonalności zapominając o pisaniu testów, dokumentacji, refactoringu, odpowiednim projektowaniu etc. bo przecież nie ma na to czasu, liczy się tylko zwielokrotnianie zysków, dodawanie wartości do oprogramowania (testów, dokumentacji, projektowania nie da się w żaden sposób przeliczyć na wymierne korzyści finansowe) – w ten właśnie sposób tworzy się coś co nazywamy Długiem Technicznym (albo Długiem Technologicznym). Dług Techniczny (Technical Debt) swoją nazwę zawdzięcza podobieństwu do zwykłej pożyczki zaciągniętej w banku. Każdy pominięty test, nieudokumentowany ficzer, dodanie czegoś ad-hoc – bez odpowiedniego zaprojektowania prowadzi do obniżenia ogólnie pojętej jakości projektu, co w rezultacie prowadzi do widocznego spowolnienia rozwoju prac nad projektem.

Pozwolę sobie przytoczyć cytat z pewnego CTO, z którym miałem okazję kiedyś porozmawiać nt. jakości oprogramowania wytwarzanego przez podległych mu programistów: „Rok temu pracowaliśmy kilka razy szybciej, teraz wszystko jakby spowolniło – prawdopodobnie programiści się rozleniwili”. Wspomniany dyrektor był zdenerwowany tym, że rok wcześniej główny projekt firmy rozwijał się 6 razy szybciej niż obecnie. Domniemana przyczyną było „rozleniwienie programistów”,  którzy poczuli się zbyt bezpiecznie na swoich pozycjach – „przecież z tej firmy jeszcze nikogo nie zwolnili”. W odpowiedzi na domysły tego pana zadałem kilka pytań w stylu: Czy piszecie testy jednostkowe? Czy mierzycie pokrycie kodu testami? Jak wygląda wasza dokumentacja? Jak wyglądają wasze środowiska testowe? Czy możecie mi pokazać projekt architektury waszych aplikacji? etc… Na większość z tych pytań odpowiedź była negatywna (w sensie „nie, nie mamy czegoś takiego”). Przyczyną takiego stanu rzeczy była duża presja ze strony klientów, którzy wymagali jak najszybszych dostaw nowych ficzerów w celu zwiększenia zysków (co zresztą udawało im się przez dłuższy czas całkiem nieźle). Niestety nacisk tylko na wytwarzanie wartości biznesowej spowodował zanik takich praktyk jak testowanie, pisanie dokumentacji, czy nawet projektowanie – wszystko działo się ad-hoc, bez planu i spójnej wizji. W ten oto sposób powstał Dług Technologiczny, którego efektem było spowolnienie pracy. Nie wspomnę już o tym, że 80% czasu zajmowało łatanie dziur i naprawianie bugów.

Nazwa „Dług” nawiązująca do kredytu bankowego jest jak najbardziej adekwatna. Wyobraźmy sobie sytuacje w której w celu rozbudowania naszego przedsiębiorstwa i zwiększenie jego zysków zaciągamy kredyt w banku. Za uzyskane w ten sposób pieniądze inwestujemy w nowe maszyny, czy też zatrudniamy więcej ludzi co w pewnym stopniu zwiększa nasze zyski. Po jakimś czasie decydujemy się na jeszcze większe rozbudowanie naszego przedsiębiorstwa, więc bierzemy kolejny kredyt. Znowu zyski rosną. Robimy tak jeszcze kilka razy i nagle okazuje się, że owszem – mamy całkiem pokaźne przychody, ale większość zysków konsumują odsetki z zaciągniętych kredytów.

Sama świadomość tego, że taki dług zaciągamy jest już całkiem pozytywna – jeśli tylko WSZYSCY zdają sobie sprawę z konsekwencji takich a nie innych decyzji. Niestety z moich obserwacji wynika, że w większości organizacji z którymi miałem do czynienia ludzie nie mają pojęcia o czymś takim jak Technical Debt, lub nawet jeśli coś o tym, kiedyś słyszeli to nie potrafią wskazać u siebie miejsc w których taki dług jest zaciągany. Prawdę powiedziawszy to w każdej, nawet najlepiej zorganizowanej firmie zawsze znajdą się miejsca, w których w jakimś stopniu taki dług się nawarstwia.

Podobnie jak normalny kredyt, także Dług Techniczny trzeba w końcu spłacić. O tym jak można to robić napiszę następnym razem.

4 komentarze więcej...

Poszukiwany/Poszukiwana!

opublikowany przez 06, Lip, 2011, w kategoriach Praca, Testowanie

Coraz częściej zauważam wzrost aktywności wielu firm IT na rynku pracy. Zauważam także więcej ogłoszeń dla testerów i QAów. Pojawia się też coraz więcej firm zajmujących się rekrutacją pracowników dla IT. Powodów może być wiele – czasem jest to spowodowane dynamicznym rozwojem firmy, a czasem jak to zwykle w przypadku testerów bywa próbą ratowania zbugowanego systemu.

Oglądałem kiedyś ciekawą prezentację Ken’a Schwabera wprowadzającą do Scrum. Oprócz samej tematyki Scrum poruszony został tam jeden bardzo ciekawy problem – Ken przedstawił przykładowy (sprawdzający się w większości przypadków) cykl życia start-up’ów. Wygląda to mniej więcej tak:

Kilku pomysłowych gości wpada na świetną, rewolucyjną idee i rozpoczyna pracę w swoim garażu/pokoju w akademiku/wynajętym mieszkaniu etc. Po jakimś czasie pojawia się pierwsza wersja live oferowanego systemu/aplikacji która powoli zaczyna zarabiać – na początku walczymy o to by zwróciły się koszty. Po jakimś czasie, przeważnie w wyniku niesamowitego zbiegu okoliczności start-up staje się bardzo popularny i zaczyna nagle zarabiać coraz więcej pieniędzy, co powoduje że firma się rozwija i zatrudnia więcej pracowników, którzy jak najszybciej produkują coraz to nowsze ficzery by jeszcze bardziej powiększyć zyski. Przeważnie wszyscy będąc na tej fali ciągłego powiększania przychodów nie przejmują się jakością. Po pewnym czasie projekt dociera do punktu w którym dodanie nowego ficzera staje się droższe niż zyski z niego płynące, niemniej jednak są one cały czas dodawane z różnych powodów – często czysto marketingowych nieprzekładających się na wymierne korzyści materialne. Mija jeszcze trochę czasu, po którym ktoś nagle stwierdza, że przepisanie całej aplikacji od nowa zajmie mniej czasu niż dodanie nowego ficzera. W międzyczasie zarząd/właściciele firmy zaczynają się zastanawiać nad tym jak rozwiązać problem zbyt drogich ficzerów. Jednym z rozwiązań jest pozbycie się problemu poprzez sprzedanie go innym – na rynku jest wiele firm typu venture capital, które masowo skupują start-up’y, po to by niektóre z nich przekształcić w prężnie działające przedsiębiorstwa. Zdarza się też tak, że zarząd postanawia wreszcie przenieść nacisk z wyłącznie zarabiania na polepszanie jakości (czasem też na przepisanie systemu od zera). W obydwu tych przypadkach (nieważne czy firmę kupi ktoś nowy, kto będzie chciał polepszyć jakość, czy zarząd sam zdecyduje się to zrobić) potrzebne jest zapewnienie specjalistów. Właśnie wtedy firmy decydują się na zatrudnienie zespołu QAów, którzy ogarną cały ten bałagan i zaproponują rozwiązania problemów. Czasem jest już za późno, niemniej jednak, jeśli tylko nakład na jakość jest wystarczająco duży często udaje się to osiągnąć.

W życiu każdego testera przychodzi czas na zmiany… Czasem bywa tak, że jest to zmiana pracy… Jeśli taki czas nadszedł właśnie dla Ciebie to mam dla Ciebie świetną propozycję! Szukamy testerów/inżynierów testów/QAów do naszego zespołu we Wrocławiu.

Jeśli jesteś zainteresowany/zainteresowana możliwościami dalszego rozwoju w dziedzinie automatyzacji testów, testowania, szeroko rozumianego QA etc. to zapraszam do kontaktu (jeśli napiszecie, że dowiedzieliście się o ofercie pracy z mojego bloga macie +10 do charyzmy ;-)) . Więcej informacji możecie znaleźć tutaj.

Szukamy też programistów PHP i Python.

8 komentarzy więcej...

O przyszłości Agile…

opublikowany przez 01, Lip, 2011, w kategoriach Agile, Scrum

Wracając taksówką z jednego ze szkoleń w Krakowie wdałem się z kierowcą tej taksówki w bardzo ciekawą konwersację na temat jakości dróg w mieście, organizacji ruchu, sposobach przeprowadzania remontów. Jak chyba każdy polak tak i ja i wspomniany taksówkarz oczywiście wiemy lepiej jak tego typu prace należy przeprowadzać. (Nie ukrywajmy, że da się to robić lepiej, spójrzmy na którychkolwiek naszych sąsiadów na zachód – w Holandii budowa tunelu pod autostradą trwa dwie doby w Polsce dwa lata…). Ogólnie rozmawialiśmy o oczywistych problemach, które każdy widzi tylko nikt nie ma wystarczająco dużej władzy – siły przebicia by móc te problemy rozwiązać. Gdy wysiadałem z taksówki kierowca powiedział do mnie coś co na początku wydało mi się zwykłą grzecznością ale w kontekście innej rozmowy z zupełnie innymi ludźmi nabrało zupełnie innego znaczenia. Taksówkarz powiedział mniej więcej coś takiego: „Dobrze, że są tacy młodzi ludzie jak Pan, którzy widzą to co się dzieje bo za parę lat być może, któryś z was będzie siedział na miejscu tych, którzy teraz decydują tam na górze i będzie podejmował znacznie lepsze decyzje, chociażby na podstawie tego o czym teraz rozmawialiśmy”. (A nie mówiłem, że zwykła grzeczność? :-))

Kolejną bardzo ciekawą rozmowę na zgoła odmienny temat odbyłem z dwoma znakomitymi (chyba najlepszymi i prawdopodobnie jedynymi w Polsce) trenerami, coachami, konsultantami Scrum/Agile (Pewnie niektórzy domyślają się o kim mowa :)). Rozmawialiśmy między innymi o popularności Agile i o tym, że aby można było mówić, że Agile jest na prawdę popularne to musi ono zaistnieć w wielkich korporacjach. Moje stanowisko było bardzo sceptyczne – korporacje nie chcą zmian, a Agile może się okazać nieodpowiedni dla tego typu organizacji. Niemniej jednak korporacje jak wszystkie inne organizacje borykają się z wieloma problemami, które zwinne metodyki zarządzania projektami w bardzo prosty sposób rozwiązują. Ba – w związku z rozwojem rynku i samych organizacji pojawiają się coraz to nowsze i nie pasujące do żadnych wcześniejszych schematów problemy – tutaj Agile staje się jedyną słuszną drogą. Ale nie o tym chciałem napisać (pewnie rozpocznie się dyskusja na ten temat w komentarzach, do której serdecznie zapraszam)…

Kolejnym problemem, który poruszyliśmy był fakt, iż coraz więcej organizacji – korporacji, szkoli swoich pracowników niższego szczebla z zakresu Agile i Scrum, pomimo tego, że w tych organizacjach póki co nie ma szans na prawidłowe wdrożenie zwinnych metodyk wytwarzania oprogramowania. Wzbudziło to w nas pewne kontrowersje niemniej jednak w wyniku dalszej rozmowy wydaje mi się, że udało nam się znaleźć potencjalną przyczynę tego typu ruchów w organizacjach- o czym za chwilę. Oczywiście równie dobrze może to być nieracjonalne podążanie za modą i trendem – kto powiedział, że ludzie i organizacje zawsze postępują racjonalnie?

Jako że byłem najmłodszy i najmniej doświadczony w tym gronie (nie pracowałem jeszcze dla wielkiej korporacji) zostało mi postawione proste pytanie: „Jakiej metodyki będziesz używał jeśli zostaniesz managerem w korporacji?” – najprostsza i najszybsza odpowiedź jaka przyszła mi do głowy to „Scrum”. Potem padło stwierdzenie, że prawdopodobnie za jakiś czas zostanę wspomnianym managerem w korporacji – prawie każdy, kto chce się rozwijać i podążać jakąś ścieżką kariery w IT prędzej czy później zostaje project managerem w korporacji, a czasem zdarza się tak, że ten project manager awansuje i w pewnym momencie ma wystarczająco dużo mocy wykonawczej by podjąć decyzję o tym jaka metodyka/organizacja pracy ma być stosowana w całej organizacji.

Wnioski jakie z tego płyną pozostawiam jako temat otwarty. Według mnie z powyższych rozmów wynika kilka bardzo ważnych rzeczy – między innymi to, że będąc na dole mamy inne spojrzenie na organizację i dostrzegamy inne problemy – czasem znacznie więcej niż widać z góry, dlatego też potrzebna jest ciągła rotacja, która w sposób naturalny w większości organizacjach zachodzi – osoby, które były na dole awansują i mogą same rozwiązywać problemy, które do niedawna najbardziej ich dotykały. Oczywiście następuje też wymiana „wiedzy” pomiędzy organizacją i otoczeniem.

3 komentarze więcej...