Я многого не знаю. Например, я не знаю, кто был тот мудак, который раз и навсегда перевёл термин agile как «гибкий». Имя есть?

Flexible — гибкий.

Agile — проворный, подвижный, верткий, живчик.

Тестирования ради, усядьтесь голым попом на горячую сковородку — вы моментально станете agile.

Впрочем, кое-что я знаю — Асхат Уразбаев первым мощно предложил опечатался про слоган внедрения agile в 2014-ом году.

Есть мнение о том, что данный способ внедрения уже известен древним пользователям русского языка (тыц, тырдыц), однако красочности он от этого не теряет.

А ещё я знаю следующее: agile не методология и не процесс. Это надстройка над уже существующей методологией и уже существующими процессами. И если их нет, то внедрять agile не на что.

То есть, у вас может не быть скрама и доски на стене, а agile может быть. У вас процесс производства может не меняться, а agile над ним — работает.

(далее…)

Read Full Post »

Участники:

• Асхат Уразбаев – учредитель ScrumTrek
• Илья Гаврилов – начальник отдела тестирования, Exigen
• Алексей Лупан – testitquickly.com

О чем говорили

• Как вы стали тестировщиком?
• Чем программист отличается от тестировщика?
• Какой процент кода покрывать авто-тестами?
• Есть ли вред от TDD?
• Кто пишет и кто запускает тесты?
• Имеет ли смысл иметь выделенного тестировщика-автоматизатора и в каких случаях?
• Как проходит планирование итерации с точки зрения тестировщика?
• Где хранить тесткейсы?
• Как автоматизировать тестирование GUI и что такое архитектура тестирования?
• Рост продуктов – как успевать все протестировать за итерацию?

У меня микрофон оказался неимоверно галимым. Участвовал в записи сидя на балконе, зыря на огоньки ночного Кишинева. Лето подходило к логическому концу.

Read Full Post »

Автор: Асхат Уразбаев © (scrumtrek.ru)
В текст перевел: Алексей Лупан (testitquickly.com)

Вместо введения

Доклад был представлен на конференции SQA Days’2009 24 апреля. Его можно послушать в виде слайдкаста (слайды, снабженные звуком). Текст совсем чуть-чуть поправлен и снабжен (не всеми) картинками в нужных местах.

Руководство по тестированию в Agile

Я слушал доклад Виталика Стрелюка, вы были на нем, да? Виталик точно был, я его там видел. Поэтому мой доклад будет в некотором смысле продолжением и в конце я хочу назвать некоторые вещи, которые он не называл, мне кажется, что они могут быть интересными.

Кто-нибудь работает по эджайлу? Пожалуйста, поднимите руки. Уау… А из тех, кто не поднял, кто-нибудь собирается это сделать? Хорошо. Давайте я сначала представлюсь — меня зовут Асхат Уразбаев, меня уже представили, поэтому я коротко… Он сказал всю правду обо мне, немножко преувеличил местами… Работаю в компании ScrumTrek, мы занимаемся внедрением гибких методологий, помогаем компаниям и организациям всем этим заниматься.

(далее…)

Read Full Post »

Сравнилось «Manifesto for Agile Development» со всеми Евангелиями. Текст один, но как-то толкуется по-разному…

Например:

1. Люди важнее процесса

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

Этот прикол может «не работать» из-за разногласий в методах достижения конечного результата, или из-за проблем с коммуникациями («Чем занимаешься? Почему не приходишь на работу вовремя? Почему не утвердил эти изменения у такого-то начальника?»).

Тем не менее, процесс должен быть всегда и везде. Хоть какой-то. Отрицать необходимость процесса, упирая на «люди важнее» — к несчастью в личной жизни. Или к дождю.

Верно следующее утверждение: если работник просит изменить процесс, то при рассмотрении этого дела приоритет будет у работника, а не у заведующего процессом.

2. Реакция на изменения важнее следования плану

Отрицать необходимость существования хоть какого-то плана — тоже ошибка юности, и несомненно — к дождю в личной жизни.

Просто надо знать, что планы корректируются по ходу дела. Ежеминутно.

Двое людей выезжают из пункта А в пункт Б. У первого есть план. У второго — нет. Второй — романтик… У кого больше шансов «доехать»?

Учитывая прогноз «к дождю», вероятнее всего — не доедут оба. Но у первого, как ни крути, больше шансов доехать, чем у того, кто просто жмет на педали, глядя на ромашки.

Ведь у первого есть хоть какие-то соображения по выбору пути и техническому оснащению. И если заблудится — он хотя бы знает, куда и зачем ехал. И если придется выбирать дорогу на перекрестках, или делать компромиссы — у него будет путеводная Альфа-Центавра, которую он никак не найдет на засыпанном звездами небе.

Вот если он заблудится, но будет тупо следовать плану…

3. Работающий код важнее документации

Да.

Но это не значит, что документацию не надо писать 🙂

Если встает проблема «или делать код, или делать к нему документацию», то первый вариант приоритетнее — вот и всё.

Сперва подумай о том, что ты сам в какой-то момент начнешь путаться в «работающем коде».

Затем подумай о том, что когда-нибудь состав команды изменится. Кто-то уйдет, кто-то придет. Как быстро ввести новичка в курс дела?

Еще запланируй внезапную смерть главного «носителя» информации по проекту…

Документацию, все-таки, надо делать. «Agile» не означает, что можно проектировать и кодировать без сборника информации о том, что и как, по-меньшей мере, предполагалось делать.

Просто документация должна быть в этом случае менее формализованной и более доступной для изменения всеми участниками. Да, подразумевается грамотное использование wiki-систем.

4. Сотрудничество важнее формальных отношений

Еще бы…

Read Full Post »