Jak przeprowadzić udany proces tworzenia oprogramowania

Tradycyjny rozwój produktu odbywa się na ogół w jeden „właściwy” sposób, co ułatwia przewidywalność i reprodukcję. Jednak proces tworzenia oprogramowania nie jest nauką ścisłą, w której istnieje tylko jeden właściwy sposób robienia rzeczy. Proces tworzenia oprogramowania przypomina sztukę, w której istnieje kilka różnych podejść do tworzenia produktu.

Nietechniczni liderzy w kosmosie nie mają dobrej reputacji wśród twórców oprogramowania. Ale widzisz, klucz do uruchomienia udanych wydań oprogramowania jest całkowicie nietechniczny. Chodzi o proces. Nie jest to konieczne, ale niektóre części procesu programowania korzystają z wiedzy technicznej. Udane wypuszczenie oprogramowania do produkcji to nie tylko kwestia samego kodu lub projektu, a bardziej solidnej architektury procesu. Dziś porozmawiamy o przejściu produktu od koncepcji do produkcji.

Instrukcja oparta na wartości

Zanim zaczniemy, upewnij się, że twoje oświadczenie oparte na wartości wygląda mniej więcej tak:

Twój produkt to: wyjaśnij, jaki jest twój produkt.

Pomaga to: kim są Twoi docelowi odbiorcy?

Rozwiąż: Jakie problemy napotyka twoja grupa docelowa, które rozwiązuje ten produkt?

Przez: Jak Twój produkt to rozwiązuje?

Z: Jaki jest twój sekretny sos?

Jeśli w zasadzie opracowujesz prosty dodatek do swojej firmy, niektóre z nich mogą być nadmierne. Ale gdy próbujesz czegoś nowego, może to pomóc utrzymać koncentrację.

Mapa drogowa

Aby uzyskać kod, zespół musi przygotować przejrzystą mapę drogową. Musi zawierać zestaw schematów, z których każdy spełnia odrębny cel. W przypadku poszczególnych zastosowań schematy te są różne. Schemat architektury aplikacji, makieta interfejsu użytkownika i model procesu biznesowego są powszechne. Wiedza techniczna pozwala lepiej ocenić architekturę zespołu i upewnić się, że są na właściwej ścieżce, korzystając z tych schematów. Te schematy będą kluczowe nawet pomimo umiejętności technicznych. Jeśli chodzi o ukończenie produktu, możesz skorzystać z ich pomocy, aby prowadzić produktywne rozmowy. W ten sposób nie będziesz musiał zgadywać na podstawie „procentu ukończenia” od zespołu programistów. Aby dowiedzieć się, jak blisko ukończenia produktu, możesz śledzić status każdego elementu na schemacie. Na podstawie tego, jak szybko zespół skompletował wcześniejsze komponenty, możesz prognozować przyszłą prędkość.

Uważaj na dokumentację

Dokumentacja procesów to metoda skryptowania zachowania zespołu w nowy sposób. Zwłaszcza jeśli jesteś zespołem rozproszonym, ważne jest, aby było miejsce, w którym Twój zespół może znaleźć to, czego potrzebują, bez konieczności czekania, aż inni członkowie w różnych strefach czasowych pojawią się w sieci i odpowiedzą na pytania. Ponadto, istnieje niepoprawna ilość dokumentacji przedrozwojowej, żadna, ale nie ma właściwej ilości. Dowiedz się, co stanowi wykonalną mapę drogową ze swoim zespołem, zanim zaczną pisać kod. W procesie projektowania pierwszym punktem kontrolnym będzie przejrzenie tej dokumentacji i upewnienie się, że dotrzymali tej umowy.

Nie musisz wymyślać koła od nowa

Musisz upewnić się, że Twój zespół koncentruje się na tym, co naprawdę musi zbudować. Zacznij od zdefiniowania kluczowych elementów odróżniających od produktów, które już istnieją. Większość wysiłku i czasu Twojego zespołu musi poświęcić na wsparcie tego zróżnicowania.

Schematy powinny się tu przydać. Czy Twoja aplikacja obejmuje proces rejestracji i logowania? Składnik logowania? Chodzi o to, aby Twój zespół wykorzystał to, co już istnieje, tam gdzie to możliwe. Następnie szybko umieść wszystkie rusztowania na miejscu, abyś mógł przetestować swój produkt. Następnie iteruj przez cały czas i nie martwiąc się o opóźnienie gotowości do produkcji, zmień wszystko, co pomoże jeszcze bardziej różnicować Twój produkt.

DevOps

Teraz następnym punktem kontrolnym jest sprawdzenie, jaką część planują zbudować od zera po przejrzeniu planowanej architektury. Następnie znajdź gotowe technologie, z którymi będziesz pracować, i zapoznaj się z nimi w grupie wsparcia produkcji.

Następnym punktem kontrolnym będzie gotowość do operacji. Ogromna część tajnego sosu, o którym wspomina DevOps, upewnia się, że zespół wsparcia produkcji jest na początku w pętli. DevOps to przekonanie, w którym zespoły operacyjne produkcji i programistów pracują razem nad wspólnymi celami. Zalety obejmują niezawodny kod, szybsze wydania i więcej czasu na programowanie dzięki automatyzacji. Wszystkie te korzyści są świetne, ale wynikają z silnego procesu komunikacji. Pamiętaj, że automatyzacja to wspólny wysiłek.

Wdrożenie i testowanie

Tutaj miękkie umiejętności wymagane od przywództwa całkowicie przyćmiewają wszelkie umiejętności techniczne. Współpracuj ze swoim zespołem wdrożeniowym, aby opracować proces podziału pracy między sobą. Zawsze znajdzie się grupa programistów, którzy chcą pracować nad wszystkimi interesującymi pracami i ignorować wszelkie drudge. Mogą argumentować, że są najmądrzejszymi ludźmi i dlatego powinni otrzymać swoje zadania. Niektórzy inni oparliby się zmianom i trzymali się tego samego rodzaju pracy, którą wykonali wcześniej. Należy dążyć do sprawiedliwego podziału pracy. Naciskaj na wszystkich, aby odpowiednio się rozwijali, współpracowali i dzielili się.

Iteracyjna dostawa

Zazwyczaj w zwinnym procesie programowania proces wdrażania dzieli się na kilka punktów kontrolnych, a nie na jeden termin. Nazywa się je iteracjami. Odwołaj się do zdefiniowanej mapy drogowej. I upewnij się, że to, co zacząłeś, jest co najmniej kompletne, zanim zaczniesz nowe komponenty. Zmniejsza to ryzyko i daje dokładny obraz szybkości rozwoju.

Przekaż kod do środowiska w celu przetestowania akceptacji po zakończeniu iteracji. Dotyczy to użytkowników testowych lub pilotażowych, którzy wchodzą w interakcję z produktem częściowym. Testują, aby upewnić się, że spełnia oczekiwania projektowe i przekazują informacje zwrotne na temat tego, jak może być lepiej. Ale testy akceptacyjne nie zastępują testów jednostkowych. Możesz rozpocząć proces zarządzania wersją, gdy zgromadzisz wystarczającą ilość przetestowanego kodu, aby uzyskać wystarczającą wersję produktu.

Przegląd kodu

Więc teraz twój zespół jest przekonany, że kod jest gotowy, a testerzy akceptacji są pewni, że produkt działa tak, jak powinien. Następnym punktem kontrolnym jest zweryfikowanie przekonania, że ​​Twój kod jest gotowy, aby stać się produktem. Możesz nie czuć się swobodnie przeglądając kod zespołu, jeśli nie masz technicznej wiedzy technicznej i to jest w porządku. Nie musisz. Twój proces powinien. Współpracuj ze swoim zespołem, aby opracować proces przeglądu kodu, który będzie dla nich odpowiedni. Ustanów program recenzji kodów równorzędnych, pracując ponad granicami zespołu. Używając schematów jako punktu odniesienia, poproś ich o wyjaśnienie, w jaki sposób kod osiąga cele określone na schemacie. Pod koniec procesu sprawdzania kodu recenzenci i programista muszą czuć się dobrze, ponosząc odpowiedzialność za kod.

Ten przegląd kodu to także idealny czas na sprawdzenie bezpieczeństwa i dokumentacji. Przegląd bezpieczeństwa musi znaleźć miejsce w każdym przeglądzie kodu. Zazwyczaj polega to na ponownym spojrzeniu na kod w celu zidentyfikowania słabych obszarów, w których haker może przejąć kontrolę nad serwerem lub wykorzystać go do ujawnienia prywatnych danych. Twórca może się tym zająć, nawet jeśli korzysta z automatycznego narzędzia do analizy kodu bezpieczeństwa.

Ostatni punkt kontrolny

Kod przeszedł proces sprawdzania. Jest gotowy, aby być produktem. Ale wciąż może nie być gotowy do produkcji. Musisz wyczyścić ostatni punkt kontrolny, gotowość do wdrożenia. Czy kod można łatwo wdrożyć do produkcji? Musi to obejmować jak najmniej ręcznych czynności. A jeśli kod nie działa, musisz mieć plan przywrócenia zmiany zgodnie z planem lub planu wycofania. Twój zespół operacyjny powinien przejrzeć dokumentację dotyczącą wdrażania i wycofania oraz poinformować Cię, czy to wystarczy. Możesz zrobić ten krok sam. Ale upewnij się, że instrukcje dotyczące wdrażania produktu są jasne i proste. Kroków ręcznych powinno być bardzo niewiele, ponieważ każdy krok ręczny stwarza szansę na błąd człowieka. Po przekroczeniu tego punktu kontrolnego prześlij ten kod do wersji produkcyjnej.

Po wydaniu

Ważne jest, aby powrócić do przeszłości i sprawdzić, jak przebiegał proces po zakończeniu, czy to sukces, czy porażka. Czy testy prawidłowo modelowały scenariusz produkcji? Czy Twój zespół prawidłowo oszacował wysiłek wymagany do wydania produktu? Sprawdź, jak dobrze radził sobie zespół, ponownie sprawdzając punkty kontrolne dotyczące wdrażania i testowania. Jak działa produkt w produkcji? Może odwiedź zespół operacyjny i zbierz ich opinie. Zbuduje to zaufanie między dwoma zespołami, prowadząc do większej przewagi DevOps na późniejszym etapie. Przede wszystkim upewnij się, że rozliczasz siebie i swój zespół. Twój zespół odpowiednio dostosuje swoją wydajność, gdy przyzwyczai się do odpowiedzialności za każdy krok w tym procesie.

Wniosek

Udana wersja oprogramowania wymaga dobrze zrozumiałego, dobrze udokumentowanego procesu przenoszenia oprogramowania przez szereg pomysłów do produktu. Nie potrzebujesz do tego obszernej wiedzy technicznej. Często wiedza techniczna może być kulą.

Upewnij się, że angażujesz się ze swoim zespołem, jednocześnie zaślepiając dziury i budując powtarzalny proces, który działa na was wszystkich. Nie musi być idealny dla wszystkich zaangażowanych, ale wszyscy muszą to zrozumieć. Upewnij się również, że popyt na produkt jest dopasowany do prędkości Twojego produktu przez punkty kontrolne. I jak w przypadku każdego procesu, iteruj. Podobnie jak w przypadku kodu, Twój pierwszy nieprzetestowany szkic może nie być idealny. Dostosuj proces za każdym razem, a otrzymasz w końcu przewidywalną, płynną ścieżkę wydania oprogramowania.

Pierwotnie opublikowany na blogu Product Insights od CognitiveClouds: Najlepsza firma deweloperska SaaS

Ta historia została opublikowana w The Startup, największej publikacji na temat przedsiębiorczości na średnim poziomie, a następnie ponad 295,232 osób.

Zapisz się, aby otrzymywać nasze najlepsze historie tutaj.