Dotychczas wszystkie poprawki rejestrowałem albo w pamięci, albo miałem je w e-mailu, jeżeli projekt robiony był na zamówienie. Znacznie rzadziej wykorzystywałem papierowe karteczki, gdyż mają one dziwną tendencję do znikania, gdy są najbardziej potrzebne. Już jakiś czas temu zauważyłem, że gdy liczba rzeczy do wykonania wzrośnie powyżej pewnej granicy, zaczynają się częstsze pomyłki w stylu przegapienia czegoś lub omyłkowego zakwalifikowania w głowie danego podpunktu jako wykonanego, już nie wspominając o braku możliwości zapisania uwag, komentarzy oraz nowych odkryć, tudzież odpowiedniego oznakowania miejsc w kodzie źródłowym. W bugtrackerze wszystkie sprawy znajdują się pod ręką, dodatkowo opatrzone informacjami o postępach oraz powiązaniach między zadaniami. Każde zgłoszenie ma swój unikalny numer, do którego można odwołać się w kodzie źródłowym, a ponadto gdyby do projektu z nieznanych przyczyn dołączyły inne osoby, miałyby wszystko na tacy. Bugtracker, oprócz błędów, nadaje się również do notowania pomysłów oraz nowych opcji do zaimplementowania. Obecnie chyba nie ma skryptu, który nie udostępniałby opcji definiowania i wyboru typu zgłoszenia (Błąd, pomysł, funkcjonalność itd.). Co więcej, wszędzie można umieścić informację o wersjach, a z tego już bardzo łatwo wyprodukować mapę drogową, change-loga czy inny rejestr.
Aktualnie jestem w trakcie wprowadzania do lokalnego Flyspray'a wszystkich informacji o rozwoju nowego silnika. W ustawieniach projektu wydzieliłem sobie szereg kategorii (system obsługuje ich zagnieżdżanie) takich, jak poszczególne elementy jądra, przez podstawowe DAO i kontrolery, aż do dodatkowych narzędzi. Muszę jeszcze poćwiczyć nadawanie poszczególnym zgłoszeniom odpowiedniego statusu i priorytetu, gdyż na razie jest tu pewien element losowości i czytając później spis mam wrażenie, że układał go jakiś idiota :). Stosowne wyczucie przyjdzie z czasem... wyczucie? Czy może po prostu świadome pobranie odpowiednich danych z podświadomości, które już tam są? Nieważne zresztą, nie pora tutaj na zgłębianie tajników ludzkiego umysłu. W załącznikach zamieściłem kilka screenów z Flyspraya.
Na instalację czeka również prywatne wiki, na którym będę umieszczać opisy dotyczące API oraz korzystania z tego, co napisałem, a także szczegółowo dopracowywać nowe pomysły. Aktualnie w tym celu używam zwykłego pakietu biurowego, lecz tam dość ciężko formatuje się kod i w związku z tym rozwiązanie to ma swoje ograniczenia. Pozostaje problem wyboru systemu. Nie ukrywam, że składnia MediaWiki odpowiada mi najbardziej, lecz tam domyślnie nie ma żadnych narzędzi do kolorowania składni. Odpowiednim pakietem dysponuje DokuWiki, lecz tam z kolei niemożliwe jest umieszczanie spacji w nazwach podstron, co mnie osobiście okropnie w tego typu systemach wkurza. Jaki będzie więc ostateczny wybór - nie wiem jeszcze. Jednak na podsumowanie przemyślenie swoich sposobów organizowania pracy polecam wszystkim programistom. Nie musi to być od razu bugtracker - usprawnienia można poczynić w wielu innych miejscach, tylko trzeba najpierw takowe znaleźć i zastanowić się, co tam nawala. Przełoży się to na większe rozeznanie w projekcie i mniej sytuacji kryzysowych.
Napisał Marcin Kłeczek w sobotę, 10 listopada 2007 o 16:23
Nie jesteś jedynym, który w jednoosobowych projekcie uzywa bugtrackera :-) Ja co prawda preferuję mantisa (połączonego z svn'em i dokuwiki), ale efekt jest ten sam. Od pewnego czasu noszę się z zamiarem przeniesienia go na hosting zewnętrzny (jest już kilka zainteresowanych osób, które chcą dostępu). Muszę tylko napisać skrypt do synchronizacji zdalny-lokalny (jest zapisane jako zadanie... 3 miesiące temu :D ) Jedyny minus bugtrackera używanego samemu, to bałagan, który często w nim powstaje (samemu zawsze będziesz się w nim dobrze orientował).