Blogs

Wiktor's Blog (in Polish): Żeby pobrać Windowsa trzeba mieć… Windowsa

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…

Andy's Blog: The real danger for Scrum

Scrum community is now debating – how Scrum Alliance and Ken Schwaber and certification programs and trainers and all kinds of related stuff will play out or should look like. In the meantime Scrum is in a real danger, which I don’t think is being noticed.

This danger for Scrum and community that grew around it over the years is not in the politics and debates, but in their fallout and the “me-too” frenzy (everyone desperately wanting to write and speak about Scrum and contribute or – more frequently – appear to): Scrum risks being diluted in the babbling of multiple voices each presenting his own version. If anything can be called Scrum and if things ranging from metrics to back rubs can be claimed to be part of Scrum, then Scrum ceases to mean anything.

Why it is a danger? Because Scrum’s biggest advantage over the years has been that it was a very definite, distinct method. Scrum meant three defined roles, three defined meetings (later expanded to four by adding retrospectives), two artifacts and a bunch of rules. There were Ken and Jeff and the organization they created defining what it is, there were trainings available and certificates (no matter how weak) backing them. It was therefore a “product”, something you could take, apply in your company and even check if it was done right.

Figuratively speaking Scrum was standing out like a rock in the cloud of “agile”. Agile is a philosophy, an approach – Scrum is something that is rooted in this philosophy you can take and use without becoming a philosopher.

And that clarity was, I think, the important part of Scrum’s success – the reason why most agile teams use Scrum now (or at least try to). If Scrum looses its focused clarity it would slide back into obscurity and irrelevance, back into the agile “cloud”.

Ken was trying to fight Scrum being diluted with his campaign against ScrumBut, and he is still doing it. Scrum Alliance is, as far as I can see from the lineup for the last Scrum Gathering, sliding towards doing everything agile, even everything “soft skill”. This is what community seems to like, maybe being bored with “pure” Scrum. But it is not what businesses will like when looking for methods to use to improve their processes. Businesses need solutions delivering results, philosophies they are less keen about.

In the meantime PMI is still the winner in the business world because it is still seen as a respectable provider of serious, business centered methodologies – and “fad boys” of the Internet Web 2.0 community are already abandoning Scrum in favor of Kanban or Lean. This may be good in the grand scheme of things, but if Scrum community wants to stay relevant it should refocus on providing the clear cut “product” Scrum was until recently.

To that end healing internal animosities, abandoning “soft skills” (including pure nonsense like my “favorite”: back rubs on daily scrums) and shelving dreams about conquering other industries would definitely help. Scrum practitioners and trainers should focus on helping teams deliver great software using Scrum – focus on what we should be able to do best, on our “core” and make sure we really succeed there.

Wiktor's Blog (in Polish): Rola Scrum Mastera

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.

Wiktor's Blog (in Polish): Kalectwo procesu – czyli moc retrospekcji.

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.

Blog Łukasza: Back from the dead

I’m officially back from the dead. I moved my WordPress instance to a new VPS.
A test instance of Money Tracker will follow. Stay tuned.

Andy's Blog: Scrum politics as seen from afar

Ken Schwaber announced a new certification program, the Professional Scrum Master, and blogs/discussion groups are now full of posts about Scrum, Scrum Alliance and Ken.

Some of the discussion is highly political and I feel some prospective from outside of the “club” is really due. Seen from where I live (Cracow, Poland) it looks like this:

• Back in 2008 there is Scrum Alliance, led by Ken Schwaber, all Scrum gurus are together and everything goes fine, everyone wants to be a CSM. However, some point out this is a phony certificate, because to get it you just have to sit through a two day class and don’t be visibly asleep.
• To address that there is talk of introducing an exam. By October of 2008 the exam is ready to be rolled out, participants to Stockholm Scrum Gathering can take the “test version” of the exam and report what they think of it. Exam is expected to become official pretty soon (January 1st if memory serves me well).
• Then, exam implementation date is pushed back – I was back then told unofficially by “someone close to the Scrum Alliance”, that the reason was some CSTs sold classes promising CSMs without exams and were threatening to sue for lost revenue if exam is implemented.

  Whatever was the reason the exam implementation date is pushed back again and again through 2009, which looks bad – Scrum is supposed to be an effective project management method, however the organization behind it is unable to roll out a simple exam and keep its public commitments.

• Finally, the final date for exam introduction is announced to be October 1st. Then there is an announcement from the Scrum Alliance posted on September 12th that the exam won’t be introduced until 2010 (the pretext this time is supposed need to translate the exam into other languages), then it disappears from site, then on September 15th Ken Schwaber disappears from Scrum Alliance. Then Scrum Alliance announces the exam-that-is-not-an-exam – the exam is introduced, but everyone passes (so calling it an exam is, well, not exactly true) – a true pearl of corporate-style wisdom.
• Then comes the first real test for Scrum Alliance’s leadership – the Munich Scrum Gathering which is not an exact success for the board. None of the hard questions or real problems are met with clear answers then and since. Lack of leadership is clearly visible. Seems no one has not only vision and skills, but above all time and will to push Scrum Alliance forward. Enthusiasts like Tobias Mayer join in, stuff like “innovation games” is taking place, so there is some hope for the future – but overall Scrum Alliance stalls.

Amidst all that Scrum as such looses clarity and edge. Everyone jumps on the bandwagon now that it is seen as a clear winner – and everyone wants desperately to contribute, publish, write, record YouTube videos – anything, just to be known.

Some want to introduce Scrum in all industries, some want to dilute Scrum and agile into some soft-skills bag of tricks (as exemplified by this guy who proposed – apparently seriously – that members of Scrum Teams should offer one another physical affection and backrubs – link, link to prove I’m not making this up).

That leads to much noise about Scrum entering the Net – which, in turn, leads to a lot of ScrumBut. Thanks to all those “experts” who write and write and Tweet tirelessly about what they think Scrum is confusion increases, and with confusion come problems. And indeed voices appear that Scrum is failing in teams where it was introduced.

Clearly, something is wrong with the way Scrum is implemented – and that can indicate a problem with the way Scrum is taught and promoted. Maybe CSTs “club” doesn’t work all that well after all (I know, most CSTs do a great job, but “some trainers” clearly do not)? Maybe some “method creep” between trainers coupled with lack of exams makes CSMs inadequately prepared to implement Scrum?

Ken Schwaber’s Professional Scrum Master tries to address this. There is a body of knowledge (”Scrum Guide”), there is an exam already, there are clear rules as to both becoming a Scrum Trainer (as opposed to CST) as well as rules to retain that status (to ensure there won’t be “creep” of what is being taught) plus the course content itself is updated. Finally, there is clear focus on software development.

Now, I know there were hurt feelings etc., but from my prospective back here I welcome Ken’s initiative. While others were talking Ken simply moved ahead, created something new that tries to address the problems. If it is the right solution – we’ll see, but at least it is a move forward.

Having said that the best next thing that could happen to Scrum is some form of reconciliation between Ken and the Scrum Alliance. Last five months have shown that without Ken at the helm the SA drifts, but it would be a terrible mistake to waste all the enthusiasm and work invested by so many involved in that organization.

Andy's Blog: Overcomplexity

Someone has sent me a link to a quite emotional but interesting article by Tim Bray on why the world of enterprise systems delivers so many failed projects and sucky software while the world of web startups excels at producing great software fast. Tim makes some very valid points about technology, culture and approach to running projects. It is true that huge upfront specs, fixed bid contracts and overall waterfall approach are indeed culprits behind most failed IT projects, and that agile, XP and other key trends of recent years can help.

However, I don’t think they can really cure the problem, because we are facing a deeper issue here: the overall overcomplexity in our civilization.

Main drivers of this overcomplexity are bloated states and economy dominated by corporations. Both states and corporations have IT systems today – and the complexity of those IT systems has to reflect the complexity of organisms and processes they try to cover.

The IT system for a national health care system or a state run compulsory social security “insurance” is a very good example. It must be a complex mess because what it is trying to model and run is a complex, overbloated mess – in most cases a constantly changing mess. And it can’t be launched early because it is useless unless it covers the whole scope of what it is supposed to do: because most of what it covers is regulations and laws you can’t deliver a system that meets half of the regulations or 10% – it can’t be used. By the very nature of the domain the system has to be launched as a finished whole.

Plus, on top of all that, comes the scale. If you can imagine a completely privatized health care no system will ever cover all citizens – each doctor, hospital, insurer etc. will cover just its clients, a subset of the population. A system like NHS has to handle all of the UK’s population by design.

Same problem with corporations, especially those that have been around for long (by long I mean decades, not years): scale and mentality. You just can’t manage 75 thousand people easily, especially if they are spread around the globe, in a simple and agile way.

Just think of all accounting requirements global corporations have to handle with their IT systems – but this is just the tip of the iceberg. Whole world economy floats in a sea of legislation – legislative diarrhea of the last decades produced a legal swamp which is a nightmare to understand let alone model a system to comply with it. For a global corporation multiply that by all the countries it is in and stick some international regulations on top of this. This is something corporate systems have to cope with.

What is also important – much of that overcomplexity is computer driven: it would not have been possible if not for the existence of IT systems and computers that run them.

Take VAT tax – it is so complex I always wonder what idiots gave the Nobel prize to the moron who invented it (well, I used to wonder about that when Nobel prize had any credibility). Clearly, implementing it is completely impossible without computers & systems everywhere.

Same about the legal diarrhea I mentioned – I think it can be largely attributed to Microsoft Word. Ever wondered why the EU Constitution (now disguised as “Lisbon Treaty”) has hundreds of pages while the US Constitution is simple and elegant? Well, they couldn’t have possibly written a couple hundred page document with a quill pen which forced them to produce something concise.

But going back to the key issue of whether the corporate IT systems can be better: they can, but a deeper shift in thinking is needed. Instead of creating huge, complex systems corporate IT should rather be a cloud of simple, small systems built and maintained to provide just one simple service (exactly what web startups are doing – each of them provides simple a service, together they create a complex ecosystem). However, this shift would have to occur on the organizational level too – large organizations with complex rules should be replaced with small, focused entities with simple rules for interaction between them.

But to get there we would need a world-wide “agile adoption” reaching well beyond IT. But that means a huge political change, that is nowhere on the horizon. Unless, of course, one other enabler of our civilization’s overcomplexity fades: cheap, abundant energy.

Wiktor's Blog (in Polish): Continous integration – i po co to wszystko?

Na wstępie chciałbym w skrócie przedstawić podstawowe zasady CI, a może raczej ACI (Automated Continous Integration):

Trzymaj kod w repozytorium
A nawet nie tyle trzymaj co commituj swoje zmiany jak najczęściej, dzięki temu każdy będzie miał możliwość integrowania swoich zmian z Twoimi. Do tego należy także pamiętać o tym aby także updateować jak najczęściej swoje lokalne repozytorium na którym się pracuje aby integrować swoje zmiany z najświeższymi zmianami kolegów.
Cechy dobrego repozytorium to przede wszystkim:
- przejrzysty widok ostatnich zmian
- możliwość tworzenia rozgałęzień i automatycznego łączenia ich
- system powiadomień o zmianach
- łatwa możliwość odwrócenia ostatnich zmian
Osobiście używam GIT i SVN, jak na razie obydwa spełniają większość moich oczekiwań.

Automatyzuj buildy
Buildy powinny być odpalane automatycznie. Do automatyzacji buildów polecam Hudson lub CruiseControll. Warto też wspomnieć o tym co taki build powinien robić, mianowicie powinien:
- odpalać testy jednostkowe
- odpalać inne testy (jeśli są)
- generować raporty z pokrycia kodu testami
- generować raporty z wynikami testów
- wysyłać powiadomienia, zwłaszcza gdy testy nie przechodzą
- powinien być zintegrowany ze środowiskiem RC do którego commity powinny trafiać jedynie, gdy build przechodzi
- powinien generować inne artefakty, które są w danym projekcie potrzebne.

Stosuj TDD
Tak, by to wszystko miało sens potrzebne są testy do kodu, który piszemy. Jak najwięcej testów. Najlepszą praktyką w tej dziedzinie jest TDD – pisanie testów przed napisanie właściwego kodu (ale o tym może innym razem).

Zasada nie zabierania zakiszonego kodu do domu
Każdy programista commituje przynajmniej raz dziennie. Im częściej tym lepiej.

Każdy commit odpala build
Po każdej zmianie kodu powinny być odpalane testy w celu jak najszybszego wykrycia błędów i ich poprawy,a także w celu łatwiejszego wykrycia przyczyny błędu (zazwyczaj należy jej szukać tylko w ostatnim commicie).

Utrzymuj build szybkim
Buildy powinny być jak najszybsze, by niepotrzebnie nie marnować czasu na czekanie, aż build przejdzie. Obecnie rozwiązuje się ten problem w sposób sprzętowy np stosując chmury obliczeniowe do odpalania testów.

Środowisko testowe powinno być bliźniacze do środowiska produkcyjnego
Chociażby dlatego by uniknąć błędów wynikających z różnicy w tych środowiskach.

W każdej chwili powinieneś mieć dostęp do ostatniej stabilnej wersji oprogramowania
Zgodnie ze wspomnianą zasadą Agile, w każdej chwili powinniśmy mieć pod ręką jakąś stabilną wersję oprogramowania teoretycznie gotową do publikacji.

Każdy powinien mieć dostęp do wyników buildów
Na przykład Hudson ma wbudowany ciekawy plugin, który umożliwia graficzna prezentację wyników ostatnich buildów. Tego typu aplikacje mają zazwyczaj także api, które sprzyja tworzeniu własnych rozwiązań do prezentacji efektów testów etc. My w firmie używamy właśnie Hudsona i specjalnego monitora który stojąc w widocznym dla każdego miejscu prezentuje efekty ostatnich commitów.

Automatyczny deployment
Fajny ficzer zwłaszcza w fazie maintenance projektu, gdy zmiany są dosyć często wgrywane na serwer produkcyjny. Istnieją gotowe narzędzia pozwalające na automatyczne deployowanie aplikacji.

Żeby lepiej zrozumieć na czym polega CI należało by się pierw zastanowić po co właściwie coś takiego jak Ciągła Integracja jest nam potrzebne? Najprościej będzie gdy wrócimy do jednego z podstawowych założeń zwinnego zarządzania projektami a mianowicie: “w dowolnym (odpowiednio zaawansowanym) momencie trwania projektu powinniśmy być w stanie dostarczyć ‘jakiś’ produkt, który spełnia pewne założenia i udostępnia pewną funkcjonalność, produkt ten teoretycznie powinien być gotowy do wypuszczenia na rynek”. Idąc dalej tym tropem można łatwo wywnioskować, że aby produkt był gotowy do publikacji musi spełniać pewne kryteria jakości, które powinny zostać przetestowane. By jeszcze lepiej zrozumieć potrzebę ciągłej integracji w projekcie należałoby się zastanowić nad tym w jaki sposób integrować pracę wielu programistów, którzy pracują nad często zazębiającymi się fragmentami kodu. Może aby lepiej zobrazować strukturę problemu posłużę się przykładem w którym zespół projektowy nie wykorzystuje aspektów CI.

Wyobraźmy sobie zespół składający się z pięciorga programistów i dwojga testerów. Zespół ma dostarczyć jakąś określoną aplikację, która ma trzy podstawowe funkcjonalności. Tutaj pojawia się pierwszy problem – jak podzielić pracę? Może niech każdy programista zajmie się pojedynczą funkcjonalnością, a na koniec spróbują zintegrować to wszystko ze sobą (uwierzcie mi są firmy w których taki model wytwarzania oprogramowania jest stosowany na co dzień). No tak tylko, że funkcjonalności jest 3 a programistów pięcioro. Poza tym są jeszcze testerzy, którzy przez większość czasu będą się nudzić. No dobrze – klasyczny model Waterfall zakłada, że testy powinny być przeprowadzane na końcu, więc niech tak będzie. Żeby jeszcze lepiej wszystko zobrazować dodajmy trochę matematyki. Załóżmy, że wykonanie pierwszej funkcjonalności zajmie około 30 roboczogodzin, drugiej 60 roboczogodzin, trzeciej 15 roboczogodzin. Do tego przetestowanie około 1/3 czasu potrzebnego na implementację czyli odpowiednio 10, 20, 5 roboczogodzin (dość optymistyczne, ale realne założenia). Dobrze – prace ruszyły pierwsza po 15 godzinach zostaje ukończona funkcjonalność nr 3, programista który nad nią pracował teraz odpoczywa. Po kolejnych 15 godzinach została ukończona funkcjonalność nr 1, teraz programiści mogą rozpocząć prace nad integracją funkcjonalności 1 i 3, mają na to około 30 godzin. Po 60 godzinach od rozpoczęcia projektu dostarczono funkcjonalność nr 2, którą teraz trzeba jeszcze zintegrować, na tym etapie okazuje się że popełniono kilka błędów w założeniach, czegoś nie ustalono dokładnie etc. wiec integracja potrwa kolejne 20h. W sumie po 80 godzinach pracy dostarczono produkt do testów. Testowanie wraz z poprawkami zajmie około 40h.

Po 120 godzinach pracy mamy gotowy produkt. Przypomnijmy, że dla dwóch programistów nie było pracy, ciężko jest pracować nad jednym kawałkiem kodu na dwóch różnych komputerach. Co najwyżej służyli oni jedynie pomocą swoim kolegom.

A teraz podobny przykład (ten sam problem do rozwiązania) z tym że zespół wykorzysta większość aspektów CI.

Ponieważ wiemy ile szacunkowo zajmą pracę nad każdą z funkcjonalności i wiemy, że funkcjonalność nr 2 zajmie najdłużej pracować nad nią będzie aż troje programistów, dodatkowo programista, który będzie pracował nad funkcjonalnością nr 3 po zakończeniu prac nad nią wesprze kolegę pracującego nad funkcjonalności nr 1. Praca zespołowa jest w pełni możliwa dzięki temu, że zespół korzysta z systemu kontroli wersji, który pozwala na łatwą dystrybucję najaktualniejszego kodu. Dodatkowo testerzy dzięki środowisku, które roboczo nazwiemy RC (Release Candidate) mogą w każdej chwili testować dostarczane funkcjonalności i zgłaszać błędy, które są dużo łatwiejsze do poprawienie we wcześniejszej fazie. Należy też zauważyć, że integracja całości odbywa się od samego początku, gdyż wszystkie zmiany wrzucane są do jednego repozytorium. Czas implementacji wydłuży się zapewne o około 1/3 ze względu konieczność pisania testów jednostkowych (nie jest to wymóg jeśli w zespole są testerzy, jednak dzięki temu ich praca powinna się skrócić o około połowę). Zobaczmy jak to teraz wygląda. Planowane czasy implementacji po uwzględnieniu dodatkowego pisania testów jednostkowych: F1 – 40 roboczogodzin, F2 – 80 roboczogodzin, F3 – 20 roboczogodzin. Testy: T(F1) – 7 roboczogodzin, T(F2) – 14 roboczogodzin, T(F3) – 4 roboczogodziny. Projekt startuje. Po 10 godzinach pracy rozpoczynają się testy dla funkcjonalności nr 2 (wykonuje je jeden tester). Po 16 godzinach od rozpoczęcia rozpoczynają się testy akceptacyjne dla funkcjonalności nr 3, po 20 godzinach od rozpoczęcia ta funkcjonalność jest już gotowa i przetestowana, programista, który nad nią pracował pomaga programiście pracującemu nad funkcjonalnością nr 1 (do jej ukończenia zostało 20 roboczogodzin, podzielone na dwóch daje po 10 godzin). Trzy godziny później rozpoczynają się testy funkcjonalności nr 1. Po kolejnych 7 godzinach funkcjonalność nr 1 jest ukończona i przetestowana – minęło 30 godzin od rozpoczęcia projektu. W międzyczasie po około 27 godzinach od rozpoczęcia projektu zostaje ukończona i przetestowana funkcjonalność nr 2. Wszystko powinno działać i być już zintegrowane, dla pewności testerzy sprawdzą wszystko jeszcze raz – po 8 godzin każdy.

W sumie daje nam to 38 godzin pracy nad projektem, których efektem jest gotowy, przetestowany produkt, którego dodatkowym gwarantem jakości są test jednostkowe. Dodatkowo od pewnego momentu w z środowiska RC mogliśmy pobrać stabilną – przetestowaną wersję aplikacji zapewniającą pewne funkcjonalności. To raczej znacznie lepszy wynik niż poprzednio. Powyższe założenia są trochę naciągane i wyssane z palca, ale uwierzcie mi już kilkukrotnie widziałem nawet dużo bardziej zaskakujące efekty wprowadzenia CI do procesu wytwarzania oprogramowania.

Powyższy wywód jest również pewnego rodzaju odpowiedzią na często stawiane pytanie: “Czy pisać testy jednostkowe?”. Postaram się w przyszłości poszukać (być może samemu przeprowadzić) jakichś badań na temat czasu wytwarzania oprogramowania z i bez. Ogólnie już teraz mogę wnioskując z doświadczenia jednoznacznie stwierdzić, że niemal zawsze automatyzacja testów znacząco przyspiesza pracę nad projektem, a zwłaszcza pracę w fazie maintenance.

Wiktor's Blog (in Polish): Rok 2009 – Podsumowanie.

Po szampańskiej zabawie sylwestrowej przyszedł czas na chwilę refleksji nad minionym rokiem. Dla mnie był to rok dużych zmian i sukcesów.

Rok 2009 rozpoczął się rozczarowaniem zawodowym, które spowodowane było zderzeniem mojej osoby z pseudokorporacyjną ścianą biurokracji, która dość skutecznie blokowała, albo przynajmniej spowalniała moje możliwości rozwoju zawodowego. Powyższa sytuacja spowodowała drastyczną decyzję o zmianę pracy.

Tutaj pojawia się pierwszy sukces – bardzo szybkie (całkowity proces rekrutacji – od wysłania CV do zatrudnienia trwał tylko 2 dni) nawiązanie współpracy z Code Sprinters. Tutaj poznałem świetnych ludzi, którzy bardzo skutecznie motywowali i nadal motywują mnie do dalszego rozwoju i zdobywania wiedzy oraz umiejętności.

Jeśli mowa o sukcesach, to warto nadmienić, że znaczną ich część jeśli chodzi o moją osobę można zaliczyć do sukcesów firmy w której pracuję (albo na odwrót). Może się to wydać trochę dziwne, ale są jeszcze tacy pracodawcy, którzy potrafią stworzyć atmosferę, która sprzyja utożsamianiu się pracowników z firmą, w której pracują. I oto właśnie pierwsza lekcja z minionego roku – bardzo ważne jest aby wszystko to co robisz sprawiało Ci radość, by możliwe było utożsamianie się z tym oraz byś zawsze czerpał z tego satysfakcję. Bardzo ważne w tym wszystkim jest wsparcie innych.

Z nową pracą i związanym z nią natłokiem przemyśleń i wniosków związane było także powstanie tegoż bloga, na którym staram się dzielić z Wami wszystkim tym co sobie uroję. Jeśli oczywiście pozwala mi na to czas.

Kolejną lekcją ubiegłego roku była nauka bezpośredniej współpracy z klientami, którzy nie zawsze są idealni. Powyższe zmotywowało mnie do rozwoju swoich umiejętności interpersonalnych – zainteresowanie retoryką, NLP oraz psychologią.

Moje wcześniejsze zainteresowanie zwinnymi metodami zarządzania projektami sprawiło, iż w Sprintersach poczułem się jak ryba w wodzie. Miałem tutaj możliwość poznania od kuchni Scruma (jak jakiś czas temu stwierdziła moja znajoma jeśli chodzi o Scrum to w Krakowie nie mogłem lepiej trafić niż do CS) oraz XP. Współpracę z Adamem, z którym wdrażaliśmy dobre praktyki związane z nadzorowaniem jakości projektów (automatyzacja, testy regresyjne) oraz wplątanie tego wszystkiego w Scruma uważam za niesamowicie owocną, a jej efekty mogę śmiało uznać za kolejny sukces. Nauczyłem się wiele o procesach testowych, ale jeszcze wiele nauki przede mną.

W międzyczasie odbyła się Sesja Kół Naukowych AGH, na której mój referat o usability został nagrodzony wyróżnieniem. To taki mały osobisty sukces, który można uznać nawet za naukowy – streszczenie referatu doczekało się publikacji.

Później były już chyba wakacje, które spędziłem w pracy i uważam ten okres za bardzo męczący. Zarówno psychicznie jak i fizycznie nie czułem się dobrze. Wniosek, który wtedy mi się nasunął może dla niektórych wydać się oczywisty, lecz dla mnie wtedy taki nie był – należy zawsze zachowywać równowagę pomiędzy życiem zawodowym a osobistym. Uwierzcie nie jest to łatwe. Po wakacjach postanowiłem spróbować naprawić zerwane kontakty ze znajomymi i z satysfakcja stwierdzam, że do końca roku w dużym stopniu się to udało.

Po wakacjach miałem okazję “na boku” uczestniczyć w kilku projektach jako ekspert od użyteczności. Owe projekty już niedługo ujrzą światło dzienne i z pewnością wtedy się nimi pochwalę. Przez cały rok, niestety tylko w mitycznych “wolnych chwilach” trwały prace nad narzędziem do zarządzania testami. Niestety w miarę rozwoju moich umiejętności programistycznych kolejne wersje trafiały do kosza i status na chwilę obecną jest taki, że pozostał sam pomysł i zaimplementowanych kilka podstawowych funkcjonalności.

Co do projektów i pracy nad nimi nauczyłem się także, że nie zawsze najważniejsza jest jakość – czasem dysponujemy ograniczonymi środkami i wtedy musimy znaleźć najbardziej optymalne rozwiązania, niekoniecznie te najlepsze, które mogą się okazać zbyt pracochłonne. Niektóre projekty pomimo tego, że są świetne pozostają tylko projektami i nigdy nie ujrzą światła dziennego. Czasem warto jest wydać projekt średniej klasy, tylko dlatego by najlepszego projektu nie wyrzucić do kosza.

Należało by także wspomnieć o tym, iż udało mi się wrócić na studia, ale co z tego będzie to się dopiero okaże.

Podsumowując rok 2009 był dla mnie rokiem ciężkiej pracy i nauki. Poznałem wiele wspaniałych osób – począwszy od kolegów z pracy, poprzez ciekawe osoby związane z branżą IT, skończywszy na rozmowach z autorytetami w kilku ciekawych dziedzinach takich jak kognitywistyka czy psychologia.

Pozostaje mi tylko życzyć sobie oraz wszystkim Czytelnikom kolejnego owocnego roku, oraz samych sukcesów. Do Siego Roku 2010!

Wiktor's Blog (in Polish): Nieuczciwy monopol Microsoftu – czyli jak odinstalować IE?

Dużo się mówi i pisze ostatnio o nieuczciwych praktykach Microsoftu, a mianowicie o monopolistycznym podejściu do przeglądarek internetowych instalowanych wraz z Windowsami. Niby wywalczono już jakieś ustępstwa ze strony Microsoftu, które mówią o tym, że podczas instalacji Windowsa będzie możliwość wyboru przeglądarki internetowej. Niemniej jednak natrafiłem ostatnio na bardzo istotny problem związany z Internet Explorerem, otóż zaczęło się od tego, że potrzebowałem zainstalować na komputerze starszą wersję Internet Explorera (zainstalowany był IE8). Niestety okazało się, że nie jest to tak trywialne jak mogło by się wydawać. Pierwsza próba ściagnięcia i odpalenia instalatora IE6 skończyła się komunikatem “Nowsza wersja Internet Explorer jest już zainstalowana na tym komputerze”. Z ciekawości spróbowałem jeszcze zainstalować IE7, niestety z takim samym skutkiem. Ponieważ potrzeba posiadania IE6 zainstalowanego na moim Windowsie XP była dość paląca nie mogłem się tak łatwo poddać, więc zgodnie z powiedzeniem “potrzeba matką wynalazku” postanowiłem usunąć najnowszą wersje IE i zainstalować starszą. Wszystko było by ok, gdyby nie jeden szczegół – pełne odinstalowanie Internet Explorera z Windows XP jest niemożliwe. Próbowałem chyba wszystkiego – począwszy od odnistalowania IE za pomocą Menagera Aplikacji, skończywszy na ręcznej próbie usunięcia katalogu z Internet Explorerem z dysku (nawet w trybie awaryjnym jest to niemożliwe). Próbowałem także wyłączyc wszystkie procesy, które mogły by blokowac usunięcie plików IE, niestety nie udało się. Koljnym krokiem było wygooglowanie rozwiązania, które skończyło się odnalezieniem informacji o tym, iż IE można jedynie wyłączyć w Systemie Operacjnym, ale nie ma możliwości jego odinstalowania, gdyż jest on nieodłącznym składnikiem systemu, który jest wykorzystywany między innymi przez usługę Live Update. Po wyłączeniu IE nadal nie było możliwości zainstalowania starszej wersji – ten sam komunikat.

Niestety Microsoft nie pozwala nam na zrobienie kroku wstecz i cofnięcie się do starszej wersji Internet Explorera. Pozostaje tylko jedno rozwiazanie – zainstalować aplikację Multiple IE, która pozwala nam na korzystanie ze starszych wesji IE.

Andy's Blog: Brandt’s Law of NDAs

As agile software developers providing outsourcing services we are frequently asked to sign different NDAs and MNDAs. After over two years and dozens of NDAs I noticed a certain pattern which I will call “The Law of NDAs”.

It goes like this:

“The originality and value of the idea protected by an NDA is inversely proportional to said NDA’s length, penalties involved and insistence on signing it.”

In other words, on average, the more harsh and menacing the NDA is the less original and innovative the idea supposedly protected by it turns out to be.

Interestingly, not only average NDAs and ideas fall under this law, but also do extreme cases. For example, I remember one guy who had a 7 (seven) page long NDA to protect his revolutionary idea that turned out to be yet another social network (which, as far as I know, didn’t in the end see the light of day). Conversely, we had a group of high-profile European entrepreneurs who shared with us their truly revolutionary idea (related to multimedia) without even asking us to sign anything.

One may wonder why it is so, but for now I’m satisfied with having observed the pattern. Has anyone else noticed it?

Andy's Blog: Scrum picture is quite right

David Harvey wrote a piece on his blog entitled “The Scrum picture is wrong” where he says that the well known, canonical even, picture of Scrum loops errs by focusing too much on the product (deliverable, “potentially shippable product increment”) and forgetting that continuous improvement of the team is another important outcome of each sprint that should be shown with another loop.
[Go and read David's piece now if you haven't yet]

As much as I agree with David’s insight I don’t think his version of the Scrum loop should be used to “sell” Scrum outside of our community. I very much value all the focus on teams and their improvement, but it helps to understand that this is something that is important (and should be!) only for us, sitting deep in the software development community. Clients ultimately pay for products, not for our methodologies, our teams improving or our overall well being and happiness.

Let’s take the case of outsourced development, which I know firsthand. Our clients pay us for the product they get from us, but once the project is done they are gone and I don’t think my team getting better on their project is something that even crosses their minds. And why should it, anyway? Unless they would want us to extend their product or start another project with us there is no benefit there for them. What really counts is whether the product we delivered will allow them to meet their business goals, their commitments – and their bottom lines. So when I work to convince them to forget fixed bids and go with Scrum I don’t waste the attention they give me on telling them that thanks to Scrum my team will get better.

But also if you have your own, in-house teams, building your product then in the long term it is that product that counts more than the teams. Why? Well, because not only your clients don’t pay for your teams, but for the product – you also don’t really own your teams. People change jobs (one call from Google’s recruiters to your best people can make your life very hard, believe me), get sick, even die – that’s inevitable. And (as I have learned the hard way) pampering your best people won’t prevent them from quitting – so is probably not worth it. In the long run – measured in years – it counts how much value your clients get from your product, not how perfect your team has become. If your team is getting better with every sprint but your product doesn’t sell you will hit the bottom hard sooner or later. Yes, your company may be then one of those legendary places that excelled technologically but are no longer around (Commodore, SGI etc.) which may be fine for the employees – they will just change jobs – but is not fine for owners and/or investors who will have to cover the loses.

So, team getting better is a tool, a mean, to get a better product, not the other way around (unless you run a monastery – there indeed work is just a tool for monks to perfect themselves spiritually).

Just to make sure no one misunderstands me: I’m not saying we should forget about team improvement, not care about our workers’ well being, career development etc. Yes, we should do all that and more, help everyone excel in what they do, make sure as much as we can people like what they do, heck, do it with passion and care, using fully their potential. All that is important and valuable. But we should not forget that in the end it is the client paying for a product who makes it all happen. And all our methodologies, frameworks and diagrams, all our “management science”, all techniques and research is aimed at improving efficiency – and that means, sorry to be blunt, getting better products faster and cheaper.

So I think the current Scrum picture is quite right in its focus on the product. And the message is spot on. It should be still used to “sell” Scrum to managers, clients and businessmen. David’s diagram is insightful and fine, but let’s keep it within our world of process freaks, agile activists and scrum preachers.

Wiktor's Blog (in Polish): Pierwsze spojrzenie na Google Chrome OS (beta)

Ten post pisany jest z Google Chrome OS…

I stało się – Google udostępniło źródła Chrome OS, a w Sieci pojawiły się pierwsze obrazy tego systemu. Postanowiłem na własnej skórze (a raczej pececie) sprawdzić czym jest to co ma zrewolucjonizować korzystanie z komputerów osobistych. Po ściągnięciu gotowego wirtualnego dysku z zainstalowanym OSem i odpaleniu go w VirtualBoxie nastąpiło pierwsze miłe zaskoczenie: około 25 sekund i już – system gotowy do pracy.

Spróbujmy nasze rozważania skupić nad samą ideą Chrome OS. W zasadzie nie można go porównywać do Windowsa czy np. Ubuntu, gdyż zgodnie z założeniami Chrome OS jest czymś w rodzaju przeglądarki internetowej wzbogaconej o różne właściwości systemu, a nie systemem operacyjnym w pełnym znaczeniu tego określenie. Według twórców Chrome OS będzie dostępny w sprzedaży tylko razem ze sprzętem, co sprawi, iż będzie on skierowany do wąskiej (niekoniecznie) grupy odbiorców. W Chrome OS wszystko skupia się wokół przeglądarki i Internetu. Wizjonerzy z Google proponują by użytkownicy zrezygnowali z przechowywania danych na swoich dyskach lokalnych na rzecz korzystania z serwerów i aplikacji Google i nie tylko. Pomijając wszechobecną paranoję (mniej lub bardziej uzasadnioną) ogarniającą pewne grupy użytkowników Internetu pomysł wydaje się być całkiem niezły. Gdy dobrze przeanalizujemy zawartość Sieci, oraz wszystkie dostępne w niej aplikacje to okaże się, że oprogramowanie zainstalowane na naszych komputerach można by w całości zastąpić tym dostępnym w Internecie. System operacyjny wydajnie korzystający z zasobów Sieci, porzucający standardowy sposób wykorzystywania komputerów osobistych wydaje się być naturalnym kolejnym krokiem w ewolucji tychże komputerów.

W związku z błyskawicznym rozwojem Internetu zmienia się poziom jego abstrakcji a Google wraz z Suse postanowili wyjść temu na przeciw. Jak mawia pewien profesor z którym mam wykłady z Architektury Systemów Komputerowych “Człowiek tak na prawdę nie wymyśla niczego nowego, wszystko co tworzy, tworzy na podobieństwo czegoś co już istnieje”. Zgodnie z powyższym można przyjąć, że system operacyjny można było porównać do biurka pracownika, na którym można znaleźć wszystkie potrzebne do pracy narzędzia, Internet był z założenia połączeniem wielu biurek – jakimś rodzajem systemu przesyłowego/kurierskiego, a Google tworząc swoje aplikacjie takie jak GoogleDoc, GoogleCalendar, GoogleWave etc., przeniosło biurka do Sieci.

Po kilku godzinach zabawy Google OS jestem skłonny stwierdzić, że pomysł może się przyjąć, ale na razie byłbym ostrożny w spekulacjach na temat tego czy system ten jest w stanie wyprzeć obecnie używane Windowsy i Linuxy.

Samo zjawisko ewolucji Internetu jest tematem niesamowicie ciekawym i będę chciał poświęcić mu pewnie jeszcze niejedną notką.

Wiktor's Blog (in Polish): Dlaczego nie lubię IE?

Do tej notki zainspirowały mnie ruch We don’t support IE i jemu podobne, oraz wieści o nadchodzącej premierze Internet Explorer 9. Dla mnie czyli testera między innymi stron internetowych świadomość pojawienia się kolejne przeglądarki spod znaku błękitnego “e” oznacza tylko jedno – więcej żmudnej pracy przy testach cross-browser. IE 9 to najprawdopodobniej jeszcze jeden “badziew”, którego twórcy tylko słyszeli o czymś takim jak standardy W3C, ale o ich przestrzeganiu nie ma mowy. Przecież IE i tak ma 33% rynku w Polsce, a na świecie około 37%  więc kto by się tym przejmował. Na szczęście w ciągu ostatniego roku ilość użytkowników przeglądarek od wuja Billa spadła o około 10% i miejmy nadzieję, że ten trend się utrzyma.

Dobrze, ale dlaczego nie lubię IE? Odpowiedź jest prosta – gdy mam do sprawdzenia kompatybilność jakiejś strony z kilkoma przeglądarkami to wyniki takich testów przeważnie wyglądają mniej-więcej tak:

Załóżmy, że strona była tworzona dla FireFox 3.* (Przeważnie tak jest chociażby ze względu na ilość dostępnych dodatków dla deweloperów do tej przeglądarki), więc zakładamy po przetestowaniu, że ta przeglądarka jest naszym wzorcem – zgodność oczekiwań 100%.

Zaczynamy testy w innej przeglądarce, powiedzmy starsza wersja FF 2.*  zazwyczaj znajdziemy jakieś drobne uchybienia związane raczej z ewolucją standardów (czasem nie do końca przestrzegana jest kompatybilność wstecz) wyniki takich testów utrzymują się przeważnie na poziomie 95%+.

Weźmy inną przeglądarkę niech to będzie Opera w najnowszej wersji – jeśli chodzi o CSS to możemy być prawie pewni, że wszystko jest ok, może czasem wystąpić jakiś błąd, ale to już nasza wina, że zaimplementowaliśmy coś niezgodnie z obowiązującymi standardami (wynika to z tego, że twórcy Opery są mocno związani z twórcami samego CSS i raczej przestrzegają swoich standardów), możemy się spodziewać kilku drobnych problemów z Java Scriptami, ale nic strasznego – wyniki testów około 92%+.

Przejdźmy do naszego ukochanego IE, zacznijmy od IE6 – ludzie nadal tego używają (około 10% rynku). Nawet nie chce mi się opisywać co jest nie tak: Java Scripty częściej nie działają niż działają, nie jest obsługiwana przezroczystość dla obrazków w formacie .png, CSSy dla FireFoxa można wyrzucić i trzeba pisać od nowa itd… Zgodność IE6 z oczekiwaniami 50%-, czasem tych stron po prostu nie da się otworzyć. Odrobinę lepiej jest w IE7 (obcenie największy odsetek wśród użytkowników Internet Explorera), niemniej jednak nadal względnie liczne problem z Java Scriptami. Nie wspomnę o tym, że w IE w ogóle wszystko zawsze wygląda inaczej i jeśli chodzi o CSS to nasze usilne starania by dobrać odpowiednie marginesy, paddingi i grubości ramek by wszystko wyglądało tak jak należy (w FF) w Internet Explorerze 7 będziemy musieli zapewne powtórzyć. Zgodność z oczekiwaniami około 75%+. Obecnie najnowszą wersją omawianej przeglądarki jest wersja nr 8. Tutaj widzimy już znaczącą poprawę, ale nadal czasem występują problemy z Java Scriptami, względnie mniejsze z CSS. Pomimo wszystko dość często zgłaszam błędy związane z tą przeglądarką, więc ogólna ocena na około 85%-.

Tak znaczące różnice oznaczają zwiększenie całkowitej pracy całego zespołu o kilkadziesiąt procent…

Powyższe oceny są dosyć subiektywne i opierają się na moich testerskich doświadczeniach z powyższymi przeglądarkami. Nie wspomnę już o tym, że IE przed wersją 8 był znacznie wolniejszy od pozostałych przeglądarek. Jedynym atutem jest, to że dzięki ładowaniu podczas startu systemu dużo szybciej uruchamia się za pierwszym razem. Niemniej jednak wadą IE jest to, że można go używać jedynie pod Windowsami.

Tak, zdecydowanie nie lubię Internet Explorera. Niemniej jednak ze względu na jedną trzecią udziałów w rynku jesteśmy zmuszeniu dostosowywać nasze aplikacje do pseudostandartów Microsoftu. Pojawienie się kolejnego Internet Explorera oznacza dla mnie zwiększenie ilości testów o jakieś 20% – testów które i tak są już redundante (dla FF2, FF3, IE8 i IE 7). Także wielkie dzięki. Może przynajmniej IE9 wyprze IE6, ale szanse na to są małe, gdyż IE6 jest głównie używane w korporacjach, a tam procedury zmiany narzędzi są dość skomplikowane, a poziom świadomości technicznej osób za to odpowiedzialnych jest raczej niski. Można śmiało stwierdzić, że ze względu na zwiększenie ilości pracym a co za tym idzie czasu, który jest potrzebny by wypuścić jakąś stronę/aplikację na rynek nieprzestrzeganie przez twórców przeglądarek tego typu wszystkich ustalonych wcześniej standartów stanowi świadome lub nie opóźnianie rozwoju Interntetu, co w dzisiejszych czasa oznacza spowolnienie rozwojuz cywilizacyjnego, na który Internet ma dość duży wpływ. Może za tym wszystkim stoją szlachetne idee zmiany świata przez gości z Microsoftu. Przypomina mi się pewne powiedzenie: “Chcesz zmienić świat na lepsze – zacznij od siebie”.

Andy's Blog: Short sight?

Departing from my usual topics I want to share an observation on the big picture that we are being fed by politicians, mainstream media and most of the Internet.

This big picture is – in short – that we humans are damaging the planet Earth, causing catastrophic global warming driven by CO2 emissions due to burning fossil fuels (mainly in cars), as well as having kids, eating meat etc. We are also facing a huge energy crisis, economic crisis, swine flu pandemic and terrorists. Doom is just around the corner, there is no hope unless we submit to a whole portfolio of totalitarian policies proposed by the very same politicians in the very same media outlets.

Apart from whether all of this picture is true (most is not) what is interesting here is a complete lack of any positive program for our civilization.

It seems the only thing our elites can come up with is downsizing humanity by all means possible from contraceptives to choking off industrial production with this whole "carbon tax" scheme. But this is not a positive program, it is at best an idea on how to prolong status quo for those left, especially those on top of the chain. Let’s suppose we will cut human population by 90% (as some "ecologists" – or rather antihuman madmen – are suggesting) – what next? Where is the path upwards, not downwards?

What is amazing is that people in general are not noticing this lack of any long term prospective. They seem so scared of (mostly fake) dangers they see in the media each day they don’t see our leaders have no idea what to do. Or, worse, they have an idea, but it doesn’t include most of us.

All of this is extremely short sighted. Notice that in all of those doom scenarios Earth is being presented as a limited, closed environment – something akin to Eco Spheres. Global warming models, for example, generally don’t factor in the influence of the Sun, space radiation, Earth orbit cycles & changes and so on. So do those who talk about energy and resources scarcity.

The fact is, however, that Earth is just a part of the unimaginably huge and complex system called the Universe. This is our world, not just this tiny rock. And universe is full of energy and matter. Even our own solar system is full of energy and matter way beyond anything we humans may need for centuries. Just the solar energy descending on Earth in the visible spectrum every day is way beyond all energy needs we have or may have in foreseeable future.

Also, as it has been shown, the limit of Earth’s atmosphere is as much a hard limit for life as the water surface is for fish. Fish can’t walk on the land, we can’t get to space without lots of energy and technology – but it doesn’t mean the world just ends there (like they thought flat Earth ends in Middle Ages). Even the limit of Earth’s atmosphere is just an arbitrary line drawn by humans to simplify things – in fact it is a changing continuum between the dense atmosphere on the ground and the vacuum of space above it (and even that vacuum is not completely empty). And that space influences what happens here on Earth in a powerful way – much more so than anything we humans can come up with.

How all that relates to the current picture of doom and gloom? Well – my question is: if we know we’ll run out of resources at some point why we are not trying to get to the resources beyond what is available on Earth? And since when did we forget that for any sane human being fellow humans should come first, before whales and bats? Why instead of trying to kill off humans (or prevent them from being born) – which is what our leaders seem to be busy doing – we are not trying hard to make sure that a) everyone is fed and b) we can have a future in space?

It’s not a problem of technology or money. The technology is there – we have heavy lift rockets, most are just not being produced anymore (like the famous Russian Energia). We even have nuclear technology that could give even better lift and could propel us further than just the Low Earth Orbit, but it never was really used. In fact it seems that when it comes to space technology we are not advancing, not stagnating, but actually falling back.

The money is also there – just the bailouts for the “too big to fail” would have funded NASA for years. This is not mere rhetoric. NASA’s budget for FY 2008 is approximately $17 billion or 0.6% of US Federal budget. The bailouts did cost between $4 to $8.5 trillion according to different sources. That is between 235 and 500 years of NASA’s funding. Or 29 to 63 Apollo programs (cost of whole Apollo program is estimated at $136 billion of 2005 US dollars). And some say the total cost of bailouts etc. is $23 trillion – you can calculate yourself how many trips to Moon, Mars and elsewhere would that buy – even at NASA, known for its wastefulness and reckless spending on bureaucracy etc.

Those numbers show how mad this is, how we risk our collective future by massive misallocation of resources. Can you imagine how much technology and knowledge we could have obtained if just a fraction of those heaps of money wasted on Wall Street would have been allocated to space exploration? How many good, real jobs would have been created – jobs that actually create something, not “service” jobs that mainly mean people flipping burgers and waiting tables?

So something just doesn’t add up here. Either all our leaders just never look up into the sky at night and can’t use their brains for anything other than campaigning – or there is a barrier there we are not being told of. In any case instead of pursuing the only positive path we are being told the best thing we can do is planet-wide civilization suicide.

Which is why I’m sick when I see attempt by mass media and major corporations to create an illusion of grass-root support for the Copenhagen meeting and tax on breathing they want to impose there on the whole world (like this one). What’s really sickening is that this scam seems to work, that people do believe in this whole heap of lies they are being told without questioning them, without thinking. And without realizing there is a positive path – we just don’t follow it, we don’t even consider it.

Andy's Blog: Risk boomerang

In the the world of Scrum & agile there is an ongoing discussion about contracts. Main problem is clash between agile approach of flexibility based on adaptation and the world of RFPs, RFIs and fixed contracts. I’ve seen many good talks and presentations about this, including also on the last Scrum Gathering. One thing I don’t agree with is the way the problem of risk is being handled almost in all of them.

People usually start their talks with the notion that in the basic time&materials contract (the only truly agile contract if you ask me) all the project risk is on the client’s side and other contract types somehow move some of the risk to the supplier. Some go as far as to say that in a fixed bid contract (fixed time, scope & cost) all the risk is on the supplier side.

First time I heard this I thought this is clever, but over time it dawned on me that this “risk sharing” is as much illusory as is the security of the fixed bid contract. Here is why.

The single biggest risk anyone faces when they build something is that this something won’t fit the purpose it was intended for. Causes for this can be numerous: the needs might have been not understood properly or the idea doesn’t fit the market, the needs have changed or the thing built can’t be used because of defects. Finally, the thing being built may be delivered too late for it to be used as intended.

No matter how hard you try the biggest share of this risk is always on the client’s side, because it is the client who won’t get expected benefits in the end. You may add as many penalties and harshly sounding clauses to a very fixed and rigid contract as you want, you still won’t get away from this risk.

Imagine you’ve spent 3 months writing the initial spec, then next two months on RFP/bidding process, then contract negotiation, then two years on developing your complex software system only to discover at the end of all this that the product is not exactly what you intended, is full of bugs and is irrelevant because in the meantime the world moved on (the usual, flawed, waterfall process). What then? Yeah, you can sue the unhappy supplier all the way, but how much good will it do to your business? You can not pay them and even bankrupt them if they were not careful – will that repay all the lost opportunity? Make up for lost time? No way!

This risk is like a boomerang. I’ve heard someone define a boomerang as a piece of wood that no matter how hard you throw away from you will come back and smack you in the face. Very fitting. The harder you try to move away from this risk with complex contracts the more you will be hurt in the end. You don’t need rigid relationship based on distrust to tame this risk, you need an adaptive relationship with people you trust but can check all the time.

That’s exactly what agile offers: tight control of the product being developed in short inspect&adapt cycles. Instead of trying to write clever penalty clauses and waste time on lawyers clients can closely monitor the progress of the team(s) that build their software. They can spot any problems early on and correct them. Or readjust the backlog to changing situation keeping their product relevant. Or change the team.

I’d say there is way way less risk here. What clients pay with for this is their time and involvement – they have to see test builds at least every sprint, they have to speak to the team, readjust the backlog and overall stay on top of their project. But all the time they have all the tools and controls to navigate the project to a successful end. A fixed contract just kills all the outset.

So, next time when people will again define contract negotiation as risk pushing I’ll definitely interrupt them with my little boomerang analogy, because I feel we must all realize this is yet another (paper) illusion.

Wiktor's Blog (in Polish): PyConPl’09 – Python oczyma testera.

Ostatnio miałem okazje uczestniczyć w konferencji PyConPl’09 poświęconej programowaniu w pythonie (i nie tylko). Konferencja odbyła się w ośrodku wczasowym “Gwarek” w  malowniczym Ustroniu. Kto był ten wie jak było, a kogo nie było niech czyta i zazdrości .

Pokuszę się o  krótkie streszczenie tego co według Testera było ciekawe.

Piątek 16 X 2009:
Niesamowicie ciekawy wykład Wesley’a Chuna o referencjach i modelach pamięci w pythonie. Podczas tego wykładu wreszcie udało mi się w pełni (mam nadzieję) zrozumieć idee alokacji pamięci nie tylko podczas programowania w Pythonie. Poza tym na uwagę zasłużyło stwierdzenie Wesley’a – “Wy jesteście młodzi i to do Was należy przyszłość świata”, miało ono sens ponieważ zostało poparte niewątpliwym przykładem w osobie samego Wesley’a który te słowa usłyszał kilka/kilkanaście lat temu od jednego ze swoich nauczycieli i teraz polata jak spojrzał wstecz i podsumował to co udało mu się osiągnąć (kilka książek o Pythonie, wykłady, prelekcje, szkolenia) to faktycznie wniósł jakiś wkład w przyszłość świata.

Sobota 17 X 2009:
Dzień zaczął się od warsztatów Pair Programing i TDD prowadzonych przez Konrada Delaga i Krzysztofa Goja, o ile do Pair Programing (patrząc z boku) jestem dość sceptycznie nastawiony o tyle TDD uważam za podstawę prowadzenia projektów agileowych. Niemniej jednak ponieważ TDD jest u nas w firmie na porządku dziennym i mamy w  tym spore doświadczenie to same warsztaty dla mnie osobiście nie były interesujące (może po części też dlatego, że jednak wymagały umiejętności programowania w Pythonie). Ale brawa dla chłopaków, bo tego typu praktyki trzeba jak najbardziej propagować, jeśli chcemy zapewnić wysoką jakość tworzonych a zwłaszcza rozwijanych aplikacji.

Kolejną dość ciekawą prelekcją było zagadnienie praktycznego wykorzystania Pythona we współczesnych systemach pomiarowych używanych w laboratoriach fizycznych. Prelekcje poprowadził Paweł Nita. Duży plus za pokazanie praktycznego wykorzystania języka.

Następnie bardzo interesujący wykład Marcina Mierzejewskiego o dataminingu i przewidywaniu przyszłości za pomocą Python i Orange. Dla mnie wykład był o tyle interesujący, że po dwóch latach studiów Informatyki i Ekonometrii wreszcie ktoś pokazał mi na prawdę proste ale bardzo efektywne zastosowanie podstaw metod ekonometrycznych i statystycznych. Oczywiście aspekt wykorzystania pythona do tworzenia modeli, które przewidują przyszłość obliczając trendy i inne tego typu rzeczy pokazuje kolejne praktyczne i wydajne zastosowanie tego języka. Sam temat dataminingu jest wart zainteresowania i w mitycznej wolnej chwili na pewno postaram się poszerzyć swoja wiedzę w tym temacie.

A po obiedzie był Adam Zieliński współtwórca serwisu dla kinomaniaków Filmaster.pl. I tutaj przeżyłem szok, gdy usłyszałem, że w serwisie, którego kod jest otwarty nie napisano prawie żadnych testów. Ja bym się wstydził pokazywać innym coś takiego i raczej bym się z tym krył. Niemniej jednak serwis świetny i wart polecenia.

Niedziela 18 X 2009:
Niedzielny poranek rozpoczął Jarosław Zgoda prezentacją o WSGI której konkluzją była idea wykorzystywania istniejących już rozwiązań a nie próba wynajdywania koła od nowa. Prezentacja bardzo wartościowa zwłaszcza dla początkujących programistów, którzy zawsze wiedzą lepiej

Wartym uwagi był też wykład Mrka Gajdy o tworzeniu prostych gier w Pythonie i nie tylko. Chyba nawet złapałem bakcyla, może to fajny pomysł na nowe hobby.

Podsumowanie: Konferencja na pewno pozostawiła pozytywne wrażenie – ciekawa tematyka i świetni ludzie. Kilka minusów organizacyjnych: bardzo marny internet, prąd którego dosyć często brakowało, ciasna i duszna sala etc. ale na plus świetna lokalizacja i doskonałe jedzenie . Mała dygresja – czemu można zorganizować konferencję dla programistów pythona której koszt to około 300 zł, a nie można zorganizować konferencji dla testerów za mniej niż 1000zł?

A i oczywiście podziękowania dla Code Sprinters i Andy’ego za zasponsorowanie naszego udziału w konferencji.

Andy's Blog: Scrum Gathering 2009: day three and final comments.

To wrap up my coverage of the last Scrum Gathering in Munich a couple of words about the last day and then some general comments.

After the lame keynote session on Tuesday I decided to sleep in on Wednesday and I missed Harvey Wheaton’s talk. It didn’t appear particularly interesting on the mini-agenda we were given, looked like another boring life story. My friend Tomek went in, and thanks to him I know I’ve missed a very interesting talk, a real world experience of implementing agile & Scrum in a startup company run by Harvey. Well, next time I’ll be in for Harvey’s talk.

Another session I attended was supposed to be about agile contracts by Peter Stevens. To the surprise of both speakers this talk was squeezed into the same room and time slot with Regina Mullen’s talk. In effect both had time to speak, but not to take many questions from the audience (crowded, as usually, on chairs and in between). Peter’s talk was a mild disappointment for me. I had a chance to talk to him a few times and I read his blog, so I know he knows a lot more about agile contracting. Maybe he just decided to cut his talk to leave some time for Regina. In any case, I didn’t learn much stuff that I would not know before, but I think it must have been a good introduction for the first-time attendees. One thing I’ll remember from this talk is his story about Zurich trams contract. And it also reinforced my resolution to finally write about my take on risk in client-vendor relationships.

Regina’s talk was, on the other hand, an unexpected, entertaining diversion for me. Though she did include her life story into it (like way too many speakers at the Gathering), she did it in a gracious and humorous way and her thoughts on making lawyers use agile were quite interesting, even though I’m clearly not in her target group (IANAL). Nice talk, I just hope she has a chance to present this to lawyers and indeed change their ways. Part of the challenge throughout my career in the IT world, especially as a manager in the last couple of years, has been finding lawyers that would really understand what we are trying to do before helping us draft contracts, user agreement, licenses and so forth. We need more people like Regina there – I definitely would love to talk to a lawyer who does know outright what a sprint is.

After lunch the best regular talk to attend was probably one led by Nigel Baker (I suppose so, as I know Nigel – it’s not possible to get bored when he talks), but tired of all the Scrum politics over lunch I decided to go to the haiku workshop led by Liz Keogh. I was amazed by the results. I really did learn something new I didn’t know before, and it was really easy. It took Liz a couple of minutes to get us to write haikus, and since then they keep on popping up in my mind on their own. Two examples of the ones I did and really like:

Worn green carpet
carries us all patiently.
Thunderstorm!

Engulfed in our own little worlds
between iPod earbuds.
Autumn leaves.

(Haikus composed during the workshop and sent in afterward can be read here).

I resolved to try and write at least one per day. I think they are more than a diversion – they are a great tool to awaken our pattern-matching R-mode processing (read Andy Hunt’s book for more on L&R-modes). Haikus being by definition based on surprising matches can increase creativity by encouraging the R-mode “search engine” to produce more unexpected matches, useful not only for more haikus.

The event ending session was a big surprise. I expected some energizing talk, so I took out my camera to record it. Instead what happened was that after some small talk and a round of due thanks to different people by Tom Mellor a “wave” exercise was performed. It was so jawdroppingly stupid I thanked God I had my camera out so I had a good excuse not to participate in this idiocy without attracting attention. I kept on recording though and I wonder now whether I should put up this video or not, as I’m afraid it could only damage the reputation of the Scrum Alliance.

Interestingly, most people I talked with afterwards agreed it was stupid, but during the round after the “wave” they said BS like “powerful” or “energizing” – only me and one other guy were honest enough to say it was “silly”. To me it was a clear example that whoever was supposed to lead this session just didn’t have anything meaningful to say, so came up with this thing instead.

I think this failure illustrates a deeper problem Scrum & Scrum Alliance has. Scrum is part of the IT industry’s response to the failure of traditional, waterfall based project management in software development that that is called “Agile”. Scrum is a simple framework for managing requirements, work and team during software development projects. Yes, it doesn’t say anything about “software” as such, but this is where its roots are. In other words – it is a way to manage projects (because, I’d argue, Scrum projects are still managed, even if there is no Project Manager as such) created in our industry.

Now we have to decide – is Scrum just that or is it something more? Should we focus on merging Scrum with technical practices in teams and keep focus on software (which is what Ken Schwaber seems to be doing with his new training program aimed at developers)? Or should it be treated as a industry-agnostic project management methodology that could take on PMBOK, Prince-2 and other heavy methodologies everywhere? Or maybe should it be part of the soft-skills portfolio for coaches, HR etc. together with “waves”, collaborative drawing etc.?

The problem here is that traditional management methods work quite well in heavy industries they evolved in, and there are lots of very good people in the soft-skills department – usually better than ex-software developers discovering their “emotional intelligence”.

In any case a choice must be made before Scrum dissolves into mist. Ken, Jeff and Mike did agile movement a great service by laying out Scrum as a clearly defined, tangible thing as opposed to agile’s vagueness. Scrum was something anyone could start using and derive benefit from following its simple rules – because even ScrumButt was giving more productivity than waterfall. That’s why it was so successful – exactly because of its sharply defined edges and simple clarity. Now this clarity can be lost amidst empty motivational talks and silly exercises lifted out of kindergarten.

I know what I wrote will be harsh for some, but well, that’s what I think. And being a nobody in this movement, a nobody living in a place most of you never heard of I can afford the luxury of being honest. And of course one thing will stand: Scrum itself and other agile methods and practices. No matter which Alliance trademarks what you can use them and be better off in your projects.

To close on a more optimistic note some appreciations:

• Thanks to Boris Gloger and his team: they not only provided real, freshly pressed juice and real, freshly brewed coffee but also filled in where organizers couldn’t in a truly agile fashion. Their idea of just copying the materials on pen drives and handing them to people at the end was brilliant. Plus he paid for the beer on Monday.
• Tobias Mayer: another true agilst, when everyone complained about the lack of Open Spaces and the board said they will make them next time Tobias singlehandedly organized “guerrilla Open Spaces” the very same day greatly enhancing the Gathering experience for many. Also, it is Tobias who told me to go to the haiku session instead of political discussions – thank you!
• Howard Sublett and Cory Foy: Scrum Alliance needs more of you guys, not just 5 hours / month.
• Stefan, Robert and other German friends who helped me find my way around Munich and explained some customs during the beer evening.
  Everyone I talked with during the breaks.

Overall, I liked the event as a whole, I hope next one will be way better – and that clouds over Scrum Alliance’s future will be gone by the time we meet again “somewhere in Europe”.

(There will be one more post in the Scrum Gathering series – about Scrum Alliance as such).

Andy's Blog: Scrum Gathering day one and two

Here are my short notes from Scrum Gathering. Overall this edition is slightly disappointing as compared to the last year’s.

First the talks quality is a bit lower than in Stockholm. Or maybe I did end up in wrong ones because I didn’t choose well. Nothing besides the talks titles & speaker names was announced so I could only guess.

Initial remarks by Jeff Sutherland were delivered with his usual zest, but seemed to be just an incremental update from his presentation in Stockholm and his other talks. Must have been quite interesting for first time attendees though. One thing I picked up there is that I really need to read the original Takeuchi & Nonaka paper that started all of this. And I think it is worth exploring what those guys are up to now. If their one paper started this whole movement, then maybe their other work is also valuable.

On to other first day talks: “Coaching Scrum Teams with a User Centered Approach” with Mike Sutton turned out to be much less interesting than I thought. Two things I picked up there were Prezi presentation software and a book about brain functioning – that is before I left 30 minutes into the talk. Simon Bennett did a much better job with his talk on applying game theory to agile contracting. Though his conclusions were certainly nothing new for me his exercises were interesting and kept the group involved. Also Roman Pichler’s talk was interesting, though his delivery style – slow, calm and quiet – is not what I like. He discussed anti-patterns for Product Owners – or common mistakes made by Product Owners. One point we didn’t agree on is what he called “bungee product owner” – I think I’ll write more on this separately.

As far as the first day goes, though, it was Mike Cohn’s talk that was the highlight of that day for me. I recorded the whole talk and with Mike’s permission I’ll post it on-line when I get back.

Second day opened up with some guy from Sweden – Petric Palm – telling us his life story and showing quotations from famous people and nice pictures. Certainly not a keynote level talk. I used that time to do my e-mail.

Next, organizers switched sessions – the one I wanted to go to was replaced with a product owner panel discussion I wasn’t all that interested in. When I realized that I wanted to go to Erez Katzav’s session but the room was already so full of people it wasn’t possible to get in. More e-mail then plus an interesting chat with another guy who did not get inside for the Katzav’s talk.

After lunch finally the highlight of day two came: Serge Beaumont’s talk on tools for product owners (tools meaning practices and mental tools not software tools or anything like it). Learning from the previous sessions I came 20 minutes before the talk so I didn’t have to sit on the floor. Serge talked about ways in which Product Owners can organize their work and collaboration with the team, especially around that part of the backlog that is not yet inside the sprint. Serge’s observation is that once team is running at high speed with Scrum POs quickly run out of backlog or they are not fully prepared at the outset. The cure is to define a READY state for items that can go into sprints – an equivalent of the DONE state at the end of sprint – then build a Kanban-based flow that feeds the backlog of READY items so that it is never empty. Great talk and I’m looking forward to seeing the slides posted.

Finally, the day ended with the Scrum Alliance board – or part of it – answering questions. I have to say that it was a depressing experience. Both Jeff Sutherland and Mike Cohn were not present, I think they have left earlier, which was a surprise. The four board members present were looking sad, devoid of energy and vigor as they sat collapsed in their chairs. Sadly, the Alliance’s support staff – Howard Sublett, Cory Foy and others – looked much more energetic and alert than the board.

Plus the style of board’s answers was like on a corporate meeting: very diplomatic, rather avoiding or deflecting questions than giving any straight answers. For example someone asked if the board will be elected by the membership rather than elect itself. The short answer was NO, but instead of saying so one of the board members went into a lengthy discussion which included a story about some football coach from his college or university or whatever.

In summary it is quite clear that the Scrum Alliance is suffering from leadership deficit. “Improvement communities” are a great idea, but they can’t be an excuse for lack of leadership. After all self-organization occurs around goals, and it is not clear what Alliance’s goals are now. This apparent lack of vision is normal after what happened recently, but it can’t be allowed to last too long. Right now everyone is, I think, willing to cut Tome & others on the board some slack and give them time to find the direction but this won’t last long.

Personally I think the Scrum Alliance should open up, especially to members outside of the “old boys club” (as someone called it), to move ahead. Pushing Scrum outside of software development is IMHO unrealistic and in places wrong. The Alliance should rather focus on improving the quality of projects inside our industry. There is still a lot to be done in this sphere. The complexity and importance of the Product Owner role, for example, has been only discovered over time. The problem of awareness in the industry that is reflected in everyone still wanting fixed bid contracts is an ongoing problem. I think everyone could add to this list.

Making the CSM exam a real test of knowledge as soon as possible would be the first step in the right direction. I think exams should be like PMI’s PMP exams – there are no certified PMP trainers, anyone can train or learn PMBOK on their own, but the exam itself is known to be hard and is administered in a controlled environment to ensure one can’t cheat with a book or search engine. Such a structure promotes honesty and certificate value plus it is much more open and fair. I think this is a good example to follow. In the long term a good structure of exams like this could even make CSTs obsolete – which would help the promotion of Scrum greatly. Right now the existence of this closed club with unclear entry rules is choking the growth, especially in the parts of the world where English is not the primary language.

To wrap up my rant a short list of organizational failures:

• venue: rooms too small, at times crowded – people had to stand in some workshops,
  
• lack of proper events folder or plan – short plan in the conference ID is good, but without a brochure with descriptions of talks and speakers profiles one is left guessing as to what talks are about, it is way harder to make good decisions as to where to go, amazingly this information was even missing from the Scrum Alliance’s web site even though all speakers did submit it,

• lack of Open Spaces – that was a great idea, one of the greatest advantages of Scrum Gathering in Stockholm, don’t understand why it got dropped,
• lack of free Internet – at 1200€ one could expect that (was fixed on the second day).

To ballance it with some organizationa positives:

• all most talks in English,
• food – good and abundant!

Blog Łukasza: Back from PyCon PL'09

Last weekend we went to attend the PyCon PL’09 conference. This year it was located in Ustroń. The most positive change was comparing to last year was to accommodate everybody in one place, as it made it easier to integrate with the python folk, and talk/have a beer after/between the talks. There were a few interesting talks. I liked Wesley Chun’s “Python References and Memory Model”, although I knew most of the material. “Pair programming & TDD in practice” by
Konrad Deląg & Krzysztof Goj was also cool because it involved workshops (nevertheless nothing new to me there). Marcin Mierzejewski’s “Python and Orange – how to predict the future” about data mining using python was very interesting. I was actually surprised that there is no market for this stuff in Poland. The talks were OK, but not revolutionary. In my opinion the crowd (well perhaps excluding the two physicists there) and the talks were dominated by web development (Django). I would very much like to see more non web related talks.

This year’s pros and cons.

Pros:

• common accommodation
• good food
• international speakers
• better organization
• lots of lightning talks

Cons:

• problems with the power for computers
• really bad WiFi
• too little non web related talks

Since most of the cons can be worked on, I’m really looking forward to the next year’s edition.

Read more →
next page → Jobs
Key people ← previous page

---