Tagged under: agile, architektura, proces, software craftsmanship
W jakim miejscu obecnie stoi architektura? Można powiedzieć, że mamy dwa klasyczne podejścia:
• klasyczne, które każe starannie zaplanować możliwie wiele szczegółów (up-front);
• zwinne, które każe podejmować decyzje najpóźniej, jak to możliwe i rozwijać architekturę poprzez refaktoring.
Jak to najczęściej się odbywa w projektach? W dużej części przypadków tworzy się projekt mniej lub bardziej szczegółowy (w stylu up-front) i tak już zostaje.
Z drugiej strony liczenie na to, że uda się rozwinąć dobrą architekturę tylko i wyłącznie organicznie, poprzez naturalną ewolucję, też zazwyczaj się nie udaje. W dużych projektach jest to wręcz niezwykle ryzykowne, gdyż prowadzi często do rozwiązań lokalnych, które w pewnym momencie należałoby całkowicie przepisać (co najczęściej się nie dzieje).
W praktyce zdecydowanie najlepiej sprawdza się mieszane podejście tzn. na początku projektu, releasu, iteracji, tworzy się koncept i projekt rozwiązania, który stanowi bazę i punkt odniesienia do prac projektowych. Nie musi, a nawet nie powinien być to niezwykle szczegółowy projekt. Z drugiej strony nie należy zakładać że to, co zostało wymyślone na początku, będzie doskonałym rozwiązaniem, dlatego w ramach prac projektowych, dokonujemy bieżącej lokalnej modyfikacji założeń projektowych poprzez refaktoryzację.
Dzięki temu uzyskujemy naturalny proces rozwoju architekury, z jednej strony jest ona wstępnie zaprojektowana, dzięki czemu nie stracimy czasu i zasobów na ewolucyjne błądzenie. Ewolucję wykorzystujemy, to poprawienia pierwotnego projektu. Jeśli powiążemy to z procesem Naturalnego Porządku refaktoryzacji to jesteśmy w domu! Więcej w kolejnych wpisach.
Szkic procesu wygląda następująco:
Tagged under: agile, efektywność, myślenie systemowe, proces, zarządzanie projektami
Dzisiaj rano jadąc samochodem do pracy natknąłem się na dużo dłuższy korek niż zwykle. "No tak, przy takim mrozie pewnie wszyscy jadą szczególnie ostrożnie" - pomyślałem i powoli się turlałem Trasą Łazienkowską. Po kilkunastu minutach, w pewnym momencie zauważyłem z daleka, że na jezdni w przeciwnym kierunku był wypadek i policja oraz pogotowie robiły, co swoje. Na moim pasie nic się szczególnego nie działo. Niby nic, a jednak... Kierowcy najzwyczajniej w świecie zwalniali, żeby zobaczyć co się dzieje na drugim pasie. Nikt się nie zatrzymywał, tylko patrzyli, co się dzieje. I z tego powodu fragment, który zazwyczaj przemierzałem w 5 minut, zajął mi tym razem 20 minut. Po przejechaniu tego punktu ruch znacząco przyspieszył i przebiegał normalnie.
Dlaczego o tym piszę? Od razu dostrzegłem analogię do projektów programistycznych :) Przedsięwzięcia programistyczne - ludzie, architektura, procesy - to złożony system. Często niewielkie zmiany, pozornie nieistotne elementy mają ogromny, kaskadowy wpływ na to co się dzieje w projektach.
Być może o jeden punkt decyzyjny za dużo, za mało, brak lub nadmiar dokumentacji, brak asertywności lub przyzwolenia o mówieniu o błędach, brak ścisłej współpracy lub zbyt swobodna współpraca bez ustalonych reguł mogą znacząco zmniejszać efektywność całego procesu. Warto o tym pamiętać!
W przypadku ruchu drogowego sytuacja jest nieco prostsza, bo łatwiej ją zmierzyć - jest to prędkość i czas przejazdu na tej samej trasie. Nie mamy tego luksusu w projektach, gdzie zazwyczaj to, co jest realizowane nie jest tak powtarzalne. Jednak możemy przybliżać się do oszacowania i porównywania. Szacując zadania oraz dodając relatywną miarę złożoności zadań (funkcjonalności).
Mniej formalną metodą są punkty (points, story points), które są jednostką względną, służącą raczej do porównania złożoności różnych funkcjonalności, niż do dokładnej analizy złożoności (która jest niezwykle pracochłonna, a i tak pozostanie tylko prognozą). Bardziej formalną metodą (gdzie dużo precyzyjniej należy argumentować podane szacowania) mogą być kilkuczynnikowe metody szacowania i pomiar zadań za pomocą punktów funkcyjnych.
Wtedy możemy obserwować czy nasza prędkość się zmienia, jak wprowadzane zmiany mają na nią wpływ.
