W zależności od projektu, jeśli pracujesz sam nad małym projektem, może być sensowne przeprowadzenie badań technicznych i badań w ramach rozwoju. I chociaż nie jest częścią Agile, oczywiście można zastosować metodologię Agile, aby dodać do tego pewną kontrolę. Jednak powoduje to, że proces jest bardzo trudny do przewidzenia / lub przedziału czasu. Może być w porządku, nawet szybciej, jeśli pracujesz samotnie nad małym projektem, który jest całkowicie twój, pozwól, aby twoje wymagania się rozwijały, gdy się je uczysz. Po drodze stosuj dobre zasady, bądź konsekwentny i nie powinieneś zbyt wiele zmieniać faktorów.
W pracy używamy Kanban, Scrum i bardziej tradycyjnych podejść do wodospadu. W zależności od projektu uważam, że złożone rozwiązania z dobrze zdefiniowanymi wcześniejszymi wymaganiami nie najlepiej nadają się do zwinności, jednak wielu się nie zgodzi.
Zanim zaczniemy pracę nawet nad zwinnym projektem (wszystkie z wyjątkiem najprostszych), tworzymy dokumentację. Mamy makietę (jeśli dotyczy interfejsu użytkownika), zestaw wymagań i specyfikację funkcjonalną.
Programista zostanie poproszony o utworzenie specyfikacji technicznej ze specyfikacji funkcjonalnej, a podczas tego procesu określimy technologię i przeprowadzimy wszelkie wstępne badania, które będą nam potrzebne. Ten proces wydaje mi się tak ważny, ponieważ daje możliwość dostrzeżenia luk w wymaganiach / specyfikacjach funkcjonalnych - i daje duże decyzje technologiczne przed ludźmi z doświadczeniem i wiedzą systemową do podejmowania takich decyzji.
Istotną rzeczą jest to, że specyfikacja funkcjonalna może być listą wypunktowanych punktów, a specyfikacją techniczną będzie zwykle model, z pewnymi wypunktowanymi punktami i sterami technologicznymi, w niektórych przypadkach może to tylko 3 lub 4 strony.
Nawet podczas prowadzenia zwinnego projektu tworzymy dokumentację:
- Cała dokumentacja ma swój koszt.
- Opracowanie w oparciu o ruchome i źle zdefiniowane wymagania na wysokim poziomie wiąże się z pewnymi kosztami.
- Właściwa równowaga do powyższych zależy od twojego projektu, kultury i ludzi.
- Dokumentujemy W samą porę dokumenty stają się nieaktualne.
- Dokumentujemy ledwo / wystarczająco.
- Nie utrzymujemy ani nie aktualizujemy tych dokumentów, nie wkładamy w to wiele wysiłku. One są małe. Spodziewamy się ich wyrzucić.
- Eliminujemy wielkie niewiadome, takie jak decyzje technologiczne, mgliste wymagania i architektura z góry.
- Wiemy, co rozwijamy, zanim zaczniemy.
- Ufamy programistom podejmowanie świadomych decyzji dotyczących dokumentacji i omawianie wszelkich problemów.
- Cenimy komunikację zamiast dokumentacji, dlatego oczekujemy, że wszyscy zaangażowani będą się często komunikować.
- Systemy (przegląd) dokumentujemy po opracowaniu, a nie w trakcie, nie wcześniej.
Widzisz, w naszym zwinnym procesie jest mały wodospad.
Jeśli pracujesz sam, stwórz model z góry (schemat!), Baw się i wybierz technologię, a następnie, gdy masz koncepcję wysokich wymagań, biegnij dalej i rozwijaj zwinnie iteracyjny sposób, ale rozważ dobre zasady i spójność w miarę przemieszczania się i trzeba będzie ponownie rozkładać mniej, więcej zmieniać na bieżąco.
Ale ogólnie, jeśli wiąże się to z prawdziwymi kosztami (nie hobby), wiedz, co rozwijasz, zanim napiszesz kod, ale nie marnuj zbyt wiele czasu na pisanie dokumentacji, która szybko się zwolni, gdy zmienisz zdanie i powinieneś zmień zdanie podczas rozwoju, gdy będziesz lepiej poinformowany. Twój projekt może znacznie zmienić kurs, ale zacznij od dobrego, dobrze określonego fundamentu.