Chaos Report dwanaście lat później
Jakość 04/03/2007 · Link Jak donosi SD Times w artykule Standish Group Report: There’s Less Development Chaos Today poprawia się sytuacja na froncie projektów informatycznych. W porównaniu z wynikami z pamiętnego raportu z 1994 roku (o którym wspominałem tu) dzisiaj znacznie więcej projektów kończy się sukcesem a mniej porażką. Cytowane wyniki pochodzą z nieopublikowanego jeszcze raportu "Chaos Report 2006". 35% projektów zostało zakwalifikowanych do grupy zakończonych sukcesem - tzn w założonym zakresie, czasie i budżecie. Dla porównania w roku 1994 było to tylko około 16%. Podobnie zmniejszyła się grupa projektów uznanych za zakończonych porażką - dwanaście lat temu było to 31%, dziś jest to około 19%. Autorzy raportu dopatrują się trzech głównych przyczyn poprawy sytuacji:- lepsze zarządzanie projektami
- częściej stosowany iteracyjny rozwój oprogramowania
- wzrastająca rola internetu
Czy tworzysz fajne rzeczy?
Jakość 05/08/2006 · Link Jakość w projektach informatycznych kosztuje. Kod wytworzony za pierwszym razem zwykle bardziej przypomina prototyp niż rozwiązanie i wymaga refaktoringu. Dzieje się tak dlatego, że dopiero tworząc produkt zaczynamy dobrze rozumieć zależności między różnymi fragmentami kodu, łatwiej nam dostrzec podobieństwa, uogólnić i stworzyć eleganckie docelowe rozwiązanie. Czy w Twojej firmie (dziale, zespole, projekcie) jest na to czas? Czy tworzysz fajne rzeczy, czy też działasz według filozofii "good enough"? Nie twierdzę, że którekolwiek z dwóch ekstremów jest właściwe, zawsze wybierany jest w końcu jakiś kompromis. Z informatycznego punktu widzenia lepiej oczywiście jest tworzyć rzeczy dobre, choćby dlatego, że tańsze jest ich utrzymanie w przyszłości. Z perspektywy biznesowej zwykle lepsza jest strategia "good enough" - produkt może być szybciej na rynku, może wcześniej rozwiązywać problem klienta, a przy tym może być (przynajmniej inicjalnie) tańszy. Ale szukając optymalnego wyważenia warto zwrócić uwagę na mniej inżynieryjno-biznesowy, a bardziej ludzki aspekt. Ludzie chcą tworzyć coś dobrego. Jeżeli przyciągniesz do zespołu najlepszych, pokażesz im wyjątkowość wyzwania, określisz ambitne i fajne cele, zadbasz o jakość to będziesz miał zmotywowany, efektywny, zaangażowany zespół. I odwrotnie: oszędzanie na jakości, praca nad kiepskim produktem i współpraca ze słabymi ludźmi są początkiem staczania się po równi pochyłej. Utrzymanie motywacji i efektywności w takiej sytuacji jest niezmiernie trudne, przyciągnięcie dobrych osób na dłuższy czas - prawie niemożliwe. Co więcej łatwo o wzmocnienie zwrotne. Odejście dobrej osoby pociągnie za sobą inne: nikt nie chce pracować w słabym zespole, bo to tylko wróży kłopoty i żaden honor na dodatek. Jakość prawdobodobnie spadnie, pogłębiając demotywację zespołu. Nie jest łatwo zawrócić z takiej drogi. Jak się na jakość patrzy w Twoim zespole? Nie mam na myśli pustych deklaracji (czy jest tu ktoś, kto nie słyszał, że celem firmy jest dostarczanie produktów o najwyższej jakości?), ale rzeczywiste działania. Ile jest czasu na refaktoring? Jakie jest podejście managementu do wydłużenia terminów realizacji w zamian za poprawienie jakości? Jakie działania są podejmowane i jakim kosztem, by rzeczywiście produkty były dobrze zrobione? Czy Ty tworzysz fajne rzeczy? Podyskutujmy... (5)UI nie jest obszarem inwencji
Jakość 05/06/2006 · Link Odbyłem ostatnio interesującą rozmowę na temat kryteriów oceny interfejsu użytkownika w programach komputerowych. Tematem, który mocno przykuł naszą uwagę, było to, czy istnieją standardy, normy, czy też powszechnie przyjęte konwencje dotyczące UI? Zacznijmy od tego, po co w ogóle szukać standardu? Czy nie lepiej wymyślić po prostu czegoś lepszego? Moim zdaniem nie. Wszelka innowacja w dziedzienie UI ma jedną zasadniczą wadę: każda pomysłowa nowość stanowi potencjalną przeszkodę dla przyszłego użytkownika. Użytkownicy są do pewnych rozwiązań przyzwyczajeni, widzieli je setki razy i spodziewają się pewnych zachowań, nawet jeśli są nieoptymalne. Wypromowanie nowego mechanizmu w UI (np. sposobu wyboru wartości z listy, reakcji na kliknięcie, miejsca umieszczenia komunikatu etc.) nie jest wcale łatwe i zwykle wymaga dużej siły przebicia (przykład: wciąż piszemy na klawiaturach qwerty, choć wiadomo, że inne układy pozwoliłyby na efektywniejsze pisanie). Oczywiście może się tak zdarzyć, że nasz innowacyjny pomysł to absolutny 'killer', na który ludzie czekali od lat, ale w 99% przypadków będzie to tylko utrudnienie, które zwiększy 'barierę wejścia'. Dlatego podchodząc pragmatycznie bezpiecznie jest używać takich konstrukcji do jakich ludzie są przyzwyczajeni i starać się unikać odejścia od konwencji. Ale jak sprawdzić bez przeprowadzania kosztownych badań, do czego użytkownicy są przyzwyczajeni? Co można przyjąć jako 'stanard'? Jak zachować się w obliczu konieczności wyboru konkretnego rozwiązania? Moja pragmatyczna (być może kontrowersyjna) rada brzmi: zostawmy ideologię na boku i zastosujmy dokładnie takie same konstrukcje jakie przyjęto w MS Windows/Office. Takie podejście ma kilka cech:- Raczej będzie optymalne - Microsoft poświęca ogromne środki na testowanie swoje UI i szansa, że wybrał niewygodne lub nieintuicyjne rozwiązanie jest niewielka.
- Jeśli nie będzie intuicyjne, to będzie standardowe - większość osób używających komputerów desktopowych ma na nich zainstalowane oprogramowanie MS Windows i jest do niego przyzwyczajona. Nawet jeśli uważamy, że coś można zrobić lepiej, to zrobienie wbrew MS wprowadza niespójność do całego środowiska z którym spotyka się użytkownik.
- Oszczędzi czas - nawet jeśli raz na dziesięć podjęta w ten sposób decyzja nie byłaby słuszna, to przynajmniej we wszystkich dziesięciu oszczędziliśmy czas.
Usability is about choosing functionalities
Jakość 02/05/2006 · Link Przeglądając artykuły na temat analizy wymagań natrafiłem na takie interesujące spostrzeżenie (Why user experience disaster happen at the start of web projects, Sim D'Hertefelt):"And oh yeah", these prospective clients tell me at the end of their project briefing, "the site has to be sticky and user friendly as well." I have to disappoint them. Usability is not something you add to the design after you're done with the strategic thinking about functionalities. Usability IS about choosing useful functionalities. If a website is not useful, making it easy to use or attractive is not going to make it more usable. Usable means useful AND easy to use AND appreciated by users.Wybór funkcjonalności oznacza również odrzucenie pewnych z nich. Widzieliście aplikacje webowe opracowane przez 37 signals? Kluczową zaletą tych aplikacji jest prostota użytkowania. Jak ją osiągnięto? Oto fragment z manifestu aplikacji Basecamp:
Basecamp is simple on purpose. We've kept the confusing, complex stuff out. Basecamp doesn't do everything, but what it does it does extremely well. That's focus and that's the baseline principle of our "Less Software" approach. Not more stuff, just the right stuff to help you get your job done.Pomyślcie o innych produktach, które odniosły masowy sukces. Firefox, Skype, Del.icio.us, Google, Flickr, ... Czym przerosły swoich poprzedników? Czy mają bogatsze od nich funkcjonalności? Według jakich kryterów dokonano ich wyboru? Zwróćcie przy tym uwagę jeszcze na jeden aspekt: programiści są inni :-). Zwykle mają większą tolerancję na mniej zgrabny UI niż inni ludzie. Dlatego podejmując decyzję o dodaniu lub usunięciu funkcjonalności konieczne jest przyjęcie odpowiedniej poprawki w stosunku do ich opinii. PS. Osobną kwestią jest przekonanie klienta (lub innego właściciela projektu) do rezygnacji z funkcjonalności. Zwłaszcza, jeżeli projekt jest wykonywany na zamówienie i klient zapłacił za wykonanie w poprzednich wersjach funkcjonalności, które w praktyce nie są używane. Jakąkolwiek przyjąć strategię, kluczowe jest pokazanie kosztu ich pozostawienia: poza oczywistym kosztem utrzymania (np. błędy regresywne, testowanie regresywne, dokumentacja), jest to również najczęściej bardziej skomplikowany interfejs użytkownika a w konsekwencji większa liczba pomyłek użytkowników, mniejsza wydajność, większy koszt szkoleń etc. Podyskutujmy... (1)
Full Life Cycle Object-Oriented Testing
Jakość 19/04/2006 · Link Zwykle testowanie kojarzone jest z procesem przeprowadzanym po zaprogramowaniu fragmentu oprogramowania. Takie podejście jest niedoskonałe: może być skuteczne do wychwycenia usterek skutkujących błędami wykonania programu, natomiast nie jest dobrym mechanizmem do wyłapania błędów koncepcyjnych - dotyczących zrozumienia wymagań, struktury systemu, interakcji z użytkownikiem itp. Jeśli nie przetestujemy oprogramowania pod tym względem podczas procesu wytwarzania, to z pewnością życie zweryfikuje końcowy produkt. W konsekwencji program może być formalnie poprawny, ale niezbyt użyteczny lub trudny do utrzymania - z pewnością wszyscy spotkaliśmy się z takimi przykładami. Warto zerknąć na ten schemat by zobaczyć, jak może wyglądać kompleksowe podejście do testowania w procesie wytwarzania oprogramowania. Wykonanie wszystkich zawartych tam testów nie jest w większości przypadków uzasadnione, ale warto sobie uświadomić, że przeprowadzenie wielu z nich nie kosztuje wiele, a może dramatycznie podnieść jakość ostatecznego produktu. Podyskutujmy...Dlaczego powstaje kiepskie oprogramowanie?
Jakość 28/03/2006 · Link Jakość oprogramowania jest postrzegana przez użytkownika zupełnie z innej strony niż przez programistę. Niezrozumienie tej różnicy jest jednym z istotnych powodów tworzenia kiepskiego oprogramowania. Dla programisty (zwłaszcza po studiach) najważniejszym wyznacznikiem jakości jest dobry kod. Taki, który nie tylko nie zawiera błędów, ale również jest elegancki, modularny, zgrabny, łatwy do modyfikacji, składający się z kawałków gotowych do ponownego użycia itd. Dla użytkownika te cechy nie mają (bezpośrednio) znaczenia - przynajmniej dopóki produkt jest względnie stabilny. Z jego punktu widzenia program ma robić to, czego użytkownik oczekuje. Spróbujmy przyjąć uproszczony model jakości postrzeganej przez użytkownika jako iloczyn:(dopasowanie do potrzeb) x (wygoda używania) x (jakość kodu) Załóżmy, że umiejętności w tych obszarach oceniamy od 1 do 10. Z moich obserwacji osób po studiach średnie liczby mogłyby być następujące:
- dopasowanie do potrzeb (analiza wymagań): 3
- wygoda użytkowania (projektowanie UI): 2
- jakość kodu (programowanie) : 7
