blog.testowka.pl

Archiwum wiadomości z Marzec, 2010

Żeby pobrać Windowsa trzeba mieć… Windowsa

opublikowany przez 16, Mar, 2010, w kategoriach Inne

Jako że jestem studentem (nadal, jeszcze, znowu itd 🙂 ) postanowiłem wykorzystać ten fakt i skorzystać z możliwości pobrania „darmowego” Windowsa. Darmowego i jak najbardziej legalnego zgodnie z licencją MSDNAA E-Academy License Management System (ELMS), która to przysługuje mi z racji bycie studentem na mojej Uczelni.

Pomijam fakt, że podczas rejestracji w cudownym systemie ELMS hasło, które podawałem przy pierwszej rejestracji zostało mi przesłane ponownie drogą mailową, niczym nie zabezpieczonym plain textem. Ot taki mały security sic problem, ale w systemach z pod znaku M$ nic takiego nie jest mnie już w stanie zaskoczyć.

Po wypełnieniu papierków na uczelni – podpisaniu umowy (oczywiście w języku angielskim, którego przecież mógłbym nie zrozumieć, ale kogo to obchodzi) dopełniłem rejestracji klikając w link aktywacyjny i logując się na moje konto w MSDN Academic Alliance Software Center. Pierwsze zdziwienie nastąpiło, gdy okazało się, iż jest to marna przeróbka sklepu internetowego Micro$oftu, w której aby coś pobrać, podobnie jak w sklepie najpierw muszę dodać to do koszyka, po czym zatwierdzić „zakup” (nawet niektórych tekstów nie pozmieniali). Na szczęście w miejscu cen było „Free”. Po dokonaniu „zakupu” polskiej wersji Windows XP Proffessional (Single User) na ekranie wyświetliła się instrukcja by kliknąć w link „download” co też uczyniłem. Możecie sobie wyobrazić moje zaskoczenie (albo jego brak),.gdy okazało się, iż aby ściągnąć Windowsa musże najpierw zainstalować aplikację Windows_XP_ISO_Downloader.exe. W skrócie, by zainstalować Windowsa potrzebuję Windowsa, który tą aplikację obsłuży.

Żeby nie było, że tak łatwo się poddałem spróbowałem uruchomić „downloadera” używając do tego celu Wine. Po chwili niepewnośći moim oczom ukazał się poniższy obrazek:

Treść powyższego dość jednoznacznie sugeruje, że jest to nie tylko dowloader ale i installer Windowsa. Nie zważając na ryzyko (wykorzystując defaultowe C:\Temp – z ciekawości co się stanie) przeszedłem do następnego kroku.

Ściąga się… W sumie zastanawiam się jak to możliwe, gdyż nie odpaliłem Wine jako root (może ustawiłem to gdzieś, kiedyś tylko o tym zapomniałem). Poczekamy na efekty za kilka minut…

Obraz ISO z Windowsem ściągnął się. Przynajmniej tak twierdzi ta wspaniała aplikacja. Osobiście nie udało mi się odnaleźć tego pliku na moim dysku. No nic… Raz się żyje – klikam „Launch”. I… Stało się to czego się w sumie spodziewałem wysypał się Wine. Może właśnie problemem był brak uprawnień do pisania po dysku, albo nieistniejąca ścieżka do katalogu. Chyba wypadało by sprawdzać takie rzeczy przed narażeniem użytkownika na kilkugodzinne bezcelowe ściąganie pliku.

Efekt końcowy dość przewidywalny. Być może jest jakiś sposób na efektywne pobranie Windowsa przy użyciu Linuksa, ale niestety nie mam teraz czasu by się tym zajmować. Powyższy eksperyment został przeprowadzony na potrzeby niniejszej notki, a sprowokował go kolega, który miał problemy z samym ściągnięciem Windowsa nie mówiąc o jego instalacji przy użyciu powyższego narzędzia.

PS: Powyższa notka powstawała w trakcie wykonywania opisywanych w niej czynności. Na początku nie wiedziałem jak to się skończy. 🙂

Miało być tak pięknie a jest jak zawsze… Niezastąpiony M$ nigdy Cię nie zawiedzie…

2 komentarze więcej...

Rola Scrum Mastera

opublikowany przez 14, Mar, 2010, w kategoriach Agile, Praca, Scrum, Zarządzanie

W Scrumie istnieją trzy podstawowe role: Członek Zespołu (Team Member), Właściciel Produktu (Product Owner) i Mistrz Scruma (Scrum Master). To właśnie rola tego ostatniego jest najczęściej uważana za najistotniejszą (szczerze nie jestem do końca przekonany czy słusznie).

Należało by się zastanowić czym taki Scrum Master powinien się zajmować. Według mnie taka osoba ma dwa podstawowe zadania:

  1. Dbanie o przestrzeganie zasad ustalonych przez zespół.
  2. Wsparcie prac zespołu i zapewnienie mu odpowiednich warunków do pracy.

W nawiązaniu do pierwszego podpunktu trzeba pamiętać o kilku podstawowych zasadach narzucanych przez Scruma samego w sobie, po pierwsze zespół jest samo-organizujący się. To zespół ustala zasady, jakie zamierza stosować. Scrum Master nie może narzucać swoich zasad, co najwyżej może proponować na podstawie obserwacji pewne udoskonalenia lub zmiany, ale musi się to spotkać z aprobatą reszty zespołu by można było je wdrożyć. Właśnie tutaj Mistrz Scruma musi wykazać się nie lada zdolnościami interpersonalnymi by zachowując odpowiedni dystansł wymóc na zespole stosowanie przyjętych zasad. Ponadto Scrum Master jest strażnikiem samego procesu co zobowiązuje go do nadzorowania poprawnego przestrzegania praktyk Scrumowych. W tym celu można wykorzystać Scrum Check Listę (o której może innym razem). Dobrym pomysłem jest codzienne sprawdzanie czy wszystko idzie zgodnie z planem by móc jak najwcześniej zareagować na ewentualne problemy i odstępstwa od normy.

Drugi podpunkt porusza problem znacznie trudniejszy do zdefiniowania, gdyż pojęć wsparcia zespołu i zapewnienia odpowiednich warunków nie da się odpowiednio sprecyzować. Co do wspomnianych warunków przypomina mi się pewna historia opowiedziana przez kolegę, który opowiadał o tym jak bezcenny jest widok dwóch managerów przepychających muszlę klozetową ;-). Jest to dość skrajny przykład, niemniej jednak można by to zaliczyć do zapewniania odpowiednich warunków pracy. Bardziej realnym problemem którego rozwiązania powinien podejmować się Scrum Master jest załatwianie dostępu do odpowiednich informacji i pilnowanie klientów by nie mieszali się zbytnio w proces. Rolą Mistrza jest także wyjaśnianie wszelkich niejasności wynikających z niedoprecyzowania wymagań, a także rozwiązywanie konfliktów w zespole dotyczących np. sposobu implementacji danej funkcjonalności.

Ponadto oprócz dwóch powyższych podpunktów Mistrz Scruma powinien także potrafić obserwować zespół i jego reakcję po to by wyciągać trafne wnioski pozwalające na usprawnienie procesu i lepsze wsparcie. Ważne na przykład jest to by Scrum Master potrafił skutecznie motywować swoich współpracowników, by wiedział jakie są ich ambicję i by w miarę możliwości pozwalał im się spełniać w tym co chcą robić.

Z powyższego wynika, że nie każdy może być Scrum Masterem, a już na pewnie nie każdy może być „Dobrym Mistrzem Scruma”. By to osiągnąć trzeba umieć obserwować ludzi, ich zachowania, współprace, zależności etc. Ponadto warto posiadać podstawową wiedzę psychologiczną i socjologiczną. Warto też mieć odrobinę pojęcia na temat różnych innych metodologi zarządzania, niekoniecznie zwinnego, by móc także z nich czerpać pewne pomysły i udoskonalenia. Scrum jest na tyle elastyczny, że pozwala na pewną ewolucję. Każdy zespół może interpretować Scruma na swój sposób i za każdym razem może to być poprawne i prowadzić do sukcesów, ważne by przestrzegać podstawowych zasad. Mistrz Scruma powinien także brać czynny udział w procesie ewolucji i udoskonalania a także przestrzegać by mieścił się on w odpowiednich, bezpiecznych granicach.

Na zakończenie dodam, iż jest to wyłącznie moja subiektywna opinia i interpretacja roli Scrum Mastera w zespole powstała na bazie obserwacji i doświadczeń. W pewnym stopniu pokrywa sie to z teorią Scruma ale chyba raczej nie do końca.

2 komentarze więcej...

Kalectwo procesu – czyli moc retrospekcji.

opublikowany przez 10, Mar, 2010, w kategoriach Agile, Praca, Scrum, Zarządzanie

Dawno, dawno temu ktoś próbował mnie usilnie przekonywać, że w ogólnym pojęciu teoria jest jedynie teorią i w praktyce sprawdza się bardzo, na prawdę bardzo rzadko. Po latach własnych życiowych i zawodowych doświadczeń odkryłem, iż teoria to nie taka głupia sprawa. Ostatecznie ktoś te teorie z jakiegoś powodu wymyślił, ktoś zanim je opublikował dokładnie wszystko sprawdził, a jeśli teoria jest popularna to oznacza to, że wielu innym udało się ją z powodzeniem wdrożyć w życie.

Ostatnio postanowiłem lepiej przyjrzeć się Scrumowi. Także w tym przypadku sprawdzają się moje wcześniejsze spostrzeżenia – jeśli chodzi o zastosowanie teorii w praktyce to aby w ogóle było to możliwe podstawowym warunkiem jest stosowanie tej teorii od początku do końca. W efektywnym wykorzystywaniu metodologii nie ma miejsca na odstępstwa od zasad. Ktoś kiedyś te zasady dokładnie opracował i przeważnie wynikają one z wielu prób i błędów. Jeśli oczywiście mamy czas i środki na to by powtarzać czyjeś błędy to czemu nie – jak najbardziej powinniśmy eksperymentować, gdyż eksperymenty to najkrótsza droga do udoskonaleń, lecz jeśli chcemy w szybki i sprawny sposób tworzyć produkty o wysokiej jakości to nie ma mowy o eksperymentowaniu. W takich przypadkach najlepiej sprawdzają się rozwiązania wypróbowane już wcześniej przez innych. Stosując daną metodologię od początku do końca zgodnie z jej wszystkimi zasadami mamy prawie stó-procentową pewność, że jeśli coś idzie nie tak jak powinno to nie jest to wina metodologii lecz jakiegoś innego czynnika – np. źle dobrany zespół, nieodpowiednia technologia.

Niestety w życiu bywa różnie, a problem pojawiają się zawsze. Bez względu na to jak mocno trzymamy się ustalonych zasad i jak dobry mamy zespół, w końcu coś pójdzie nie tak jak powinno. Nawet drobne, z początku niedostrzegalne odstępstwa od normy w dłuższym okresie czasu spiętrzają się i nawarstwiają. Na szczęście Scrum dostarcza nam odpowiednich narzędzi do walki z tym zjawiskiem – najbardziej przydatnym jest retrospekcja. W agile zmienność wymagań, założeń, środowisk etc. jest czymś zupełnie normalnym, tak samo jak problemy z niej wynikające, dlatego też w zwinnym zarządzaniu projektami należy walczyć z problemami jak najwcześniej – gdy tylko zostaną zauważone. Właśnie do wczesnego wykrywania problemów służy retrospekcja.

W retrospekcji uczestniczy cały zespół, który na osi czasu (trwania ostatniego sprintu lub kilku sprintów) zaznacza wszystko to co było lub mogło być istotne i mieć wpływ na przebieg sprintu. Jest to pewna odmiana burzy mózgów, podczas której jak sama nazwa wskazuje wyciąga się wnioski z tego co wydarzyło się w przeszłości. Ważne jest to, by wskazywać nie tylko negatywne rzeczy ale także to co było pozytywne, daje to lepszy pogląd na sytuację w zespole i pozwala na opracowanie lepszych sposobów organizacji zasobów czy motywowania. Z założenia zespół w Scrumie jest samo organizujący się i właśnie dzięki temu podczas retrospekcji jego członkowie sami dochodzą do problemów które napotkali podczas realizacji projektu, a także sami dochodzą do tego jak te problemy rozwiązać i co zrobić by nie powtarzać tych samych błędów w przyszłości. Oczywiście samo przeprowadzenie retrospekcji to nie wszystko, ważne jest by wnioski z niej wyciągnięte zostały utrwalone.

Czasem bywa tak, że wniosków jest bardzo dużo a co za tym idzie potencjalnych usprawnień procesu jest jeszcze więcej. Niestety przeważnie próba poprawienia wszystkiego „na jeden raz” ma małe szanse powodzenia. Rozwiązaniem tego problemu jest odpowiednie kategoryzowanie problemów na te poważne i mniej istotne, można to zrobić np. przy pomocy głosowania, gdzie każdy uczestnik ma do dyspozycji kilka głosów (ich liczba powinna odzwierciedlać ilość problemów, które chcemy w najbliższym czasie rozwiązać). Przy pomocy głosowania ustalamy priorytety.

Po wprowadzeniu poprawek w kolejnym sprincie warto przeprowadzić kolejną retrospekcje by sprawdzić na ile udało się poprawić proces, oraz by ustalić nowe priorytety pozostałych problemów.

Reasumując retrospekcja to narzędzie, które jeśli zostanie wykorzystane w odpowiedni sposób daje nam wiele możliwości i informacji na temat tego jak wygląda praca w naszym zespole. Można by pokusić się o jakąś głębszą psychologiczną analizę tego narzędzia i korzyści z niego płynących, lecz wydaje mi się to nie potrzebne.

Dodaj komentarz więcej...