Powiew świeżości

29 października 2011

Jak uniknąć stagnacji, rutyny, braku nowości itp. w pracy?

Wczoraj rozmawiając z kolegą zaproponowałem zrobienie prostej aplikacji.

Odpowiedział: „O ciekawe! Myśleliśmy już o tym – super pomysł…. Kiedyś mieliśmy „dni innowacji”, ale potem z czasem jakoś przestaliśmy je robić. Gdzie podziały się te pomysły?

Zapewne jest wiele sposobów na podtrzymanie ekscytującej atmosfery w pracy.

Oczywiście potrzeba ludzi wkręconych i kochających to co robią. Ale Ci ludzie pozostawieni sami sobie z czasem popadną w rutynę, będą znali się na wylot, będą mieli swoje ulubione techniki i style pracy.

Naszemu zespołowi może pomóc: czytanie książek, blogów, Twittera i wyjazdy na konferencje. To zapewni przypływ świeżych pomysłów.

Ale skąd brać siły na ich wdrażanie w terenie, który jest dobrze zbadany i unormowany? Czasem, zwłaszcza z małymi rzeczami nie jest to problem: „Spróbujmy przez tydzień programować w parach.. Hmm, czemu nie?„.

Czasem nie jest to takie proste: „Spróbujmy wrzucać nasz soft na produkcje jednym kliknięciem myszki.. No co ty, to się nie uda, za dużo biurokracji, próbowaliśmy„. Każdy wie, że jest coś czego nie da się zrobić, ale przychodzi ktoś kto nie wie, że się nie da i robi to ! ” Albert Einstein. Jednym słowem potrzebujemy studenta :) .. Lub, kogoś z autorytetem i wiedzą że się da, bo zrobił to gdzie indziej: konsultanta.

Na chwilę obecną uważam, że by zapewnić przepływ świeżej krwi w zespole potrzeba: konsultantów, którzy są z zespołem od 3 do 6 miesięcy i studentów. Konsultanci wzbogacą zespół ideami z innych miejsc, w których byli. Studenci będą zadawać pytania. Wszystko to zachwieje ustalonym statusem quo i zapewni jakże potrzebny powiew świeżości.

Masz jakieś doświadczenia lub przemyślenia w tym temacie?

Język opcjonalnie typowany – Dart

20 października 2011

Poniższy wpis jest częścią serii opisującej moje wrażenia z konferencji GOTO Aarhus 2012. Więcej o tej konferencji. 

Na otwarcie konferencji Google przygotowało niespodziankę – nowy język programowania Dart. Dokładnie, została zaprezentowana wczesna wersja języka, nad którym ciągle trwają prace.

Jest to język opcjonalnie typowany. Możesz używać typów, ale nie musisz. Jeśli będziesz używał typów, kompilator pomoże Ci podpowiadając co dany typ potrafi lub sugerując, że chyba używasz nie poprawnego typu. Nie mniej kompilator nie będzie Cię do niczego zmuszał – to czy Twój program będzie działał czy nie, okaże się po uruchomieniu (podobnie jak w przypadku JavaScript).

Po co nowy język?

  • Dart ma być językiem, w którym „trudno” jest pisać nie wydajne programy. Google chce ułatwić swoim programistom pisanie aplikacji, które działają szybko.
  • Dart kompilowany jest do JavaScriptu, więc może działać na większości „nowoczesnych” przeglądarek. Trwają również prace nad maszyną wirtualną Darta, która będzie częścią przeglądarki Chrome. Jedna z ciekawszych opcji: „snapshot” kodu (kod może zostać prekompilowany i dostarczony do przeglądarki w postaci gotowej do wczytania do pamięci), ułatwiający bardzo szybki i wydajny start aplikacji.
  • Model konkurencji zaczerpnięty z języka Erlang. Izolaty na wzór aktorów.
  • Przemawia do ludzi z dwóch obozów (języki dynamiczne (JavaScript), języki silnie typowane(Java)
  • Być może zastąpi Javę na platformie Android?
Materiały
Język wydaje się fajny. Na następnym dojo zaproponuje, by rozwiązać w nim jakiś problem. Ciebie również zachęcam do poeksperymentowania ;)

 

 

 

 

Warsztaty: A user user manual z Chrisem Nodderem

20 października 2011

Poniższy wpis jest częścią serii opisującej moje wrażenia z konferencji GOTO Aarhus 2012. Więcej o tej konferencji.

Warsztaty: A user user manual (how to build software that works the way your users think) z Chrisem Nodderem

W czasie warsztatów kilka razy przewinęło się: „Obserwuj normalnych użytkowników używających twoje oprogramowanie. Będziesz zaskoczony co z nim robią” (Tip: Ludzie z branży IT nie są normalni ;) Są z reguły ekspertami w korzystaniu z komputerów).

Materiał przedstawiony w warsztatach został podzielony na zasady dotyczące:

  • aspektów poznawczych
    • komputery dobrze radzą sobie z „liczeniem” i „pamiętaniem” – w przeciwieństwie do ludzi. Tworząc nasze interfejsy powinniśmy o tym pamiętać, i nie zmuszać ludzi do wykonywania tych czynności.
  • aspektów dotyczących postrzegania
    • Zasada grupowania - jako grupy postrzegamy obiekty które: są blisko siebie, są podobne do siebie, tworzą rozpoznawalny kształt
    • superstitious behavior - zabobonne zachowanie. Użytkownicy czasem doszukują się prawidłowości tam gdzie ich nie ma. Zawsze włączam najpierw Worda, a dopiero potem Internet Explorera, bo w tej kolejności działa (zadziałało kiedyś).
    • Użytkownicy nie czytają tego, co do nich piszesz! Nie czytamy tekstu – skanujemy. Z badań z wykorzystaniem śledzenia ruchu gałek ocznych wynika, że ludzkie oczy skanując tekst bardzo często podążają za wzorem litery F. Czytamy pierwsze kilka zdań tekstu, następnie pierwsze słowa w lewej części ekranu, aż „wyczujemy” zapach interesującej nas informacji. Wtedy zaczynamy znów czytać dokładniej. Skąd charakterystyczny kształt litery F.
  • aspektów fizycznych
    • Prawo Fitt’a. Łatwiej jest kliknąć w coś dużego, niż w coś małego ;)
    • Nazwy przycisków, linki, powinny opisywać co robią. Zamiast „OK” -> „Zapisz”. Zamiast „Kliknij tu” -> „Przejdź do koszyka z zakupami”.
    • Jak bardzo cierpliwi jesteśmy?
      • mniej niż 0.1 sekundy, gdy przeciągamy coś po ekranie
      • mniej niż 1 sekunda, po kliknięciu w przycisk
      • mniej niż 10 sekund, by utrzymać koncentrację na aktualnym zadaniu, np. startowanie aplikacji (by rozpocząć z nią pracę).
    • Historia dotycząca „cierpliwości” i instalacji Windows Service Pack 2 dla systemu XP. Proces instalacji tego serwis packa wymagał restartu systemu, po którym system „wstawał” na wielu komputerach przez parę minut. W tym czasie ekran był „czarny”. W czasie testów z użytkownikami, okazało się że wielu z nich widząc czarny ekran „tak długo” decydowało się zrestartować komputer jeszcze raz. Powodowało to trwałe uszkodzenie systemu. Problem został rozwiązany przez zastosowanie stałego wizualnego indykatora postępu: kropek wypisywanych na ekran w odstępie około jednej sekundy.
  • aspektów dotyczących „workflow”ów
    • „Sprytne” wartości domyślne. Pokazując, która opcja jest preferowana/domyślna, ułatwiamy życie użytkownikom. Większość użytkowników nie zmienia wartości domyślnych. „Sprytne” – by je zdefiniować, czasem potrzebne jest badanie na użytkownikach by „odkryć” co jest preferowanym wyborem.
    • Użytkownik może mieć więcej lub mniej kontroli nad wykonywanym zadaniem. Może być prowadzony (przy pomocy „wizarda”) lub sam może decydować o wykonywanych akcjach i ich kolejności. „Wizardy” są preferowane dla zadań, które użytkownicy wykonują rzadko i nie są w nich biegli.
    • Ujawniaj informacje stopniowo. Np. w czasie instalacji można wybrać instalację „standardową”. Dla ciekawskich, dostępna jest opcja by kliknąć i dokładnie dowiedzieć się, co składa się na tę instalację.
  • aspektów dotyczących komunikacji
    • Wydrukuj wszystkie „ekrany” w aplikacji i powieś obok siebie na ścianie. Czy są spójne?
    • „Pomoc nie pomaga”. Bardzo często pomoc pisana jest z perspektywy funkcji, jakie aplikacja dostarcza. Użytkownicy z reguły szukają pomocy na temat tego, jak wykonać jakieś zadanie. Dlatego np. FAQ są bardzo skuteczne.
  • jak zachwycać użytkowników
    • Czy użytkownicy używając danej funkcjonalności będą zachwyceni?
Oprócz teorii dlaczego, było dużo konkretnych przykładów jak to wykorzystać w praktyce. Podobało mi się to jak Chris prowadził zajęcia. Jest wyluzowany i potrafi ciekawie opowiadać. Polecam.

GOTO Aarhus 2011

20 października 2011

Drugi tydzień października spędziłem na konferencji GOTO w Aarhus. Jak zwykle było to bardzo intensywne doświadczenie ;)

W telegraficznym skrócie:

Niedziela

  • Warsztaty A user user manual z Chrisem Nodderem. Porady na temat tego jak tworzyć przyjazne i łatwe w użytkowaniu oprogramowanie + teoria na temat tego, jak zachowują się użytkownicy i dlaczego.

Poniedziałek

Wtorek

  • TODO

 Środa

  • TODO

Czwartek

  • Warsztaty „Evolutionary Architecture – How to Make it Work” z Martinem Fowlerem i Rebeccom Parsons
  • Warsztaty ”Influence Strategies for Practitioners” z Linda Rising

Piątek

  • Warsztaty ”Maintaining and Evolving Legacy Systems” z Frankiem Buschmann

Ogólne komentarze i podsumowanie:

W tym roku do materiałów konferencyjnych dołączone zostały dwie małe książeczki: „The 3 pillars of personal effectiveness” oraz „Priming Kanban” - oryginalne i fajne posunięcie.

I tak na przykład w „Priming Kanban” wyczytałem, co robić gdy osiągamy limit „work in progress„. Jest to moment na dyskusję. Do wyboru mamy albo powiększyć limit (co będzie skutkować zwiększeniem czasu, jaki jest potrzeby by historyjka przewędrowała od „koncepcji” do „wdrożenia”) albo usprawnić/wspomóc „wąskie gardło”. Np. gdy „testowanie” jest wąskim gardłem, może jako programiści możemy zautomatyzować wrzucanie nowej wersji na środowisko testowe? Tak czy inaczej, osiągnięcie limitu „work in progress” jest pretekstem do dyskusji.

Konferencja to również męczące wydarzenie (pełno wrażeń, codziennie integracja), nie mniej z niecierpliwością czekam na kolejną konferencję organizowaną przez Trifork, QCon 2012 w Londynie ;)

Extreme Startup zamiast wtorkowego dojo

14 września 2011

Wczoraj zamiast „normalnego” dojo poprowadziłem mini warsztat Extreme Startup.

Podczas tego warsztatu zadaniem uczestników jest napisanie aplikacji webowej, która odpowiadać będzie na zapytania „wirtualnych” klientów. Uczestnicy warsztatu nie wiedzą, co ich czeka i z logów serwera muszą wywnioskować, czego chcą klienci.

Klienci będą między innymi pytać:

  • Ile jest 2 + 5?
  • Która z tych liczb się największa: 4, 234, 2, 4?
  • Jaki kolor ma banan?
Warsztat jest dość intensywny, jako że uczestnicy konkurują między sobą o to, kto zdobędzie najwięcej punktów. Na bieżąco na rzutniku wyświetlany jest aktualny ranking, co oczywiście wyzwala w uczestnikach chęć rywalizacji.
W zależności od pytania uczestnicy otrzymują różną ilość punktów. Gdy ich serwer odpowie źle, tracą punkty, a gdy ich serwer jest nie dostępny, tracą jeszcze więcej punktów.

W warsztacie wzięło 8 osób, zostały uformowane 4 pary. Zaczęliśmy o 1700 i około 50 minut zajęła nam sesja próbna, gdzie uczestnicy konfigurowali sieć tak, by móc połączyć się z serwerem i odpowiedzieć na proste zapytanie „Jak masz na imię”.

Około 18 zaczęliśmy ”prawdziwą” rundę z normalnymi pytaniami. Niestety z braku czasu, runda trwała tylko około 45 minut. Na przyszłość, „normalna” runda powinna trwać co najmniej 90 minut. Na potrzeby warsztatu przygotowane jest 6 zestawów pytań i wczoraj dobrnęliśmy tylko do trzeciego, a tak naprawdę mało który zespół miał poprawnie zaimplementowane wszystkie pytania z 2 pierwszych zestawów.

Z 4 zespołów tylko jeden pisał testy. Wszystkim zespołom poszło „podobnie źle” – zdobyły po około -2000 punktów. Prawdopodobnie gdyby warsztat trwał dłużej, to w miarę implementowanie poprawnych odpowiedzi dla kolejnych pytań, pary wyszłyby na prostą.

Pary, które używały „cięższych” serwerów aplikacji (jak Jetty ;) ) traciły sporo punktów podczas redeployu aplikacji. Niestety nikt nie pokusił się o rozwiązanie z load balancerem ;)

Technologie jakich używali uczestnicy

  • Scala
  • Node.js
  • Groovy
  • Smalltalk, a potem z powodu problemów Java
We wszystkich zespołach/parach uczestnicy grali rolę programistów. Żaden zespół nie „wprowadził” roli Product Ownera, który analizowałby logi i priorytezował pracę programisty (np. niektóre pytania były dużo prostsze niż inne, podobnie pytania miały różną ilość punktów, czasem wystarczyło zwrócić pusty string.).
Ogólnie chyba się podobało ;) .. Może powtórzymy ten warsztat za jakiś czas…
Ps. Wczoraj wyszła książka Lean Startup. Polecam.