Agile mindset vs Agile механизми

https://flic.kr/p/bkcj5q

Многократно установявам, че софтуерните екипи се фокусират твърде много върху механизмите и губят от поглед основния принцип. Това важи особено за методите Agile. Методи като Scrum имат толкова много механизми, че тези нови за пъргави напълно се изгубват. Първоначално написах това като имейл до моя екип, за да изясня какво е мнението ми за Agile, но сега го изпратих на толкова много хора, че като приемам съвета на Скот Ханзелман, го превръщам в публикация в блога.

Считам себе си донякъде квалифициран да дам тази представа. Аз съм пъргав практикуващ от дните, в които разработването на Agile включваше отвертка - за да демонтирате собствените си каюти и да създадете отворен план за сядане!

В началото на кариерата си работех с компания за медицински софтуер. Създадохме софтуер за настолен компютър за преглед на изображения, който беше инсталиран на работния плот на Доктор в болниците. Процесът на внедряване включва пътуване с компактдискове до друг град и инсталиране на настолни компютри и сървъри за изображения. Бяхме обект на одобрение от FDA, така че трябваше да надграждаме спецификации, които са били получени чрез FDA одобрение. Това създаде идеална среда за методология на водопада отгоре надолу. Всички спецификации бяха записани, одобрени, подписани и ние създадохме само тези спецификации и тези спецификации. Едва когато екипът на разработчиците започна да пътува с инсталационния екип и гледайки лекарите да използват нашия софтуер, ние разбрахме, че можем да направим много по-добре, само ако можем да говорим с клиента по-рано в цикъла. Кодирахме към точни спецификации и въпреки това доставихме нещо, което не беше толкова полезно, колкото можеше да бъде. Тази графика показва част от моя опит.

Как разработката на софтуер може да се заблуди от https://blogs.perficient.com/perficientdigital/2011/07/22/how-to-build-a-tire-swing-a-case-for-agile-development/

Около това време екипът ми чу за нещо, наречено манифест на Agile и практика, наречена Extreme Programming. Като се има предвид, че тя е подписана от ветерани от индустрията, чиито книги активно четем, хора като Мартин Фаулър и Кент Бек, отдадоха на практика много легитимност. Моят екип от пет разглоби кабинките си, вмъкна нашия PM (прокси за наш клиент), за да дойде да седне до нас, да настрои дъска с индексни карти и да отиде на работа, съставяйки XP, докато продължихме заедно. Имахме седмичен цикъл на планиране и демонстрации, много сдвояване и дискусии. Работих в различни итерации и вариации на това, в различни компании около 15 години. Един екип сякаш не следваше никаква методология, но това беше така, защото всички членове на екипа бяха от дълбок пъргав фон, итерацията и сътрудничеството бяха тяхното стандартно състояние на работа и нямаха нужда от наложен процес.

Така че Agile за отворени планове на етажа или говори много? Ако имате стендъп-ретро и ретро, ​​може ли да претендирате за Agile? Къде се вписват Scrum или TDD? Често хората се заблуждават твърде много в спецификата на процеса - Scrum или Kanban? Две седмици или една седмица спринт? Ако нямате закъснение, наистина ли сте пъргав? Пораснах да се занимавам с активно развитие с помощта на Agile методи, с други разработчици, които участват еднакво, разработват и адаптират практики, ми даде добра представа и този пост е да идентифицирам основните принципи.

Agile е в състояние бързо да задоволи нуждите на клиентите. Това означава ли, че пишем код по-бързо? Не. Ние не можем да победим законите на физиката, а за едно стабилно многофункционално приложение е необходимо време.

Това, което трябва да направим, е

  1. Идентифицирайте основните проблеми, които искаме да решим с код
  2. Дайте бързо теоретично решение, за да тествате хипотезата
  3. Итератирайте и се адаптирайте, докато нуждите се променят или научаваме повече
  4. Направете го в сътрудничество, с клиента ангажирана част от екипа

Всичко останало, което правим, е да направим 2 и 3 по-горе по-малко болезнени - да знаем дали отговаряме на необходимостта възможно най-бързо и ако не можем да се променим бързо. Ако сте решили да изградите (срещу покупка), пишете потребителски софтуер. Това означава, че има специализирани изисквания и среда.

Получаването на нещо видимо, дори и да е малък подмножество на функционалността, пред клиента възможно най-бързо ни позволява да получаваме обратна връзка по-бързо. Ето защо винаги се застъпвам да се съсредоточа върху изграждането на малък парче от функцията, от край до край, и да стигна това до целия продуцент. Кажете, вие създавате страница за вашите агенти за поддръжка, за да видите всички данни за клиент. Вместо да отделяте много време за проучване на източниците на данни за цялата страница и първо да пишете всички API-та, опитайте се да получите подмножество от данни на страницата чак до производството. Ще можете да упражнявате механизмите си за интеграция и разгръщане, можете да започнете да получавате обратна връзка за UI рамката, как тази страница се вписва с останалата част от приложението ви и т.н. Тези неща се настройват по-лесно, когато имате малко количество код, за разлика от него до когато сте изградили цяла рамка на API.

Ето някои от другите механизми, които са от съществено значение за пъргавината

Спринтове: Разработването във времеви цикъл ни позволява да инспектираме и адаптираме и да включваме нови данни на редовни интервали, за да гарантираме, че продължаваме да работим върху съответните функции. Софтуерът е отговорност. Ние трябва да изграждаме само това, което ни е необходимо, и да можем да добавим това, което е необходимо, когато е необходимо. Затова е важно редовно да разглеждаме какво сме изградили досега и накъде следваме. Това води до втората точка.

Като се има предвид, че ние планираме постоянно да оценяваме и променяме, нашият софтуер трябва да бъде лесен за промяна. Ами ако след като клиент започне да използва приложението, той иска някои данни да се покажат по различен начин от първоначално проектираните? Можем ли да направим това, без да докосваме всичко останало на страницата? Или трябва да се обадим на друг API, за да получим данни - можем ли да направим тази промяна безопасно? Тук влизат добрите практики и механизми за развитие

Тестване на единица: Имаме автоматизирани тестове на различни нива, така че има предпазна мрежа за промени. Също така е важно да се има предвид какво всъщност тестват единичните тестове. Единичните тестове трябва да тестват логиката. Ако вземете горния пример, използвайки различен API за получаване на данни, в идеалния случай не би трябвало да изисква промяна в единичните тестове за нашия API, който обслужва данни към потребителския интерфейс. Тестовете за единици съществуват, за да ви дадат увереността да префабрикувате кода, което от своя страна ви дава свободата да пишете само това, от което се нуждаете сега, и да почивате по-късно, за да не произвеждате някакъв показател за 100% покритие, така или иначе.

CI / CD: Това ни позволява да съкратим разстоянието между ангажиране и доставка. Това е от съществено значение за пъргавината. Когато се премахнат бариерите пред внедряването и можем да наложим малки промени в производството, рискът от промяна значително намалява. Ако разполаганията са досадни, те са по-редки. По-рядкото внедряване изтласква тона на промяна, докосвайки голяма площ и следователно са по-рискови. Ако научите повече за това, защо е важна ефективността на доставката на софтуер и какви показатели да използвате, за да го оптимизирате, горещо препоръчвам тази книга от Никол Форсгрен.

Разделяне на проблемите: Слабо свързаната архитектура е от съществено значение за софтуера, който е лесен за промяна. Намалява повърхността на промяна. Микросервизите и контейнерите са някои от механизмите, използвани за отделяне на проблемите. Важно е да запомните това и не забравяйте да имате предвид отделянето на проблеми, когато изграждате API, компоненти и приложения.

Помня
Добрият код може лесно да бъде променен

По-добрият код може лесно да бъде изтрит

Най-добрият код е този, който изобщо не е написан

От съществено значение е битовете, които създавате да се срещнат с реалния свят възможно най-бързо, така че да знаете как трябва да изглеждат новите ви битове и не губите време да правите ненужни битове.