Trzecia kawa Szkolenie Scrum

Mitologia rekrutacji programistów

Mainpage_Slider_Greek_Mythology_GodsChoć jest przynajmniej kilka znanych i całkiem dobrych tekstów nt. rekrutacji programistów (kilka linków podałem niżej), postanowiłem podzielić się swoim – bardzo subiektywnym – doświadczeniem w tej dziedzinie. Niniejszy tekst piszę z perspektywy osoby, która rekrutuje programistów, jednak spostrzeżenia i porady pomocne mogą być zarówno dla innych rekruterów jak i kandydatów do pracy. Swoje przemyślenia zebrałem w formie kilku “mitów”, które udało mi się gdzieś usłyszeć lub przeczytać. Nazywam się je mitami głównie dlatego, że w całości lub przynajmniej częściowo się z nimi nie zgadzam… i staram się niżej wyjaśnić dlaczego. Dodatkowo chciałbym uprzedzić – tekst dotyczy weryfikacji zdolności, umiejętności i wiedzy technicznej – a nie całokształtu znajdowania idealnych pracowników do danego zespołu. Nie aspiruję do tego aby być ekspertem od psychologii, HR czy zaawansowanego managementu. Interesuje mnie głównie to, aby ludzie techniczni – programiści i architekci, mieli możliwość dobierania sobie współpracowników poprzez udział w rekrutacji i żeby robili to kierując się sensownymi kryteriami.

(więcej…)

Badając zwinność

agilecatW kwietniu i maju bieżącego roku BPM Laboratory uniwersytetu w Koblenz przeprowadziło badanie zatytułowane Status Quo Agile. Celem badania było zebranie doświadczeń różnych organizacji w zakresie wykorzystania zwinnych metod zarządzania projektami. W ankiecie wzięło udział ponad 600 respondentów, a opracowanie jej wyników można pobrać ze strony http://www.status–quo–agile.net/.

Dlaczego to badanie jest ciekawe? Dlatego, że mówiąc o zwinności w organizacjach, zazwyczaj wypowiadamy się na temat kilku-kilkunastu projektów, które dane nam było prowadzić czy zobaczyć. Tutaj zaś mamy zebrane z opinie z wielu różnych firm i organizacji.

Celem tego artykułu nie jest streszczanie 142-stronicowego raportu lecz wybranie z niego kilku fragmentów, które wydają mi się najciekawsze. (więcej…)

Od menedżera do właściciela produktu

darth_vader_product_ownerDzień był szary, deszczowy i mglisty. Wystarczyłaby chwila spojrzenia na zasłonięty mgłą świat, aby zadumać się nad jesienią, przemijaniem i sensem… Na szczęście nikt w wielkim budynku biurowca nie miał czasu na patrzenie za okno – klimatyzacja utrzymywała stałą temperaturę 22 stopni Celsjusza, grube szyby broniły przed deszczem, a ludzie wpatrzeni byli w niebieskie ekrany monitorów, które wyświetlały raporty, maile, kody oraz – od czasu do czasu – zdjęcia małych kotków.

Do pokoju Stefana, młodego i zdolnego menedżera projektu, wszedł dyrektor działu rozwoju oprogramowania, przysunął sobie krzesło, usiadł na nim i powiedział tak:

– Słuchaj, jest taka sprawa. Centrala chce bardzo, żebyśmy byli adżajl i żebyśmy teraz projekty robili w skramie. Wybraliśmy twój projekt jako pilotaż, bo kiedyś mówiłeś, że coś o tym słyszałeś. Także zróbcie szybko tego skrama, wprowadźcie te biegi czy sprinty. Oczywiście cała zmiana nie może mieć wpływu na budżet – jest już ustalony z klientem, terminy są napięte, także nie możemy już niczego przesuwać. Tak za miesiąc potrzebuję prezentacji, która podsumowuje zalety skrama, będzie to rekomendacja dla pozostałych projektów. (więcej…)

Dlaczego Scrum nie działa?

Scrum FailPewien zespół programistów postanowił wdrożyć w swojej pracy framework Scrum. Jedna z osób w tym zespole przeczytała książeczkę pod tytułem Scrum Guide i opowiedziała innym jak ten cały Scrum wygląda – opowiedziała o tym, że są sprinty, że ostatnio cały świat tak robi, że będą bardziej efektywni oraz że w ogóle będzie miło i przyjemnie.

Zabrano się do pracy. Ustalono role – Franek został Właścicielem Produktu, zaś Marek został Scrum Masterem. Ustalono, gdzie będzie trzymany backlog oraz nauczono się, że gotowe zmiany w kodzie od teraz nazywają się inkrementem. Ustalono długość sprintu, w kalendarzach pojawiły się nowe spotkania pod tytułem planowanie sprintu, codzienny scrum, przegląd oraz retrospektywa. Wszystko zaczęło się toczyć, właściciel produktu priorytetyzował zadania w backlogu, backlog produktu zmieniał się w backlog sprintu, backlog sprintu zmieniał się w inkrement, a wykresy spalania poruszały się to w górę, to w dół.

Wszystko miało być pięknie. Jednakże po pewnym czasie członkowie zespołu doszli do wniosku, że w zasadzie nic się nie zmieniło. Zadania są takie same, jakość dostarczanego produktu w zasadzie cały czas pozostawia sporo do życzenia, a odbiorca cały czas jest tak samo niezadowolony. I w zasadzie to po co nam ten cały Scrum, więcej z niego kłopotu niż pożytku… (więcej…)

SOA i middleware

GetSoaGeekAndPoke

Geek and Poke

Architektura zorientowana na usługi (SOA) kojarzy się z zastosowaniem oprogramowania pośredniczącego nazywanego potocznie międzymordziem (ang. middleware). W poprzednim wpisie na temat SOA próbowałem na przykładzie opisać czym jest SOA w scenariusze z i bez ESB. W tym wpisie postaram się wyjaśnić jak middleware może pomóc przy budowaniu architektury zorientowanej na usługi.

Zdarza się, że przedsiębiorstwa inwestują w narzędzia middleware nie do końca wiedząc do czego i kiedy warto je stosować. Wiąże się to z kilkoma problemami: wiedza na temat integracji jest dosyć mało rozpowszechnioną dziedziną, a produkty oznaczone plakietką SOA oferują bardzo specyficzne metody według własnej filozofii. Temat SOA również rozumiany w środowisku informatycznym bywa w rożny sposób.

(więcej…)

SOA w praktyce

SOA

Architektura zorientowana na usługi (ang. service oriented architecture), SOA stała się popularnym terminem pojawiającym się na wszelkich etykietach dostępnego oprogramowania klasy enterprise. Praktycznie każdy dostawca chwali się, że dostarcza produkty “zgodne z SOA”. Wiele firm dało się skusić na kupienie produktu oznaczonego znaczkiem SOA z myślą, że zainstalują taki produkt i będą od tego momentu “robić SOA”… No cóż, SOA to nie systemy, a podejście, które trzeba wdrożyć by czerpać z niego korzyści.

(więcej…)

Ogólna Architektura Aplikacji Warstwowych

Wikipedia

Architektura kolumny z Persopolis

Projektujesz kolejny system internetowy w architekturze wielowarstwowej? Obiecujesz sobie, że tym razem wszystko będzie uporządkowane i przemyślane? W głowie klarują się Tobie pakiety i komponenty i wszystko ma swoje miejsce dopóki nie przyjdą ludzie z biznesu i wywrócą świat do góry nogami?

Okazuje się, że w przypadku większości systemów internetowych pewne ramy architektoniczne są powtarzalne i nie ma co odkrywać koła na nowo zaczynając kolejny projekt. Niezależnie, czy budujemy system rezerwacji, portal internetowy, system obiegu dokumentów, system bankowości elektronicznej, to część elementów pozostaje na pewnym poziomie ogólności wspólnych dla każdego z nich. W tym wpisie pomiędzy trzecią, a czwartą kawą spróbujemy zidentyfikować owe wspólne elementy i przedstawić propozycję bibliotek do ich realizacji w środowisku Java / J2EE. (więcej…)

Gdzie są moje daty?

2010Dziś odbiegając od poprzednich wpisów dotyczących sfery zarządzania w obszarze IT, zajmiemy się bardzo konkretnym problemem, na który można trafić podczas pracy z relacyjnymi bazami danych.

Podczas implementacji raportów jednym z często spotykanych typów raportu, z którymi przyjdzie nam praocować jest szereg czasowy. Upraszczając chodzi o takie zestawienia, w których obserwujemy zdarzenia w dobrze określonych odstępach czasu. Niestety zazwyczaj dane jakimi dysponujemy rejestrują tylko czas wystąpienia zdarzenia, w którym cokolwiek zaobserwowano. (więcej…)

Dokumentacja – od chaosu do bazy wiedzy

documents.pngPodczas prezentacji, które prowadziłem na tegorocznym GeeCON-ie oraz na Forum Jakości, największe zainteresowanie uczestników wzbudził temat porządkowania i cywilizowania dokumentacji dla dużych systemów IT. Co naturalne, najbardziej tematem zainteresowani byli przedstawiciele firm, które pracują z dużymi systemami i w poprezentacyjnych rozmowach widać było, że wszyscy zmagamy się z bardzo podobnym problemem.

(więcej…)

GeeCON – notatki na marginesie konferencji

geecon_logo2Idea pracy informatyków jest bardzo prosta – tworzymy systemy, które mają jakieś zastosowanie. Możemy za ich pomocą zarezerwować hotel, stworzyć listę zadań w telefonie, założyć lokatę w banku, wymieniać informacje ze znajomymi, wyszukiwać produkty o najniższych cenach, szukać drogi w obcym mieście i robić wiele, wiele różnych rzeczy.

Ale pod powierzchni ą interfejsu systemu kryje się chaos. Kryje się cała masa kodu, danych, założeń, dokumentacji, interfejsów, usług, komunikacji, standardów… (więcej…)