Monday, June 27, 2011

PEA(3): Wyodrębnianie user stories

To jest artykuł z serii Proces ewolucji architektury.

Po dość zgrubnym rozeznaniu się w środowiskowym kontekście systemu, jest czas na nieco więcej konkretów na temat funkcjonalności.

Część I - Przygotowanie


Dobór grupy
Do wyodrębnienia user stories świetnie nadają się spotkania focusowe. I ty pytanie z kim?
Najlepiej, aby grupa była różnorodna. Jednorodne grupy mają tendencję do "krzywienia" user stories. Na przykład programiści formułują je bardzo crudowo.

Aktorzy
Jeśli to możliwe, już na samym początku zidentyfikuj aktorów. Zadaj sobie pytanie Kto będzie wołał ten system?. W tym momencie masz już wstępnie rozpoznanych na następujących aktorów:
  • inne systemy - ponieważ poznałeś kontekst pracy systemu
  • użytkownik - na razie to dość ogólne sformułowanie, taki metaaktor, którego pojęcie będzie dokonkretyzowywać się w trakcie dalszych rozmów
  • dla porządku warto dorzucić jeszcze jednego: Time ; bojownicy o czystość UMLa mnie przeklną, ale wygodnie mieć tych aktorów dla spraw wyzwalanych czasem; jest to wygodne tylko i wyłącznie z tego powodu, aby nie bawić się w dodatkowe tabelki, gdy zajdzie potrzeba wysmarowania pięknego diagramu

Rysunek 1: Wstępny szkic aktorów w systemie
Wstępne nazwanie aktorów pomaga konkretnej zadawać pytania. Głównie o to tu chodzi. Konwencja nazewnicza Ustal ramową konwencję nazewniczą, zazwyczaj są dwie konkurencyjne alternatywy:
  • anglojęzyczna - działa proporcjonalnie do swobody językowej
  • polskojęzyczna - często jeden do jednego przekłada słownictwo binzesowe, ale w kodzie będą wychodzić zabawane pongliszowe kwiatki
Najkorzystniej jest promować taką konwencję nazewniczą, która zmienia jak najmniej przyzwyczajeń. Najczęściej słownictwo biznesowe jest zlepkiem z polskiego, angielskiego, a czasem i z innych języków i trudno je uspójniać. Zmiana organizacyjnej nowomowy trochę boli, ale przynosi niepomierne korzyści w postaci wzajemnego zrozumienia. Wypraktykowałem, że zamiast próbować udowadniać ludziom, że mają złe przyzwyczajenia, o wiele lepiej działa zadawanie pytań uwypuklające niejednoznaczność słownictwa. Na przykład: Co ma Pan na myśli mówiąc <<szkolenie>>. To <<program>> szkolenia, czy <<czynność>> prowadzenia szkolenia? Acha, rozumiem, czyli możemy mówić o szkoleniu <<możliwym do zorganizowania>> oraz <<zorganizowanym>> szkoleniu? Pułapką uspójniania słownictwa jest synonimia nomenklaturze organizacji. Śmiało można zaryzykować stwierdzenie, że każdy dział ma nieco inne nazwy na te same rzeczy i procesy.

Rysunek 2: różne nazwy na te same rzeczy, to jedna z większych trudności
Tego typu różnice dość szybko wychodzą, jeśli zadbasz o wspomnianą wcześniej różnorodność grupy. Kto nazywa ten rządzi Jak najszybciej ustalcie nazwę dla systemu. W przeciwnym razie, będziesz rozmawiać o oderwanych funkcjonalnościach, co sprawi, że zakres systemu będzie stale i nieograniczenie się powiększał. Najlepiej, aby nazwa wzięła się z rzeczywistości np.: kalendarz elektroniczny, aby występowała w informatyzowanym procesie. Łatwo wtedy eliminować wodotryski, zadając proste pytanie Czy dotychczas w kalendarzu również miał Pan możliwość dodawania awatarów? Nic nie mówiące i zbyt ogólne nazwy z kategorii Zintegrowany System Informatyczny, to otwarta furtka do wylądowania poza budżetem lub terminem lub oboma jednocześnie.

Część I - Prowadzenie sesji wyodrębniania user stories

Zasady ogólne Przed przystąpieniem do sesji wygodnie jest mieć jakiś szkic interfejsu użytkownika, żeby skupić uwagę osób. Jeśli ich nie ma to je rysuj. Rysowanie dobrze ogniskuje uwagę i często lepiej pozwala wyrazić myśli. Historycznie user storier spisywane są na małych kartkach. Powiedzmy sobie jednak szczerze, że arkuszem Excela o wiele lepiej się zarządza. Jak to zatem jest z tymi karteczkami? Z całego serca polecam karteczki (żółte, samoprzylepne :) ). Mają one tę wielką zaletę, że budują zaangażowanie interesariuszy. Osoby na spotkaniu są często przytłoczeni dużą liczbą obowiązków, nieco zmęczeni i teraz jeszcze muszą odbębnić z nami spotkanie. Mimo, że rzeczywiście chcą tego systemu, to nie chcą na niego poświęcać czasu - nielogiczne, ale prawdziwe. Jeśli będziesz zachęcać ludzi, aby sami pisali user stories na karteczkach i dodatkowo przyklejali je na fipcharcie, to "wciągną się" w spotkanie, będą bardziej kreatywni. Budując zaangażowanie, zwiększasz swoje szanse na wyodrębnienie rzeczywistych oczekiwań co do systemu zamiast ogólników, które czasem ktoś może chcieć Ci wcisnąć, żebyś tylko dał mu spokój. Zaangażowanie - to jest rzeczywisty cel karteczek. Rzecz jasna, że po spotkaniu możesz przepisać je do Excela, skoro w ten sposób łatwiej nimi zarządzać. Nie jestem fanem zbyt szybkiego wprowadzania narzędzi. Narzędzia (zwłaszcza takie, które narzucają swój proces pracy) częściej przeszkadzają niż pomagają. Fanom narzędzi chętnie polecam Scrum Do. Jest bardzo grywalne, zawiera wszystko co potrzeba, a jednocześnie jest kompletnie nieinwazyjne. Minusem jest to, że działa on-line. Formułowanie historyki Ogólny algorytm prowadzenia sesji wygląda tak:
  1. Ustal uwagę na pierwszym ekranie
  2. Zadaj pytanie: Co można zrobić na tym ekranie?
  3. Skłoń ludzi, aby sformułowali swoje oczekiwania w następujący sposób: Jako <<kto?>>mogę <<funkcjonalność>>, aby <<po co?>>
Struktura zdania, za pomocą którego formułujemy historyjki, jest bardzo chytra. Każda z części tego zdania ma swój ściśle określony cel. Przyjrzyjmy się jej bliżej.
  1. Jako <<kto?>> - tu konkretyzujemy aktorów (role); funkcjonalności nie są zawieszone w powietrzu; dzięki przyporządkowaniu historyjek do ról, łatwiej na późniejszym etapie ogarnąć zasady bezpieczeństwa dostępu do systemu
  2. mogę <<funkcjonalność>> - tu precyzujemy konkretną funkcjonalność, do której dany użytkownik ma mieć dostęp
  3. aby <<po co?>> - ta bardzo ważna część, pomaga użytkownikom uświadomić sobie potrzeby oraz problemy, które zamierzają zaspokoić i rozwiązać za pomocą tej funkcjonalności; dodanie tej części eliminuje sporo niepotrzebnych funkcjonalności, bo gdy ludzie zaczynają zastanawiać się po co coś będzie potrzebne, to czasem dochodzą do wniosku, że po nic
Ogólniki i szczególiki Podczas spisywania historyjek, możemy otrzymać efekt dwojakiego rodzaju:
konkretne user stories
np.: Jako U mogę zobaczyć listę swoich zamówień, aby wiedzieć co już otrzymałem, a czego jeszcze nie; do takich sformułowań zmierzamy podczas pracy z interesariuszami
niekonkretne user stories
np. Jako P mogę zarządzać dokumentami?; słowo "zarządzać" niewiele mówi o tym co właściwie należy zrobić, być może kryje się za tym jakiś ogromniasty epic;

Prawdopodobnie będziesz mieć chęć, aby drążyć niekonkretne historyki, gdy tylko użytkownicy je sformułują. Kłopot w tym, że prawdopodobnie oni sami jeszcze nie przemyśleli co to konkretnie ma być. Proponuję, by chwilowo zostawić je w spokoju. Zapisz je i wróć do nich później, już po sformułowaniu wszystkich user stories.

Dodatkowe porady
Podczas sesji ludzie spierają się o to, co właściwie ma robić dana rola i dość szybko zaczynają roztrząsać kwestie techniczne. Nie daj się wciągnąć w tę dyskusję, ucinaj ją natychmiast i prowadź spotkanie dalej. Na tym etapie eksploracja "w szerz" zamiast w "głąb" zagadnienia, pozwoli Ci szybciej przyswoić sobie wiedzę domenową.

Tego typu spotkania wygodnie jest prowadzić w dwie osoby. Jedna aktywnie moderuje rozmowę, druga nieco mniej zaangażowana zachowuje big picture i wkracza w razie kłopotów.

Thursday, June 16, 2011

Obiektowość dla embedded?

Często zdarza mi się wypełzać poza Javę, z której wyrosłem i ze zdziwieniem stwierdzam, że są inne obszary, w których ludzie mają podobne do naszych problemy i z utęsknieniem spoglądają w stronę gadżetów którymi dysponujemy.

Jakiś czas temu, konstruktywnie krytykując mój wpis, Sławek powiedział mniej więcej coś takiego: "Kto w obecnych czasach podaje w książkach przykłady w C++? Od razu widać, że old school"

Rzeczywiście, większość koncepcji związanych z: refaktoryzacją, TDD, clean code itd. nabrała obecnego kształtu w okół Javy i C# i ich community (tak, tak, pamiętam: Small Talk, C++, GoF - byli pierwsi :)). Jakby te języki były jedyne, dominujące, a inne to tylko marginalne ekstrawagancje. Zerknijmy na ten ranking. Jak widać Java i C# mają towarzystwo i to całkiem spore.

RTS, Entertainment
Mówię o systemach embedded, ale nie telefonach, grach i smartach, gdyż im (wg programistów embedded) bliżej raczej do PC-tów. Mówię o: systemach czasu rzeczywistego, systemach sterowania produkcją, oprogramowaniu obsługującym stacje bazowe w sieciach komórkowych, o komputerach pokładowych w samochodach, o sofcie który jest zainstalowany na naszych kartach kredytowych. Kto by pomyślał, że na takiej karcie jest procesor, a na nim system operacyjny, a na nim dziarsko działa maszyna wirtualna Javy? (@see Java Card)

C rządzi!
We wspomnianych wyżej domenach często króluje język C. Po pierwsze z powodów historycznych - ktoś zaczął pisać w C i tak już zostało.

W miarę rozrostu tego typu systemów, pojawiają poważne problemy z ich utrzymaniem. Miliony wierszy kodu, gęsto pociętych przez dyrektywy kompilatora, kompilacje warunkowe, ifdefy, makra tam, gdzie to tylko możliwe oraz specyficzny sposób oszczędnego nazywania zmiennych zdecydowanie utrudniają rozwijanie tego kodu. Te problemy powodują, że środowisko embedded coraz częściej rozgląda się za podejściem obiektowym, które pomoże tworzyć łatwiejszy w utrzymaniu kod. Napotykają jednak na pewne przeszkody, które budują przekonanie, że obiektowość nie jest dla embedded. Zebrałem nieco informacji nt. tych przeszkód. Niektóre z nich są rzeczywiscie zaskakujące, inne to raczej przekonania.

Brak kompilatorów
Do pewnego momentu nie było zwyczajnie technicznej możliwości skomplikowania kodu. Jeśli już jakieś istniały, to były tak zabugowane, że dyskwalifikowały się same przez się. Sytuację poprawił gcc, który popchnął sprawę nieco do przodu.

Koszt wejścia
O ile maszyna wirtualna Javy jest dla PC-tów darmowa, to za wersję na embedded trzeba płacić grube pieniądze. Doświadczenia zaprzyjaźnionych firm pokazują, że ta implementacja JVM jest koszmarnie wolna. Istnieją sprzętowe implementacje (tak! sprzętowe) maszyny wirtualnej, ale niewiele o nich wiem.

Niedoskonałość sprzętu
W porównaniu do procesorów z kategorii ix86, procesory dla systemów wbudowanych są dość proste (tylko w porównaniu :)). Pisząc usługę EJB nie zastanawiamy się, czy aby procesor działa poprawnie, czy nie będzie błędu w działaniu urządzenia. W aplikacjach embedded niedoskonałość sprzętu jest częstym kłopotem.

Trudności w poszukiwaniu błędów
Tak powszechne zadanie jak poszukiwanie błędów również może nastręczać trudności, gdyż odbywa się to poprzez debugowanie oraz analizę kodu asemblera. Taka analiza jest zdecydowanie łatwiejsza dla kodu napisanego w C niż w C++.

Koronny argument - wydajność
Hmmm, trochę prawda, trochę mit. Tak myślę. Przeanalizujmy.

Po pierwsze:
Jak wspomniałem JVM jest rzeczywiście wolna. Z drugiej strony istnieje przekonanie, że kod napisany w C++ będzie działa duuuuużo wolniej. Tylko czy ktoś to rzeczywiście zmierzył? Czy ktoś napisał dwie tożsame implementacje, jedną w C, drugą w C++ i stwierdził to jednoznacznie?

Po drugie:
Przyczyną mogą być ograniczenia programowe i sprzętowe. Sporo zależy od tego jak jest napisany sam kompilator, czy potrafi wykorzystywać automagiczne sztuczki optymalizacyjne. Innym i często skutecznym sposobem zwiększania wydajności jest zmiana sprzętu. Ten jednak przenika do branży dosyć wolno. Powód jest trywialny - koszty. Nowy sprzęt - większe pieniądze, kolejny kompilator, kolejne bugi itd.

Po trzecie:
W rozwiązaniach embedded rzadko kiedy brakuje np. 5%, 10%, 20% wydajności. Jeśli już trzeba zwiększyć wydajność, bo powiedzmy, nie nadążamy z pomiarem temperatury pieca i grozi wybuchem, to trzeba ją zwiększyć kilkukrotnie. W takim przypadku obniżenie wydajności o parę, paręnaście procent, w związku z konstrukcjami obiektowymi, jest do przyjęcia. Jeśli efektem tego narzutu będzie łatwość utrzymania i rozbudowywania dylemat jest wart uwagi. Tak doszliśmy to wysłużonego już hasła: czytelność ponad wydajność. Nie oznacza to bynajmniej nonszalancji w szafowaniu pamięcią, lecz to aby w pierwszej kolejności koncentrować się na tworzeniu czytelnego kodu, a dopiero w drugiej mierzyć, profajlować i optymalizować.

Co dalej?
Jakie wyzwania stoją przed technikami refaktoryzacji i wzorcami, które w swoim najbardziej światowym wydaniu, utknęły gdzieś pomiędzy Javą a C#?
  • Jak pracować z hybrydowym legacy code, pisanym trochę w C trochę w C++?
  • Jak bezpiecznie przepisywać kod proceduralny na obiektowy?
  • Jakie standardy kodowania przyjąć dla C++, aby uniknąć pułapek wynikających z bogactwa języka
  • Jak sensownie rozwinąć narzędzia wspierające refaktoryzację. Sorki, ale VC++ i wsparcie dla refaktoryzacji to porażka. Visual Assist X jest super, ale to jeszcze nie to. Eclipse C/C++ nie próbowałem, Wind River Workbench jest ponoć dobry, ale i kosztuje słono
  • i cała reszta bajerów, których się w okół Javy i C# dorobiliśmy

Za różnymi problemami oraz przekonaniami kryją się ludzie, którzy poszukują skutecznych rozwiązań swoich problemów. Na pewno coś da się zrobić.

Thursday, June 9, 2011

Value Stream i zarządzanie wymaganiami w korporacji

Małe firmy często opracowują własne efektywne procesy. Programiści i analitycy z jednej z zaprzyjaźnionych firm sami wymyślili Scruma. Serio! Wpadli na dosłownie wszystkie scrumowe praktyki i przestrzegali ich z pedantyczną dokładnością. Co ciekawe, wcale nie uważali, że zrobili coś nadzwyczajnego. Ot, zwykłe zdroworozsądkowe podejście. Kompletnie inaczej jest w korporacjach.

Podczas warsztatów z zarządzania wymaganiami największy challenge mam z pracownikami departamentów IT w korporacjach. Złożoność organizacyjna rodzi kilka dodatkowych problemów.

Hipertraceability
Pisałem na ten temat tutaj. Nie dajmy się zwieść, że pragnienie hipertraceability jest potrzebą organizacji. Nie jest to potrzeba lecz rozwiązanie problemu związanego z bałaganem w wymaganiach. Rozwiązanie to daje złudzenie, że wszystko jest pod kontrolą. Zazwyczaj nie jest.

Wstrzymałbym się chwilowo ze skłanianiem się ku temu rozwiązaniu dopóki dokładnie nie zrozumiemy natury problemu. (tak tak wiem, focus on solutions, not on problems; ale czy można zaproponować rozwiązania nie rozumiejąc problemu? - moim zdaniem nie).

Niech nieco światła na problem zarządzania wymaganiami w korporacjach rzuci parę poniższych akapitów.

Time to market
To, że prace programistyczne rozpoczynają się rok po zebraniu wymagań, to norma. Niestety przez ten czas, konkurencja poszła do przodu, priorytety się zmieniły i zebrane wymagania są (delikatnie mówiąc) średnio przystające do rzeczywistość. Szkoda jednak tracić zabukowane mendejsy, więc parce wrą. Co prawda dzieje się co innego niż pierwotnie planowano, ale dzieje się!

Harmonogram wdrożeń i rezerwacja mendejsów
W organizacji systemów jest od groma i jakość trzeba nad nimi zapanować. Więc w trosce o jak najlepszą organizację prac definiuje się harmonogram wdrożeń. Harmonogram jak harmonogram musi być rygorystycznie przestrzegany, więc jeśli projekt nie wstrzeli się w swój termin, to czeka na następny termin (zatem ewentualna obsuwa nie jest ciągła lecz dość grubo skwantyfikowana).

Ponieważ projekty konkurują ze sobą o miejsce w harmonogramie wdrożeń, a Biznes ma wskaźniki do osiągnięcia, więc przezornie rezerwuje sobie miejsce dwa lata w przód na Jakiś Bardzo Ważny Projekt. Dla uzasadnienia rezerwacji, odbywa się nawet zbieranie wymagań. Jest to jednak sprytny wybieg taktyczny mający na celu zaalokowanie zasobów Departamentu IT "na wszelki wypadek".

Pigułka: Nowy System
Nowe potrzeby = nowy system. Rzesza programistów podejmuje trud stworzenia czegoś nowego, co powiela część funkcjonalności z już istniejących systemów. Jasne, że ktoś powinien pójść po rozum do głowy i wyłożyć co jest grane. Ale kto?: Główny Architekt, Enterprise Architect, Architekt Funkcjonalny, Architekt Systemowy, System Designer, Backend System Designer ???

Mimo szczegółowej procedury decyzyjnej oraz masy zebrań, komitetów, analiz i opinii, powstaje pięćset szósty system, który sprawia, że:
  • potrzeba kolejnego etatu do jego utrzymania,
  • SOA staje się naprawdę jedynym sensownym rozwiązaniem,
  • skomplikowanie procedur organizacyjnych dąży do nieskończoności,
  • końcowi użytkownicy ze starymi przyzwyczajeniami próbują korzystać ze starego systemu na nowy sposób i klną na czym świat stoi.


Paraliż decyzyjny
Wyobraźmy sobie następującą, powiedzmy, że hipotetyczną, sytuację:
  • Komitet sterujący projektu IT składa się z: Prezesa oraz członków Zarządu
  • Komitet spotyka się z Kierownikiem Projektu, aby podjąć decyzję o zmianie harmonogramu tworzenia projektu

Rozmowa przebiega następująco:
  • Kierownik: Czy zmieniamy harmonogram?
  • Prezes: Zmieniamy?
  • Członkowie Zarządu: hmm...
  • Prezes: Tak! Zmieniamy!
  • Kierownik: A zatem wpisuję w protokole: "Komitet sterujący podjął decyzję o zmianie harmonogramu"
  • Prezes: Zaraz, zaraz...Jaką decyzję? Proszę napisać: "Komitet sterujący rekomenduje zmianę harmonogramu". Niech zostanie to zatwierdzone na zebraniu Zarządu.

yyyyy????

Obosieczny miecz standardów
Buy, don't write Wiele kawałków systemu, można kupić taniej niż wykonać. Wiele kawałków do wykonania, można szybko napisać w konkretnych technologiach, bibliotekach, itp. Ale stop! W organizacji standardem jest technologia X i kropka. Z jednej strony ma to sens (na przykład finansowy), z drugiej jest pewnym marnotrawstwem zasobów.

Zmęczony Biznes znajduje drogę na skróty
Ponieważ biznes napotyka powyższe trudności w dogadaniu się z Departamentem IT, radzi sobie w sprytny sposób - zatrudnia jednego lub dwóch programistów we własnym dziale, na własny koszt.

W pewnej firmie jeden z takich "partyzanckich" programistów, w krótkiego czasu naskrobał w pehapie CRM, który zrobił sporą furorę w organizacji. Dostarczał dokładnie takich funkcjonalności jakich było potrzeba. Jak powiedział jeden z programistów z Departamentu IT: ktoś tam siedział, słuchał biznesu i zrobił. Oczywiście CRM był na bakier z: harmonoramem wdrożeń, bezpieczeństwem testami i stosem innych procedur, aczkolwiek miał podstawową zaletę: adresował wszystkie potrzeby Biznesu.

Problem z takim "kukułczym jajem" jest taki, że Departament IT nie chce go tknąć, bo: "nie mamy kontroli nad opensource'owymi bebechami i jak coś się stanie to będzie na nas". Dodatkowo między Biznesem a IT rośnie napięcie ponieważ estymacje Departamentu IT są kilkukrotnie większe niż programisty-partyzanta.

Value Stream
Ktoś kiedyś napisał bądź powiedział: "Informatyzacja efektywnego procesu zwielokrotnia jego efektywność. Optymalizacja procesu nieefektywnego zwielokrotnia jego nieefektywność".

W powyższych przykładach organizacja sterowana jest procedurami, brak jest zorientowania na wartość biznesową. Jasne, że są plany, wskaźniki itd. Ale czy opisane sytuacje nie wskazują, że wartość biznesowa zniknęła gdzieś między procedurami? Brakowało zdefiniowania strumienia wartości biznesowej, czyli zoptymalizowanego procesu zarabiania pieniędzy.

Tajemniczy Dział Optymalizacji Procesów
Organizacje mają świadomość opisanych sytuacji. Jednym ze sposobów jest powoływanie do życia Tajemniczego Działu Optymalizacji Procesów (ew. zatrudniania do tego kosztownych konsultantów). Dział ów to kilka osób, zamkniętych w malutkim pokoiku, które co jakiś czas
objawiają Organizacji nowe i ulepszone procedury. Nie tędy droga, ponieważ procedury procedurami, a ludzie ludźmi. Formalizowanie i standaryzowanie jest ok i przynosi wiele korzyści, ale zaangażowanie i orientacja na wartość biznesową przynosi ich więcej. Trudno mi w tej chwili podać konkretny przepis na to co z tym fantem zrobić. Temat w inkubacji.

Jako zajawkę w pokrewnej tematyce polecam prezentację. (nie wiem ile powisi, więc kiedyś link może się zdezaktualizować)

Tuesday, June 7, 2011

Jak wykorzystać swoje doświadczenie i jeszcze wiele się nauczyć?

Jako że nasza działalność (BNS IT http://www.bnsit.pl) nabiera coraz większego rozmachu, pojawia się miejsce dla osób, które są chętne, aby pracować z innymi w celu dzielenia się wiedzą i doświadczeniem oraz chcą wspierać zespoły w zwiększaniu efektywności pracy.
Zatem jeśli masz doświadczenie praktyczne w pracy na projektami programistycznymi, jesteś kompetentny w PRZYNAJMNIEJ W JEDNYM z następujących obszarów:
- wzorce projektowe
- dobre praktyki pracy z kodem (refaktoryzacja, czysty kod, obiektowość (SOLID, GRASP, interfejsy))
- test-driven development
- domain-driven design
- scrum (agile)
- komunikacja w zespole (w kontekście projektów programistycznych),
- zarządzanie czasem dla programistów,
- zarządzanie projektami,
- zarządzanie wymaganiami, analiza.

Ważna jest wiedza i doświadczenie projektowe, co do warsztatu trenera, jesteśmy w stanie odpowiednio do tego przygotować.

Jesteśmy głównie zainteresowani stałą współpracą. Aczkolwiek ewentualnie opcja współpracy od czasu do czasu też wchodzi w grę.

Pisz śmiało: m [kroppka] bartyzel [mauppa] bnsit [kropkka] pl

Friday, June 3, 2011

Grunt, to prostota

Dostałem ostatnio grę edukacyjną dot. szybkiego czytania. Tak się podekscytowałem nową zabawką, że aż straciłem nad nią kontrolę. Było to tak:

czwartek: Dostałem zestaw płytek. Zaraz po szkoleniu pobiegłem do hotelu i pierwsze co zrobiłem, to szybko rozpakowałem CD1 i chcę uruchamiać.
Nie idzie. Zorientowałem się, że zmieniłem notebooka na mniejszego i nie mam CD.

piątek 16.30: Ciągle myślę o nowej grze. Znam już na pamięć instrukcje i teksty z okładki. Już bym pograł, a tu jeszcze parę godzin podróży z Wrocławia. Wykombinowałem, że wezmę laptopa żony, zgram zawartość płytki, przekopiuję na swojego nooteboka i już. Zaraz potem pomyślałem, że pewnie taka gra zajmuje sporo miejsca i potrzebuje płytki do rozruchu. Wpadłem więc na pomysł, że na drugim laptopie zrobię obrazy, które potem przegram i podmontuję u siebie. Genialne!

piątek 22.00: Znalazłem darmowy program do emulowania napędu DVD. Odpalam Nero...hmm moja wersja robi tylko obrazy *nrg. Obrazów ISO nie robi. Ściągam inny program, który robi już obrazy ISO.
Już miałem kliknąć, ale program informuje mnie, że ma własny bardziej skompresowany. format zapisu obrazów i że ISO jest do bani. Googluję. Ok, więc dla testu przygotowałem dwa różne obrazy: ISO i ten drugi: różnica w rozmiarze = 2MB. Zdecydowałem się jednak na ISO.

piątek 23.50: Obrazy gotowe idę spać.

sobota 13.00: Obrazy mają ponad 4GB. Na mojego pendrive nie wejdą. Szlag! Spróbuję udostępnić pliki poprzez sieć.

sobota 13.45: Dwa Win7 za nic w świecie nie chcą się zobaczyć przez sieć. Powyłączałem wszystkie antywirusy, zapory, filtry i takie tam. Nic. Wygooglałem, że z moim routerm WiFi jest coś nie tak i nici z udostępniania. No trudno. Wystawię przez FTP.

sobota 14.15: Też lipa. Nagle mnie olśniło. Mam dysk zewnętrzny! Przekopiuję na dysk a potem do siebie.

sobota 14:17: No tak. Kiedyś chciałem się łączyć z tym dyskiem przez WiFi i producent zmusił mnie do sformatowania go jako FAT32. Przygotowane ponad czterogigowe obrazy tam nie wejdą. (Zaczynam żałować, że zająłem się informatyką. Gdybym znał tylko ofisa oraz guziki power i reset, to bym komuś za to zapłacił i miałbym z głowy, no trudno).
Podjąłem męską decyzję: przekonwertuję dysk na NTFS i po kłopocie. Google mówi, że polecenie winda ma wbudowane polecenie convert i po kłopocie.

sobota 16.00: Polecenie convert zgłasza błędne sektory dysku, co uniemożliwia konwersję. W eleganckim komunikacie zapewnia mnie, że po wykonaniu polecenia chkdsk będzie ok.

No więc wykonuję polecenie chkdsk, które raportuje błędy i pyta czy naprawić? No, pytanie! Naprawiam. Znów odpalam convert. I znów lipa. Nie można przekonwertować z powodu błędów. Partition Magic napewno sobie poradzi! (żona zaczyna domagać się zwrotu laptopa, jeszczę chwilunia)

sobota 16.30: Sciągam Partition Magic. Odpalam, wybieram partycję, konwertuj na NTFS, ok.....Partition Magic odpala program convert! Efekt do przewidzenia. Grrr!!!!!

sobota 17.00: Po chwili poszukiwania ściągam Norton Disk Doctor. Teraz już będzie ok! Zaznaczam autofix Disk Doctor leniwie rozpoczyna naprawę niemal terabajtowego dysku. Dla uspokojenia tematu poszliśmy z żoną na zakupy.

sobota 21.13: Wciaż naprawia...

sobota 23.40: Dalej naprawia...

niedziela 9.07: Naprawił. Odpalam convert. AAAaaaaaaaaaa!!! Wciąż to samo. Googluję, googluję, googluję. Mam! mój dysk ma ustawiony dirty bit i stąd te kłopoty. Znalazłem jakieś polecenie windozy, które sprawdza ten dirty bit. Odpalam - brak praw do wykonania operacji.

Olśniło mnie, wszystie poprzednie sztuczki nie działały bo programy nie wprowadzały zmian na dysku z powodu braku uprawnień. Tylko dlaczego o tym nie informowały? Tajemnica.

niedziela 11:30: Odpaliłem konsolę na prawach administratora i chkdsk a potem convert. Robi się.

niedziela 12.00: Taaak! Przekonwertowane. Przegrywam obrazy, montuję, instaluję, działa. Na wszelki wypadek sprawdzam rozmiar danych na płytce: 154 MB....!@#*&Y#*! Dlaczego nie robiłem tego na początku?

Wnioski


Chwila refleksji nad moją przygodą, która do złudzenia przypomina mi sytuację, których doświadczam podczas prac programistycznych.

Błąd 1: Brak planu
Nie przygotowałem się do akcji. Nie określiłem jakie działania podejmę - robiłem wszystko jak leci. Nie ustaliłem czasu, który mogę przeznaczyć na to zadanie. Wszystko, co robiłem było totalnie nieuporządkowane.

Błąd 2: Zosia Samosia
Plusem i minusem jednocześnie programistów jest kompetencja. Cokolwiek jest związane z IT potrafimy się w tym odnaleźć. Napisać program - ok!, Postawić sieć - no problem!, poskładać komputer - pewnie! Ponieważ, czujemy się kompetentni w niemal całej branży i mamy feeling jak się zabrać do większośći tych rzeczy, to niechętnie prosimy o pomoc. Ignorujemy zasadę buy, don't write.

Błąd 3: Brak feedbacku
Podejmowałem coraz to nowe działania, mające dość znaczny wpływ na stan mojego przedsięwzięcia, bez rozważania neatywnych konwekwencji. Działałem na chybił-trafił.

Błąd 4: Ignorowanie intuicji
Pierwsza myśl była dobra. Mogłem przynajmniej sprawdzić, czy to zadziała.

KARDYNALNY Błąd 5: Brak koncentracji na wartości biznesowej
Koncentrowałem się na rozwiązywaniu lokalnych problemów technicznych. Już na samym początku zapomniałem o gównym celu tego przedsięwzięcia, czyli: zagraniu w grę edukacyjną. Żadne z moich działań nie dodawała wartości biznesowej. To był marsz ku klęsce.