Blogs
Andy's Blog: Sprint retrospective vs. Sprint review
Someone has asked if management or project management should come to the sprint retrospective 1. Think the way this question was asked indicated that there was some confusion regarding sprint retrospectives versus sprint reviews which, I think, is worth clearing.
Sprint retrospective and Sprint review are two different things that shouldn’t be confused.
Sprint review is for everyone involved, especially stakeholders, to inspect where the project is and discuss how to adapt as needed. Sprint review revolves around what was built – the “shippable product increment” produced in the last sprint – and the overall product, not how it was produced.
It is good if Product Owner “represents” stakeholders, but it is even better if they come and see themselves what was accomplished, what runs etc. My advice is to welcome management of all kinds if they want to come to a sprint review, just being sure they know what the purpose of the meeting and their role in it is. Ensuring that and educating them is primarily Product Owner’s job, but of course the Scrum Master may assist him.
Sprint retrospective is primarily for the team to inspect their last sprint, concentrating less on what was done than on how it was done, and then adapt their way of work. I wouldn’t include anyone outside the team in those, besides maybe the Product Owner if he/she wants to join.
A common objection to bringing management of any kind into retrospective is that team may not be comfortable talking about their dirty laundry in front of them. It is indeed very valid – but it is also worth noting that from managements’ prospective this would be a waste of their time to, for example, listen to developers debating how to improve branching in their code repository. Even if the management knew what the heck the team is talking about this is not something they should waste their time on. Managers have lots of things to do (collectively called “bigger picture”) which no one will do for them – this is where their time will be better spent.
Having said that an overall retrospective on the project or on a longer chunk of it (like a quarter or half a year) that would include management may make sense, but it would not necessarily include all team members (if you have many teams that would make it even impossible to do). Such a retrospective would concentrate on “big picture” and could be very beneficial – if there is of course a right atmosphere within company for people to be honest enough in such a retrospective for results to be useful.
Speaking of retrospectives – definitely worth buying is “Agile Retrospectives” Esther Derby and Diana Larsen. There is not much to read there – just a couple of introductory chapters – but it is a great cookbook of various techniques to use in different phases of a retrospective based on how much time you have and what is the retrospective about. Each technique has a description of how much time to set aside for it, how to facilitate it and where its place is the overall sequence of a retrospective.
Great help, since classic “what we did well? what we didn’t do well?” etc. becomes boring pretty quickly. Anyone who facilitates retrospectives on a regular basis should have this book.
Andy's Blog: Oath of Non-Allegiance
Jesse Fewell – a long time proponent of building bridges between the world of traditional project management and agile – has brought to my attention the newest initiative by Alistair Cockburn – “The Oath of Non-Allegiance”:
I promise not to exclude from consideration any idea based on its source, but to consider ideas across schools and heritages in order to find the ones that best suit the current situation.
This should be obvious in the context of looking for ways to better run projects, but clearly it is not. The world of agile is full of divisions, bickering and discussions that remind me of good old days of comp.os.advocacy. As Jesse points out, even the thought leaders of the agile community practice very little collaboration that is the cornerstone of this whole approach. Why?
I think there are two reasons for this.
First, for some agile – or, worse, just one flavor of it – has become something akin to a secular religion that gives their lives sense and meaning – the one and only true way to not only run software projects, but also “transform the world of work” and people’s lives worldwide. It doesn’t matter if this attitude is true or faked – believers will fight with each other over slightest details always defending their chosen flavor of agile. They will also savagely attack anyone who dares to suggest agile is just a tool.
Second, once money is added to the mix things are bound to get hot. People have built their livelihoods around teaching and promoting certain “labels” and, naturally, they will fight to protect what they consider to be their turf. This is exactly same reaction as the one we are getting from “traditional project managers” when promoting agile – they feel their jobs are at risk from methods with no room for someone that will tell workers what to do.
Both attitudes are normal and very human indeed, however they should not shape the world of agile. I think most of us – people involved in agile – want to get things done. I’m enthusiastic about Scrum not because I think it will put the whole world as we know it on its head – but because I know from first hand experience that Scrum simply works on software projects. I’m pretty sure there are projects where it would fail – and I would use other, more appropriate methods there.
I’m sure there are more pragmatists like me and it is a good thing that their voice is heard. I signed the Oath.
Blog Łukasza: My late impressions on EuRuKo 2010
I should have written this a long time ago, however maybe it’s for the best, since this way I can write about the talks I remember the most.
This year’s EuRuKo conference came to an end. First of all I’d like say a big
“Thank you” to the organizers. Apart from the weird registration process they
did their job well. The conference room where the talks took place was a bit small (for the number of people attending) however nobody complained since it was a backup venue for the one that has been flooded.
I really enjoyed this year’s talks. I think they were even better that those during the last year’s EuRuKo in Barcelona.
Day #1
Matz had problems flying in to Cracow, so his talk was swapped with “Profiling Ruby 1.9″ by Piotr Szotkowski. Piotr presented some really interesting workflow of optimizing ruby code. One lesson that I
learned: don’t necessary trust the standard library. Sometimes you can end up with a significantly faster piece of code for your given use case than a standard library method. The ideas and examples of the talk were clear so it was a pleasure to listen to.
The second talk I also liked was Rocky Bernstein’s “Rbdbgr, a debugger for Ruby 1.9″. I think Rocky’s project is really promising. I got a chance to talk with Rocky after his talk and he confirmed that in the long term a version for JRuby is possible so I’m keeping my fingers crossed.
José Valim did a very good job on his talk “DSL or NoDSL? – The power is in the middle”. The examples were very good, interesting questions from the crowd, and no answer for the topic question :-).
I have to mention Florian Hanke’s “Building a search engine with Ruby” – he had the funniest slides (I especially liked the one with Matz in a car on ruby wheels) :-).
Day #2
The second day of the conference brought some nice talks as well. I liked Sven Fuchs’ “Anatomy of Ruby i18n” (also everybody got to know how to pronounce his name via one of the slides :-)).
The best public speaker was Scott Chacon with “Gittin down to the plumbing”. You may not like git or the overall topic, but I think Scott was really well prepared. He spoke dynamically and had excellent examples.
Marcin Kulik presented a nice topic of “Building web frameworks with Rack” however it was difficult to hear him at the back of the room. Good thing the recordings have been published so it’s easy to watch it again.
Neil Straford from Tropo.com presented some amazing stuff regarding voice enabling your application. Definitely something to play with, especially there’s a free sandbox for developers set up.
The lighting talks were nice as usual. I really enjoyed Fernando Gullien’s lighting talk about his zombie game (masterpiece !).
To sum up the conference was a blast. I’m really looking forward to the next year’s event in Berlin !
Resources:
Andy's Blog: Selecting candidates for the Scrum Alliance board
As some of you may know I have been on a committee led by Harvey Wheaton, that was tasked with selecting the candidates for the two vacant seats on the Scrum Alliance’s board. I was pretty surprised with the proposal to be a part of this group given some of my views, mostly about CST process etc., that I express also here, but I took this as an opportunity to help the Scrum Alliance.
It turned out to be an interesting experience. Since SA’s bylaws didn’t prescribe a process we should follow, so we had to self-organize and devise a process that would be – in our opinion – fair. It worked out better than – I think – anyone of us expected. We managed to come up with a pretty good selection pretty quickly with just e-mails and two confcalls.
The process was pretty simple – on the first call we decided we want to learn more about potential candidates who expressed interest, especially what they want to bring to Scrum Alliance, so we have created a simple questionnaire for them to respond to. Some obviously didn’t saving us work, but 17 people did submit responses varying in length. As it turned out on the last call all of us took time and read through those responses, some even more than once. Thus prepared we were able to reach a consensus during the second call and present a very balanced list of candidates.
Personally, when reading the submissions, I was looking for concrete vision and addressing SA’s real problems (damaging and unnecessary rift with Ken and Jeff, certification process in dire need of an overhaul – incl. the CST process, lack of vision and openness in what the board does, Scrum being pushed aside by the “Kanban camp’s” marketing efforts etc.) rather than general statements on promoting Scrum etc. I think a board member is responsible for steering the organization in a (hopefully) right direction, not for defining what is Scrum for example (“Scrum Guide” by Ken and Jeff does this well enough).
Overall, I’m pretty satisfied with the candidates that we selected – the list will be published on the SA site pretty soon.
Now it is up to members to vote and choose, keeping in mind that those two board members will have limited influence and can be outvoted by the incumbents anyway. However, at least they can probably influence the Scrum Alliance in the right way or tell the rest of the members how the board works or what it decides and why.
It is about time to reinvigorate the Alliance and save it from fading into irrelevance – which is what can happen if those pressing points I mentioned above are not addressed – so vote carefully.
Wiktor's Blog (in Polish): Prezentacja z Krakowskiego – SPINu
Zgodnie z obietnicą zamieszczam prezentację z ostatniego SPINu. Dziękuję wszystkim za przybycie.
Link do prezentacji znajduje się tutaj: TDD i Continous Integration.
Ze względu na trudności techniczne podczas praktycznej części prezentacji film który był nagrywany zostanie uzupełniony o DZIAŁAJĄCE przykłady 
(oczywiście link do niego też znajdzie się na blogu). Za wszelkie niedociągnięcia techniczne przepraszam, tak to jest gdy w ostatniej chwili wpada się na “genialne” pomysły przeróbek i udoskonaleń prezentacji…
Wyciągnąłem wnioski na przyszłość…
Wiktor's Blog (in Polish): SPIN – Kraków – 27.05.2010
Serdecznie zapraszam na najbliższe spotkanie krakowskiej grupy SPIN, które odbędzie się 27.05.2010 o godzinie 18.00 tradycyjnie już w siedzibie Comarchu. Na spotkaniu tym postaram się przybliżyć ideę Continous Integration oraz TDD a przede wszystkim pokażę jak za darmo stworzyć kompletne środowisko do automatycznych testów GUI (zgonie z zasadami CI).
Po spotkaniu zamieszczę tutaj prezentację pewnie z jakimś szczegółowym opisem, a także nagranie (jeśli wszystko pójdzie zgodnie z planem).
Jeszcze raz serdecznie zapraszam!
Wiktor's Blog (in Polish): Scrum jest narzędziem.
Scrum to nie filozofia, to nie religia, nawet nie metodologia – to tylko proste narzędzie. Zauważyłem, że wielu ludzi próbuje uczynić ze Scruma jakąś metodologię do wszystkiego. Moim zdaniem Scrum powstał dlatego, że niektórzy mieli już dosyć sformalizowanych metodologii. Miał z założenia być prostym narzędziem oferującym kilka artefaktów, a wszystko inne miało zależeć od wizji i potrzeb użytkowników. Wspomniane artefakty to Backlog, Iteracje, Daily Scrum, Burndown Chart, Scrum Master oraz Product Owner (chyba o niczym istotnym nie zapomniałem). Wszystko inne powstało na potrzeby konkretnych projektów/użytkowników. Scrum miał być narzędziem dla każdego, narzędziem które miało być kompatybilne z różnymi metodologiami i narzędziami.
Dlaczego Scrum staje się rozbudowaną, coraz mniej zrozumiałą metodologią? Wielu użytkowników Scruma z powodzeniem zastosowała go wraz z innymi rozwiązaniami z pod znaku Agile i nie tylko, po czym próbowali swoje sukcesy i spostrzeżenia jak najbardziej uogólnić i przekazać innym. Niemniej jednak to co z tego powstało nie nazwał bym już Scrumem samym w sobie, Scrumem – narzędziem, tylko raczej Scrumem metodologią opartą o Scrum jako narzędzie, a wzbogaconą o wiele artefaktów i rozwiązań z innych metodologii i narzędzi. Należy zatem rozróżniać Scrum od wszystkiego co Scrumopochodne co możemy znaleźć w wielu często interesujących publikacjach i na wielu szkoleniach/konferencjach.
Owszem, takie rozwiązania są często bardzo wartościowe, niemniej jednak zanim wprowadzi się je w życie należy się zastanowić czy na prawdę tego potrzebujemy. Czasem warto stosować sprawdzone wcześniej przez innych rozwiązania, lecz czasem warto też wrócić do korzeni, do podstaw i na nich zbudować własny framework scrumowy idealnie dopasowany do projektu, zespołu oraz warunków.
Scrum Master to praca na pełny etat właśnie dlatego, że jednym z zadani mistrza młyna jest rozwijanie metodologii i eksperymentowanie z nowymi narzędziami by jak najbardziej zwiększyć wydajności i jakość pracy. Ale o tej konkretnie roli Scrum Mastera może innym razem.
Andy's Blog: Why iPad is evil
Everyone knows the iPad – Apple’s newest toy, a crossover between an iPhone and a computer. It is nice, sleek, innovative and will sell like hot cakes (in fact, it already does). But there is one paradigm change it pushes that I find troubling: Apple’s software distribution system.
Ever since “personal computers” (as they were called back then) made it to people in late 70-ies owners could load whatever software they wanted onto their machines. They could code their own, buy a copy or upload a shared (”pirated”) software. Whatever they wanted. No one knew what they have on their machines and no one could change that.
Apple’s model is that you can only get software from the central App Store run by Apple. Period. You can’t download off the Internet. You can’t buy a box at a media market nearby. You can’t use Open Source stuff from someone’s site. And you can’t make your own – unless you have another full-blown Apple computer and sign up for a special account in the Apple Dev program. That means your machine is no more entirely yours, it’s just a terminal to a store with shiny toys you have to pay for. And Big Brother Steve controls what toys are there.
This also affects the software business by introducing a new risk for software vendors. Normally your sales don’t depend on the operating system or machine maker. They can intimidate you, buy you out, introduce nasty tricks in the OSs new release you will have to work around, introduce their own bundled, free product to compete with yours (IE) but they don’t control your distribution. Host OS vendor could make your life harder but not kill you overnight.
Numerous times I’ve read complaints about Microsoft being a bullying, ugly monopolist – in fact I wrote a couple myself – but even in the maddest fit of furry Steve Ballmer can’t pull the plug on your entire business just like that. Steve Jobs can and will, with a smile. One day you might be selling hundreds of downloads of your app on the App Store and the next day your revenue stream is gone and your business with it. If that doesn’t make Apple an evil monopolist I don’t know what else they have to do to earn the title.
To be fair Apple didn’t invent this model. It was first introduced on a large scale by Amazon with their Kindle device. It is in fact a terminal to a paid library of books you can’t ever really own – you just rent them at a price to read them (I think Amazon’s stating that you “buy” them is misleading advertising). It is the ultimate perversion of the great concept of public libraries on steroids. Apple just applied that first to iPhone with great results and now it tries to do the same with computing. I’m afraid it won’t end with the iPad…
The thing is I can whine on my blog, and so can others, but this won’t change anything. The carrot, the bait is too big for both consumers and vendors. Consumers get easiest possible way to get software, vendors get instant access to huge market. So everyone will, sadly, play along. It could have been done better – for example through a community-run “App Store” or something – but for the time being the only thing I can do is buy a Linux-powered netbook and thus revert to my roots.
Wiktor's Blog (in Polish): Banana Scrum 2.0
I oto nadeszła ta wiekopomna chwila – nasze (Code Sprinters) autorskie narzędzie do zarządzania projektami w metodyce Scrum – Banana Scrum deczekało się wersji 2.0!
Banana Scrum to narzędzie w pełni przystosowane do wymogów Scrum. Aplikacja ta jest idealnym narzędziem nie tylko dla doświadczonych zespołów scrumowych ale także dla tych początkujących. Przejrzystość oraz nazewnictwo zgodne nomenklaturą Scrum pozwalają bardzo szybko poprzez praktykę przyswoić podstawowe zasady Scrum. Oprócz podstawowych funkcjonalności jak Pruduct Backlog, Sprint Backlog, Sprint Planning posiada ono także kilka innych bardzo przydatnych ficzerów jak na przykład Timeline View – ekran, który pozwala w bardzo przystępny sposób zobrazować dotychczasowy przebieg prac nad projektem, a także rozplanować w czasie przyszłe zadania. Do tego wszystkiego za jeden z killer ficzerów można śmiało uznać synchronizacje działań użytkowników w czasie rzeczywistym – zmiany przez nich dokonywane są od razu widoczne na ekranach pozostałych użytkowników – jest to niezwykle przydatne podczas pracy w rozproszonych zespołach.
Jako współtwórca tego narzędzi i pasjonat zwinnych metodologii muszę nieskromnie stwierdzić, że wykonaliśmy kawał dobrej roboty
Co tu dużo pisać – zapraszam do przeglądania wersji demonstracyjnej: demo.bananascrum.com.
Andy's Blog: Nigel Baker’s talk on Scrum
Here is Nigel Baker’s talk on Scrum – “10 things that Scrum Masters should know, but probably don’t” delivered on the “Agile Tuning” micro-conference here in Cracow last Saturday.
Judging from blog posts by other participants Nigel’s talk was definitely a highlight of the conference – many wrote that other talks paled in comparison to his outstanding presentation. In fact I think it is a pity Nigel doesn’t do more public talking on the conference circuit and only participants to his trainings (which we have a pleasure to organize in Poland) had so far a chance to experience his zest for Scrum & Agile.
Enjoy!
(I plan to make a high-res version of this available using BitTorrent later on)
Andy's Blog: What’s wrong with Toyota fascination
Last Saturday I attended a mini-conference called Agile Tuning here in Cracow. Kanban was what was talked a lot about and there was the usual automotive reference: Toyota. There is a lot of fascination with Toyota in the agile community (and elsewhere) and it has always bothered me a bit, but I didn’t really understood why. Somehow this came to me during that event.
You see, there are two problems I have with this “Cult of Toyota”.
First, clearly some of stuff that is inspired by Toyota’s approach to making cars is about how they manufacture them. For example, the whole Kanban system has its roots at Toyota but it was used there to optimize the flow of material to the assembly line and thus the line’s effectiveness. However, software development is not, repeat, not about churning repeatable products from a production line composed of machines and people performing endlessly same tasks. Software development is an inventive process. Therefore we should rather look at similar fields, like product development – we should look at how Toyota designs their cars, not how they assemble them. This whole notion of looking at software as manufacturing is utterly nonsensical and ignores the reality of how software is created.
But, secondly, one thing that is clear to me is that whoever got fascinated with “Toyota way” clearly wasn’t a petrolhead. Toyotas may be reliable and Toyota surely is a great company in business terms, very well organized and managed but their products are anything but fascinating. Toyotas are generally boring small cars and family sedans, not very innovative, not very beautiful, just means of transport to get from point A to point B and not think about it too much. In a sense Toyotas are mediocrity perfected.
I personally would be way more interested in observing and trying to understand how companies that produce outstanding, breakthrough products – or at least products one can be passionate about – work. I would prefer to know how Tesla car came to be than how Toyota Corolla was design. But we don’t have to look at automotive industry for examples – within our own industry we have way lots of creativity and passion. Take Apple. It did produce more innovative, great products people do care about in the last 10 years than Toyota did through its entire corporate existence.
The only problem is that we will have to wait until Steve Jobs dies before management science would be finally able to analyze how Apple works on the inside. Before then his legendary paranoid secretiveness and unending myth-building would, I guess, prevent any serious study of this truly amazing company.
That doesn’t mean, however, that until then the best thing we can do is try to mimic Toyota’s assembly line.
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:
- Dbanie o przestrzeganie zasad ustalonych przez zespół.
- 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!