Archive for the ‘zarządzanie projektami’ Category

Czy Webdeweloper może ignorować IE — może!

28 września 2009

Wprowadzenie

Oglądałem ostatnio zdjęcia w serwisie Flickr.

Przyglądałem się funkcji komentowania zdjęć i zauważyłem zaokrąglone rogi przycisków Preview i Save Comment oraz okna z wyjaśnieniami How do I format my comment?

Jako człek ciekawy, sprawdziłem jakiej to metody użyli programiści Flickr.com, aby uzyskać efekt zaokrąglonych rogów…

Zaokrąglone rogi w serwisie Flickr.com

Jest wiele metod (bazujących na miksie tabel i obrazków) uzyskania efektu zaokrąglonych rogów — większość to, moim zdaniem, doskonałe przykłady przerostu formy nad treścią.

Programiści Flickr.com zrobili to, moim zdaniem, niezwykle elegancko. Użyli styli CSS -moz-border-radius, które działają we wszystkich nowoczesnych przeglądarkach (Firefox, Chrome, Safari, Opera) poza…, a jakże, Internet Explorer-em — każdym :(.

flickr.com

Zaokrąglone rogi w serwisie Flickr.com

Podsumowanie

Dzięki prostemu rozwiązaniu działającemu w oparciu o style CSS, można osiągnąć ten miły dla oka i mózgu efekt niewielkim nakładem pracy i — co o wiele ważniejsze — bez rozdmuchiwania kodu HTML i rozmiaru przesyłanej strony.

Flickr.com i Yahoo pokazały też, że można zignorować niedostatki przeglądarki Internet Explorer, dzięki czemu zyskują:

  1. Użytkownicy innych przeglądarek — bo strony ładują im się szybciej,
  2. Programiści — bo mają kod prostszy do napisania i utrzymania,
  3. Testerzy — bo przyciski są standardowe i standardowo działają (fokus, zatwierdzanie klawiszem Enter i Spacja).

Recenzje: Szacowanie oprogramowania: kulisy czarnej magii

31 Maj 2009

Książka Steve’a McConnell’a Szacowanie oprogramowania: Kulisy czarnej magii to pouczająca, choć dość nudna niestety, lektura, omawiająca dokładnie podstawowe techniki szacowania oprogramowania, ich możliwe zastosowania, wady i zalety poszczególnych metod estymacji oraz częste błędy popełniane podczas szacowania oprogramowania.

Już rozdział drugiSprawdzenie swoich umiejętności szacowania — jest niezwykle pouczający. Brutalnie obnaża jak kiepscy jesteśmy w szacowaniu oraz jak fatalnie źle rozumiemy proces szacowania i jego dokładność.

Książka składa się z trzech części:

  1. Podstawowe elementy szacowania
  2. Podstawowe techniki szacowania
  3. Szczególne wyzwania związane z szacowaniem

Szacowanie oprogramowania: Kulisy czarnej magii opisuje nie tylko naukowo–techniczne metody szacowania, ale także te praktyczne jak szacowanie przez analogię, czy metodę Wideband Delphi.

Książka zawiera też wiele przykładów zastosowania poszczególnych technik estymacji oraz ich skuteczności i chociażby z tego powodu warto ją przeczytać.

Niestety spora liczba tabel, liczb i wykresów powoduje, że książka nie nadaje się na lekturę do poduszki (chyba, że dla dziecka — jak Code Complete :)).

Dwa najważniejsze wnioski płynące z książki są takie:

  1. Nie szacuj tego, co można policzyć.
  2. Najdokładniejsze szacowanie można podać na podstawie danych historycznych.

Dla ciekawych — o książce wielokrotnie pisał Jeff Atwood na swoim blogu coding horror.

Recenzje. Zarządzanie Projektami Informatycznymi. Eseje

14 marca 2009

Zarządzanie projektami informatycznymi. Eseje. autorstwa Joe Marasco to jedna z ciekawszych książek na temat zarządzania projektami, jaką przeczytałem (listę otwierają Zdążyć przed terminem oraz Czynnik ludzki — skuteczne przedsięwzięcia i wydajne zespoły).

Ciekawy rozdział Moja droga do informatyki o historii informatyki w USA po drugiej wojnie światowej, modelowanie zjawisk występujących podczas trwania projektów informatycznych przy pomocy narzędzi znanych z fizyki (autor jest doktorem fizyki), ilustracje problemów przykładami z życia (np. dlaczego niewskazane jest aby zarząd projektował oprogramowanie w rozdziale Lekcja historii) oraz dialogi z Roscoe Leroy-em to największe zalety książki.

Szczególnie warta polecenia jest część trzecia — Z punktu widzenia menadżera projektów z rozdziałami:

  • Coś za coś — wprowadzający pojęcie piramidy projektu,
  • Estymacja,
  • Harmonogramy,
  • Rytm — rozdział szczególnie wart uwagi.

Książka przedstawia świeże spojrzenie na problemy zarządzania projektami informatycznymi. Jest napisana prostym językiem, a opisywane problemy są ilustrowane ciekawymi przykładami.

Polecam ją każdemu kogo interesuje zarządzanie projektami informatycznymi.

Bo zawsze są jakieś zaciachy…

10 marca 2009

Wiele miesięcy temu rozmawiałem na temat narzędzi do prowadzenia projektów informatycznych. Marek zwrócił uwagę, że ważne jest aby narzędzie pomagało dokumentować estymacje i realny czas spędzony na zadaniu, co pozwala na lepszą estymację kolejnych projektów.

Marek przeprowadził nawet eksperyment. Wziął specyfikację jednego z przednich projektów, poszedł z nią do doświadczonego programisty i poprosił o wycenę czasową. Programista rzekł 4 tygodnie, co było zgodne z pierwotnym szacowaniem i całkowicie niezgodne z realnym czasem trwania projektu — kilkanaście tygodni.

Na pytanie Marka, dlaczego uznał, że projekt zajmie 4 tygodnie, podczas gdy projekt trwał o wiele dłużej, programista odpowiedział, że w tamtym projekcie były jakieś zaciachy.

Puenta Marka była taka — zawsze są jakieś zaciachy i szacując trzeba o tym pamiętać.

Używając dokładnie tego samego zwrotu — bo były zaciachy — tłumaczyłem z kolegami opóźnienie jednego z ostatnich projektów w którym brałem udział. Liczne zaciachy rzeczywiście były, tylko szacując czas wykonania projektu, nie wzięliśmy ich pod uwagę…

Wniosek: zaciachy trzeba dokumentować i brać pod uwagę estymując kolejny projekt.

Obszernie o zbieraniu danych historycznych pisze Steve McConnell w książce Szacowanie oprogramowania: kulisy czarnej magii.

FogBugz, system zarządzania projektami informatycznymi firmy FogCreek, implementuje zbieranie danych historycznych.

Wasabi. Z czym to się je?

13 listopada 2007

Ponad rok temu Joel wywołał burzę artykułem ,,Language Wars”. Wspomniał w nim o prostym języku funkcyjnym, który stworzyli sobie w firmie — Wasabi. Pomysł Joela najdobitniej skomentował Jeff Atwood.

Sam nie jestem zwolennikiem wymyślania koła na nowo. Pracowałem w firmie gdzie wymyślanie kół i kółeczek było (i ciągle jest!) misją, celem i strategią firmy.

A tu okazało się, że Joel — żywa legenda i wzór dla wielu deweloperów — też ma swoje własne HDB.

Rozumiałem argumenty Joela, ale się z nimi nie zgadzałem i nie zgadzam (trauma) — dokładnie z tych samych powodów o których pisał Jeff.

Sam wolałbym się skupić na rozwoju oprogramowania opartego o standardowe i popularne narzędzia, a nie rozwoju własnej technologii, co zapewne jest ciekawsze, ale rachunków zapłacić raczej nie pozwoli :).

Nurtowało mnie też, co szczególnego ma Wasabi. Dziś można już przeczytać więcej o Wasabi na blogu FogBugz.

Copy and Paste, a jakość kodu. Część druga

30 Maj 2007

Destrukcyjna funkcjonalność Copy & Paste coraz bardziej mnie przeraża…

Od czasu ostatniego wpisu, uważnie obserwuję temat i już parę razy złapałem siebie i innych, na bezrefleksyjnym kopiowaniu kodu…

W moim wypadku, była to, co prawda, tylko jedna linia kodu formatująca bieżącą datę na potrzeby zapytania SQL, ale:

  • Kopiowaną linię kodu napisałem dawno temu, gdy dopiero poznawałem używany w produkcie język programowania i aby uzyskać bieżącą datę, użyłem funkcji zwracającej bieżącą datę i czas, a ze zwróconej wartości obcinałem czas (przez formatowanie wartości do postaci czystej daty).
  • Teraz wiem, że istnieje funkcja, która zwraca bieżącą datę, więc nie trzeba było niczego obcinać i formatować.
  • Właściwa implementacja nie powodowała błędów wywołanych przez ustawienia regionalne (różna kolejność dnia i miesiąca w dacie w zależności od ustawień regionalnych).

A inne zaobserwowane przypadki to:

  • Kopiowanie kodu wykonującego zapis danych z formularza do bazy (zmieniał się tylko typ zapisywanej wartości), który w nieoptymalny sposób, odwoływał się do bazy danych.
  • Kopiowanie kodu pokazującego okno z komunikatem — problem był tylko w tym, że na początku (stałym) komunikatu była literówka…
  • Skopiowanie kodu pokazującego na stronie WWW formularz oraz kodu zapisującego dane z tego formularza. Kopista ograniczył się do dodania nowych pól na formularzu, ale, pracując pod presją czasu, zapomniał o modyfikacji kodu zapisującego dane z formularza w bazie danych — czytaj uwzględnieniu przez zapis nowych pól.

Możliwości tworzenia i powielania błędów stworzone przez funkcję Copy & Paste są naprawdę porażające… Wiem. Zawsze można zrzucić winę na kopistę, ale łatwość użycia funkcji Copy & Paste do tworzenia nowego kodu jest zbyt kusząca, aby z niej nie korzystać dla większości z programistów i niestety, także, deweloperów.

Podrzuciłem ten temat na forum strony Marka Rafałowicza.

Copy and Paste, a jakość kodu. Część pierwsza

3 kwietnia 2007

Byłem jakiś czas temu świadkiem ciekawej rozmowy, po której naszła mnie następująca myśl — pozbawienie programisty funkcji Copy & Paste dramatycznie poprawiłoby jakość kodu przez niego tworzonego.

Dlaczego? Bo nie mogąc kodu skopiować w nowe miejsce musiałby pomyśleć jak z tego kodu zrobić użyteczną funkcję. A więc wydzielić logiczne bloki kodu (które być może także stałyby się funkcjami), odpowiednio taką funkcję sparametryzować, aby była jak najbardziej ,,reużywalna”, itd.

Także utrzymanie takiego kodu byłoby prostsze — nie trzeba byłoby wyszukiwać wszystkich wystąpień skopiowanego kodu i poprawiać błędów lub zmieniać funkcjonalność we wszystkich miejscach gdzie kod został wklejony.

A co Wy, drodzy czytelnicy o tym myślicie?

Most Pegasus, czyli o roli przypadku…

12 stycznia 2007

Jestem świeżo po lekturze książki ,,Most Pegasus” Stephena Ambrose, która opowiada o historii przygotowań i ataku na dwa, kluczowe dla powodzenia operacji lądowania aliantów w Normandii, mosty.

Wcześniej przeczytałem dwie, znakomite książki Corneliusa Ryana — ,,Najdłuższy dzień” (też o lądowaniu aliantów w Normandii, tylko szerzej) i ,,O jeden most za daleko” (o historii największej operacji powietrzno-desantowej II wojny światowej — Market-Garden — ataku na mosty w Holandii we wrześniu 1944).

Każda kolejna przeczytana książka tylko utwierdza mnie w przekonaniu, że o wszystkim i tak, ostatecznie, decyduje przypadek.

To trochę smutne. Jeżeli sukces wielkiego przedsięwzięcia, w uprawianej i doskonalonej przez wieki sztuce prowadzenia wojen, zależy w takim stopniu od przypadku, to co dopiero w istniejącej od kilkudziesięciu lat inżynierii oprogramowania, gdzie stawka nigdy nie jest tak wysoka…