Като комбинираме с XP спорна топка

Как ние комбинираме Scrum с XP

Фактът, че Scrum и XP (Extreme Programming) може да се комбинира ефективно, без съмнение. Повечето от дискусията в интернет подкрепа на това предположение, а аз не искам да си губи времето с допълнителна обосновка.

Въпреки това, едно нещо, което все още трябва да се спомене. Scrum разглежда въпроси на управление и организация, а XP се фокусира върху инженерната практика. Ето защо тези две технологии работят добре заедно, взаимно се допълват.

По този начин, аз се присъединявам към привържениците на мнение, че Scrum и XP може да се комбинира ефективно!

Отивам да ви разкажа за най-полезните практики на XP и за това как да ги използват в ежедневната си работа. Не всички отбори са били в състояние да използва практиките XP в пълен размер, но ние имахме голям брой експерименти с много аспекти на XP / Scrum комбинация. Някои XP практики са пряко свързани практика Scrum, например, «Целият екип», «Седнете заедно», «примери» и «Планиране игра». В тези случаи, ние просто ще се придържаме към Scrum.

Напоследък сме започнали да го практикуват в една от нашите екипи. Изненадващо е, че работи доста добре. Повечето от другите ни отбори все още не разполагате с много програми, по двойки, обаче, опитайте тази практика в една от нашите екипи в продължение на няколко спринтове, аз съм вдъхновен от идеята да се въведе програмирането по двойки и други отбори.

Това е до няколко заключения след използване на програмирането по двойки:

• Чифт програмиране прави за подобряване на качеството на код.

• Чифт програмиране прави по-силен акцент команди (например, когато съотборник казва: "Хей, това нещо определено е необходимо за този спринт")

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

• Чифт програмиране е изтощителна, така че не трябва да се справят с тях през целия ден.

• Честите промени на двойки дава добър резултат.

• Чифт програмиране наистина допринася за разпространението на знания в рамките на екипа, значително ускоряване на процеса.

• Някои хора не се чувстват удобно работно по двойки. Не е необходимо да се отърве от един добър програмист, просто защото той не харесва програмирането по двойки.

• Преглед на кода - добра алтернатива на програмирането по двойки.

• Не насилвайте програмирането по двойки хора. Насърчете ги да даде необходимите инструменти и да се стигне до това.

Test Driven развитие (TDD)

Най-накрая! Разработка чрез тестове по-важно за мен от Scrum и XP заедно. Можете да отнеме къщата ми, телевизор, едно куче, но просто се опитват да се забрани използването на TDD! Ако не ви харесва на TDD, а след това просто не ме близо, в противен случай аз все още я занесе на проекта тихо :)

TDD разбира се за 10 секунди:

Test Driven развитие означава, че първо трябва да се напише автоматизиран тест (който не преминава. - приблизително преводач). След това трябва да напишете достатъчно просто код, за да премина теста. След това трябва да Преструктуриране на, най-вече за да се подобри четливостта на кода и премахване на дублирането. Повторете, ако е необходимо.

Няколко факти за TDD:

• Test Driven развитие - не е лесно. В действителност се оказва, че демонстрира TDD програмист е практически безполезен - често единственият ефективен начин да зарази TDD му е, както следва. Програмистът трябва да бъдат задължени да се свърже с някой, който е добър TDD. Но веднага след като програмист е проникнала в TDD, ако вече не е заразен и сериозно отношение към развиващите се и друг начин да чуят дори поиска.

• TDD има дълбок положително влияние върху дизайна на системата.

• За да TDD беше да се възползват в нов проект, трябва да се направи много усилия. Особено много се изразходват за интеграционни тестове от "черната кутия". Но тези усилия се изплащат много бързо.

• Отделете достатъчно време, но да го направят, за да напишете тества беше лесно. Това означава, че е необходимо да се получат необходимите инструменти, за да се обучават персонал, осигуряване на подходяща подкрепа и създаването на базовия клас, и така нататък. Г.

Ние използваме следните инструменти за разработка чрез тестове:

• Junit / httpUnit / jWebUnit. Ние сме се насочили на TestNG и селен.

• HSQLDB като вградена база данни в паметта (по-памет) за целите на теста.

• Jetty като вградени уеб контейнер в памет (в памет) за целите на изпитването.

• Cobertura за определяне код градуса покритие.

• Пролет рамка за писане на различни видове тестови тела (в м. Хр. С помощта mokov (макет обект) и без, с външна база данни и базата данни в паметта (по-памет) и други подобни. Г.)

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

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

TDD и новия код

Ние използваме TDD за всички нови проекти, дори ако това означава, че фазата на разгръщането на работната среда на проекта ще изисква повече време (защото имате нужда от повече усилия, за да се създаде и поддържа тестови инструменти). Лесно е да се разбере, че ползите са повече оправдание да не прилага TDD.

TDD и съществуващ код

Вече казах, че ТДУ - това не е лесно, но това е наистина трудно. така че се опитва да използва TDD на кода, която не е била първоначално предназначена за прилагане на този подход! Защо? Тази тема може да се говори за дълго време, но мисля, че ще спре. Запазване на вашите мисли за следващата книга: «TDD: Бележки от предния»: о)

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

Когато изхода на всяка нова версия, ние изолиран екип от тестери, които извършват цялата гама от сложни регресия и представяне на тестове. тестване регресия се извършва основно на ръка, което значително забавя процеса на разработване и инженеринг освобождаване. След това нашата цел е да се автоматизира тези тестове. Въпреки това, няколко месеца главата pobivshis до стената, ние осъзнахме, че ние не се доближават до целта на йота.

Тогава ние променихме подхода. Ние признава факта, че автоматизирано регресия тестване, ние не можем да си позволим, и си задайте въпроса: "Как мога да се намали времето за изпитване". Това е система за игра, и ние открихме, че повечето от тестовете на времето за отбор похарчени за тривиални задачи, като например създаване на тест на турнира, или в очакване на началото на турнира. Ето защо ние създадохме инструмент за извършване на тези операции. Малки, достъпно чрез натискане горещите ключови скриптове, които вършат цялата подготвителна работа, позволявайки тестери да се фокусират директно върху теста.

Но тези усилия са възнаградени! Умът трябва да са направили това от самото начало. Но ние бяхме толкова фокусирани върху автоматизацията, че забравих за еволюционния подход, при който първата стъпка ще бъде да се създаде среда, която позволява да се направи ръчно тестване по-ефективни.

Поука: Ако от ръчно тестване регресия не може да откаже, но наистина искам да се автоматизира - трябва по-добре да не се (добре, с изключение, че е наистина много проста). Вместо това, да направи всичко, за да се улесни процеса на ръчно тестване. И след това можем да мислим за автоматизация.

Това означава, започнете с прост дизайн и непрекъснато подобряване него, вместо да се опитва да направи всичко перфектно първи път и повече от всичко и никога не докосна.

С това се справяме доста добре. Отделяме достатъчно време рефакториране и подобряване на съществуващата конструкция, и много рядко правя подробен проект за години напред. Понякога ние със сигурност може да се притеснявам, в резултат на лош дизайн, така че расте с това, че рефакториране се превръща в наистина голям проблем. Но, като цяло, ние сме напълно удовлетворени от този подход.

Ако лекарят TDD, а след това, като цяло, непрекъснато усъвършенстване дизайн се получава от само себе си.

Непрекъснато интеграция (Непрекъснато интеграция)

За изпълнение на непрекъсната интеграция, ние имахме повечето от нашите продукти, за да се създаде доста сложно решение, базирано на Maven и QuickBuild'e. Това е изключително полезно и спестява много време. В допълнение, той ни даде възможност да веднъж завинаги да се отървете от класическата фраза: "но ми тя работи!". Нашият непрекъснат сървъра интеграция е "съдия" или еталон срещу чиято ефективност се определя от всички изходния код. Всеки път, когато някой промените ви към системата за контрол на версиите, непрекъснато сървъра интеграция започва отново събира всички налични проекти и задвижва всички тестове на сървъра. Ако нещо се обърка, сървърът се изисква да изпратят уведомление до всички екипи на участниците. Тези имейли съдържат информация за това, какви промени са разбити събранието, се отнасят до докладите от изпитанията, и така нататък. Г.

Всяка нощ непрестанно повишаване сървъра ще възстанови всеки проект наново и се публикува на нашия вътрешен портал за най-новите версии на изпълними файлове (EAR, WAR, и така нататък. Г. [5]), документация, доклади за тестове, за да покрият тестове за зависимости между модули и библиотеки, както и по- много полезни неща. Някои проекти инсталират автоматично на тест сървър.

За да направим нещата работят, трябваше да прекарват много време. но повярвайте ми, че си е струвало.

Съвместна собственост код (Колективен код собственост)

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

Информационна работно място

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

Въпреки, че ние се насърчи използването на задачите на борда, не всички отбори са ги осъществят (вж. П. на 43 г. "Тъй като ние сме оборудвани стаята екип")

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

Ето един малък откъс от нашите стандарти за кодиране:

• Възможно е да нарушавате някое от тези правила, но трябва да има основателна причина и това трябва да бъде документирана.

• При никакви обстоятелства не трябва да се изравнят изключения без съхраняване на програмата за стек пълен повикване (стека) или повторно генериране на изключение (rethrow). Допустимо използване log.debug (), просто не губи стека на повикване.

• За да се премахне здраво свързване между класове използват зависимостта инжектиране въз основа на създателите (сетер Въз Injection) (разбира се, с изключение на случаите, когато такова свързване задължително).

• Избягвайте съкращения. Добре известни съкращения, като DAO, са допустими.

• Методите, които връщат колекции или масиви не трябва да се връщат нулеви. Върнете празни колекции и масиви вместо нула.

Стабилни темпове / енергичен работа

Много книги, посветени на развитието на Agile-софтуер твърдят, че продължителната обработка води до спад в производителността.

След няколко не съвсем доброволно експерименти по този въпрос, аз мога да се съглася само с цялото си сърце!

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

Няколко месеца по-късно, ние бяхме в състояние да намали количеството на обработка до приемливо ниво. Хората вече не работят извънредно (с изключение на редки кризи в проекта), и - ето изненадата! - и производителността и качеството код подобрило значително.

Разбира се, намаляването на броя на работните часове не е единствената причина за повишаване на производителността и подобряване на код. Но ние сме уверени, че той е играл важна роля.

Забележки:

файлов формат, който се използва, за да се съберат J2EE модули (прибл. преводач)