Pixar workplace

Uważam, że Pixar jest bardzo produktywną firmą, gdzie bardzo zdolni i kreatywni pracownicy mogą realizować piękne projekty. Zastanawiam się czy prace Pixar'a są takie dobre z powodu bardzo uzdolnionych ludzi czy z powodu stworzenia miejsca pracy (środowiska współpracy) dzięki którym pracownicy są bardziej kreatywni.

Bulge bracket, Tier one i Boutiques

Jak zaczynałem prace w banku inwestycyjnym to jeszcze nie znałem tych określeń. Te określenia są tylko dla banków inwestycyjnych. Określenie "Bulge bracket" odnosi się do grupy z największymi bankami inwestycyjnymi. Te bank mogą udzielać największy zakres usług inwestycyjny. Tranzakcie mogą nawet wynosić do 10 miliardów dolarów. Takie banki nazywane są large-cap'ami, a banki z transakcjami między 2 a 10 mld to middle-cap'y. Zazwyczaj bulge bracket'y udzielają takich usługi jak doradztwo, sprzedaż, Market-Making, badanie rynku i instrumentów finansowych takich jak akcje, derywatywy, kredyty itp. Banki te są bardzo często zaangażowane w tworzenie nowych produktów takich jak papiery wartościowe zabezpieczone hipoteką (mortgage-backed securities), swapy ryzyka kredytowego, czy w handel emisją CO2.

Tier one's to pretendenci do bycia w grupie Bulge bracket'ów. Są to duże banki, które udzielają prawie takich samych usług, ale jeszcze nie osiągnęły statusu Bulge bracket.

Boutiques są to małe banki inwestycyjne, których transakcje nie przekraczają mld USD.

Zawsze zapominam jak się nazywają te grupy banków.

Demotywacja w pracy

Gdy zastanawiamy się nad motywacją w pracy to pierwsze co nam przychodzi do głowy to pieniądze. Czy tak jest na prawdę??
Chciałbym Ci przedstawić prezentację pewnego doktora psychologii o motywacji.




Autor prezentacji mówi o tym co nas demotywuje do pracy. Jednym z najważniejszych demotywatorów jest powtarzanie tej samej czynności i nie uzyskiwanie rezultatów z tej działalności - podobnie jest z Syzyfową pracą. Jeżeli już uzyskamy wynik naszej pracy to ten rezultat jest niszczony.

Przypominają mi się słowa jakie wypowiedział A. Einstein: Definicja szaleństwa to robienie w kółko tego samego i spodziewanie się odmiennych rezultatów.

Po przeprowadzeniu paru eksperymentów, Pan Dan dochodzi do wniosku, że ignorowanie ludzkiego wysiłku i pracy jaką włożyło się w wykonanie danego zadania jest prawie tak samo złe (demotywujące) jak wyrzucanie rezultatów swojej pracy.


Inne filmiki Dan Ariely można znaleź na jego stronie.

Doc Sprint

Jak myślisz, kiedy należy pisać dokumentację do projektu?


Wiesz jak to jest, zespół nie ma czasu na pisanie dokumentacji do istniejącego projektu, bo PM zawsze mówi, że brakuje jakieś bardzo ważnej funkcjonalności bez której to projekt nie ma sensu i dopiero jak skończy się tą jedną funkcjonalności to będzie czas na zrobienie dokumentacji. Ale później będzie błąd krytyczny lub inna bardzo ważna i potrzebna funkcjonalność i nadal nie będzie czasu na pisanie dokumentacji.

W metodyce scrum, sprint (przebieg) to przedział czasowy dostarczający klientowi działający produkt. Ale co z dokumentacją? Kiedy należy pisać dokumentację? Na końcu bieżącego sprintu czy na początku następnego sprintu? Czy lepiej jest na bieżąco pisać, czy jednak zmiany są zbyt często i lepiej jest pisać dokumentacje co kilka sprintów. Może jednak należy wyznaczyć osobny sprint do pisania dokumentacji?

Nie znam odpowiedzi na te pytania, ale podoba mi się koncepcja krótkiego sprintu poświęconego tylko na dokumentacje. Ten sprint nazywa się Doc Sprint. Doc Sprint może trwać od 2 do 3 dni. Jeżeli ten sprint potrzebowałby trwać dłużej niż 3 dni to oznacza, że dokumentacja jest źle zarządzana, za bardzo było się skoncentrowany na samej funkcjonalności projektu, albo mamy problem ze zbieraniem danych potrzebnych do dokumentacji (problem z knowledge sharingiem).

Wiem, że sprint bardziej jest dla klienta produktu niż dla zespołu, gdyż zasadą jest, że zmiany wprowadzone w sprincie musza być namacalne dla użytkowników (musza mieć nową widoczną funkcjonalność). Ale w trakcie sprintu można wprowadzić wewnętrzny, mniejszy sprint poświęcony tylko dokumentacji.

Korniszonek w BDD

Wymagania szczegółowe aplikacji można zapisać w języku Gherkin. Język ten składa się z 5 słów kluczowych (Given, When, Then, And, But).
Poniżej jest przykład użycia tego języka:

Scenario 1: Zwrot zepsutych butów do magazynu w sklepie
GIVEN: klient kupił buty z naszego sklepu
AND: buty przepuszczają wodę w deszczowe dni
BUT: data zakupu nie starsza niż rok
WHEN: klient zwraca buty,
THEN: buty powinny być w magazynie

Scenario 2: Zakup pasty do butów o 50% taniej przy zakupie butów
GIVEN: klient kupił buty
WHEN: klient chce kupić pastę do butów
THEN: cena pasty do butów o 50% taniej

Są to proste przykłady zastosowania języka Gherkin, które przedstawiają różne zachowania aplikacji.
Więcej można poczytać w książce The Cucumber Book: Behaviour-Driven Development for Testers and Developers oraz na stronie jednego z projektów BDD dla języka php.

W tematyce BDD i Gherkin jestem świeżakiem, ale uważam, że warto zainteresować się tym językiem, gdyż nie wymaga umiejętności programistycznych ze strony testera, PM czy BA, aby napisać przypadek użycia. Książkę jeszcze nie przeczytałem, ale w wolnej chwili muszę się zabrać za nią :)

Kiedy pisać Unit Test?

TDD jest bardzo popularnym podejściem do pisania kodu. Najpierw piszesz test sprawdzający funkcjonalność, który nie przechodzi, później implementujesz ta funkcjonalność, aby ten test mógł przejść, a na końcu refaktorujesz kod i od nowa zaczynasz pisać kolejny test.

Dużo jest przeciwników TDD, gdyż uznaje się, że TDD jest zbyt wolny, nie nadaje się do małych zmian i nie ma czasu na 'ekperymentowanie' z TDD. Nie jestem w tym ekspertem, ale jedno wiem. Pisanie kodu produkcyjnego z TDD nie jest wolniejsze od samego pisania kodu, ale pisanie kodu eksperymentalnego z TDD jest wolniejsze od samego pisania kodu. Jest to najprostszy argument, przeciwko TDD.

Innym podejściem do pisania testów jest zasada Test-First. Kiedyś byłem, na praktyce w zagranicznej firmie, w której dwóch doświadczonych programistów pisało kod z takim podejściem. Jedna osoba pisała testy, a druga osoba implementowała te testy. Wszystko ok, ale bardzo często implementator kodu przychodził do twórcy testów, aby zmienić testy - w trakcie rozwoju aplikacji funkcjonalność się zmieniała jak i pomysły rozwiązania problemów. Test-First bardzo dobrze uzupełnia się z TDD, gdyż jedna osoba (na ogół jest to architekt) pisze podstawowe testy (kontrakty), a implementator kodu dodaje bardziej szczegółowe testy.

Ale, skoro TDD zawiera bardzo dużo czasu, a testy pisane metoda Test-First są często zmieniane to może pisać testy metoda Test-After? Minusem Test-After jest to, że bardzo trudno jest uzyskać wysokie pokrycie kodu. Mamy wtedy wewnętrzną potrzebę, aby zmienić coś w kodzie, aby łatwiej można było napisać test, nie mając przy tym gwarancji, że po zmianie wszystko będzie działało. Na dodatek nigdy nie ma czasu na testy i wszyscy mówią (managery), że po ważniejszych zmianach będzie można przetestować funkcjonalność. Oczywiście po tych zmianach nie mamy pewności czy wszystko działa tak jak wcześniej działało.

Może pisanie testów nie powinno być z góry określone, kiedy należy pisać. Może wystarczą testy, kiedy mamy taką potrzebę - Test-Whenever. Coś takiego jak zasada 80-20. 20% testów sprawdza 80% funkcjonalność. Niektóra funkcjonalność nie potrzebuje testów, a przy kodzie, gdzie mniej bezpieczniej się czujemy to możemy napisać więcej testów. I ta metoda ma swoją wadę. Zawsze jak zaczynam pisać nowy kod to mam wrażenie jakby wszystko było czytelne, oczywiste, proste i wszyscy powinni zrozumieć co kod robi, ale jak po roku wracam do swojego kodu to klnę na autora tego spaghetti kodu :)

Może testy nie powinny wyjść z potrzeby autora code, ale od osoby, która robi code review.

Dylematy z pisaniem testów jest bardzo dużo. Każda metoda ma swoich zwolenników i przeciwników. Może lepiej będzie zastosować metodę Test-Never?

Spotkania z "Brown Bag"

Brown Bag to potoczna nazwa opakowania na lunch.



Brown bag seminar to szkolenia albo sesja informacyjna o rzeczach związanych z pracą zorganizowana podczas obiadu. Seminarium ma taki minus, że jest to spotkanie, które trwa koło godziny.
Brows Bag Meetings to spotkania, gdzie dowolna osoba może przedstawiać ważne informacje w ciągu trwania luncha (w praktyce 15 minut).



Dużym plusem takich spotkań jest transfer informacji wśród ludzi pracujących w firmie. Czasami tak jest, że 2 sąsiednie zespoły w obrębie jednej firmy nic o sobie nie widzą. Bardzo podobnie jest z scrum meetings, gdzie każda osoba w zespole wie co robi inna osoba, ale w firmie mamy kilka projektów, to zwyczajny pracownik nie ma bezpośredniej możliwości dowiedzenia się co dzieje się w innych projektach. Oczywiście jest Scrum of Scrums Meeting, ale na tych spotkaniach jest transfer informacji na wyższym szczeblu. Brown Bag Meetings daje możliwość wszystkim pracownikom udziału w życiu firmy.

Nie bądź krabem

Nie jestem miłośnikiem owoców morza, ale chciałbym Ci opowiedzieć o krabach i krabobraniu. Na ogół kraby są bardzo szybkie. Weźmiesz jednego kraba do pudełka i on ucieknie z niego. Wystarczy, że do tego samego pudełka włożysz drugiego kraba. Kiedy jeden krab będzie chciał wyskoczyć z pudełka, to ten drugi złapie go i nie pozwoli, aby on mógł uciec. Jeden i drugi wie o tym, że zaraz zginie, ale nie pozwoli, aby drugiemu udało się przeżyć. Nawet, gdyby działali osobno to mogli by z tego pudełka uciec. Takie zachowanie można zaobserwować w ludziach i nazywa się to syndromem krabów w wiaderku. Na pewno już spotkałeś się z taką sytuacją. To co mogę Ci doradzić to jak najszybsze odseparowanie się od takiej osoby.

A jeżeli ty jesteś krabem, to wiedz o tym jak one kończą.