Tag Archives: практика

Итоги 5й встречи сообщества Agile.BY

Коллеги, 26 февраля мы провели очередную встречу сообщества Agile.BY.

Павел Габриель выступил с презентацией на тему разработки через тестирование (Test Driven Development), а Николай Кардаш поделился опытом и информацией о том, как писать модульные тесты и какими инструментами при этом можно пользоваться.

Николай предоставил исходный код и примеры использования фреймворков, которые он продемонстрировал на встрече (в архиве есть инструкция, как все запускать: DemoReam1st.txt).

Презентация Николая:

[slideshare id=1102171&doc=agileinstrumentation-090304154501-phpapp02] (more…)

Read full storyComments { 11 }

Практика внедрения Agile

Статья написана Виктором Прокопеней в апреле 2007 года. Печатается с любезного разрешения автора. (прим. ред.)

Про методологии Agile мы узнали достаточно недавно – около полугода назад, и нашли очень много общего с тем бизнес-процессом, который сформировался у нас по факту. Изучение Agile дало нам прежде всего осознание того, что мы далеко не уникальны в отношении итерационной разработки, а также помогло сформулировать большое количество принципов, которые никак не могли вырваться наружу в какие-то документы. В своей статье я бы хотел рассказать с абсолютно практической точки зрения как теория превращается в практику – как принципы Agile ложаться на реальную жизнь. (more…)

Read full storyComments { 0 }

Детские шаги

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

В процессе изменения одной части кода возникало желание поменять ещё и соседние функции, благо все изменения лежали в рамках намеченной цели. Много маленьких модификаций, которые не должны были сильно повлиять на общую работу, повлекли за собой сбой во многих тестах.

Я провел 4 часа в попытках привести тесты и код в порядок. Потерял уверенность в стабильности нашей системы и уже был готов к тому, что проведу все выходные с мыслями о том, как же мне все переделать, чтобы было красиво и работало 🙂 (more…)

Read full storyComments { 1 }

Распределенный agile и вопросы коммуникаций

В Гродно на меня работает отличная команда разработки. Я их всех нежно люблю. Виталий Брейда – это надмозг, сочетающий лучшие качества разработчика с въедливостью тестера. Оля Махнач – бизнес-аналитик, который пишет юзер сториз так, как я бы писал сам. Причем используя мои собственные термины типа “отлуп” и “дрючок” – временами не мог отличить, где писал я, а где она. Марина Василюк делает так, что при выходе чудо-софтины багов в ней – минимум. Это при том, что многие вещи мы обсуждаем и меняем чуть ли не перед релизом. Женя Парахневич как знатный скрам-мастер неуклонно бдит над тем, чтобы все работало, молчаливо присутствуя на всех коллах. И вот про коллы я и хотел поговорить.

P1130353Я думаю, все уже поняли, что команда, которая работает – исключительно матерая. На удаленных коммуникациях – собаку вроде бы съели. На инструментах – не экономим, используем GoToMeeting, голосовые конференции, ну и все как положено, см. картинку. (more…)

Read full storyComments { 16 }

Agile – для fixed bid?

Вообще я яростный противник fixed bid-проектов. Fixed bid-проект обычно оставляет и у Заказчика, и у Исполнителя чувство обоюдного проигрыша – Заказчик недополучил функционал, Исполнитель недополучил прибыль (если очень упрощенно). Для того, чтобы этого не произошло, требуется несколько заходов танцев с бубном – во-первых, нужно вдумчиво поработать над концепцией и ТЗ, используя дорогостоящего аналитика и отвлекая (тоже недешевых) ключевых специалистов Заказчика для сессий JAD; во-вторых, нужно установить процесс управления изменениями; и в-третьих, даже при всем при этом чтобы корректно посчитать этот самый fixed bid нужно иметь историю работы команды или релевантную статистику по организации – чтобы перевести полученный юзкейсы и вайрфрэймы в часы работы и календарные дни длительности (из чего и складывается в конечном итоге цена). Ну и в добавок требуется увязать это все в контракте, создав доброжелательную обставновку вооруженного перемирия и взаимного недоверия. Но проект сделать можно. Следствием такого проекта (при условии того, что оговоренный в контракте процесс не похерят в процессе работы) с весьма большой долей вероятности будет адекватная качественная система. (more…)

Read full storyComments { 5 }

Кто такой Proxy Product Owner?

Автор: Dmitry Zdanovich

О жизни

Ура, новый проект! Заказчик говорит – «Ребята, я много слышал про Agile разработку. Я хочу Scrum на проекте». Все просто в восторге. Эйфория полная. Начинается разработка.

– Мы готовы к работе. Где можно найти product backlog?

– Guys, ну вы понимаете, я сейчас очень занят. Давайте попозже.

Команда ждет, пытается что-то предугадать, делает стандартные технические вещи – создает инфраструктуру, выбирает потенциальные framework’и. Через некоторое время разговор повторяется.

– Все, мы уже создали всю инфраструктуру. Мы не знаем, что делать дальше.

– У меня столько дел… (more…)

Read full storyComments { 2 }

Масштабируем Agile

Пусть agile-процесс изначально и рассчитан под небольшие проекты и локальные команды — его вполне можно масштабировать. Главное для этого — открытость и смелость проектных команд и, в первую очередь, руководства.
Откажитесь от ложных целей вроде бюрократичной отчетности и стратегии прикрытия задницы, сконцентрируйтесь на получении необходимого вам продукта. Экспериментируйте с длительностью итераций, составом команд, способами взаимодействия и тестирования… Да, вы будете совершать ошибки, но суть гибкого адаптивного процесса в том, чтобы признавать свои ошибки, учиться на них и постоянно улучшать процесс, а не пытаясь скрыть ошибки и искать козлов отпущения. Технологии и процессы несовершенны, люди несовершенны, мир несовершенен… но это не означает, что не мы не должны учиться и улучшать качество своей работы.

http://mourk.com/blog/2008/05/05/scaling-agile/

Рекомендации по масштабированию Agile для удаленных команд. Да, agile сложно, а может быть даже и невозможно полностью масштабировать для большой, а тем более удаленной команды. Но тем не менее представленный процесс помог избежать ряда проблем, описанных автором в предыдущей публикации.

Read full storyComments { 0 }

Процесс разработки проекта становится гибче

Некоторое время назад у нас начался большой проект, который потребовал внедрения новых методик работы. Классический “водопад” не может обеспечить быстрое и безболезненное внесение изменений в проект. А это плохо. В условиях не четко поставленной задачи (а она и не может быть четко поставлена) требуется быстро вносить изменения, дополнения, новые требования клиента.

Похоже, что работа над подобными проектами, а также просто работа с разнородными задачами клиентов убеждает меня в том, что я бы не осмеливался сказать еще пару-тройку лет назад:

написать большое и всеобъемлющее ТЗ на крупный проект не реально.

Т.е. я хочу сказать, что это или не реально сложно или вообще не реально. Да я писал большие толстые ТЗ, которые описывали с точностью до запятой, как должен работать сайт, где у него какая информация и на какую кнопку надо нажать и вписать, чтобы он сообщил: “Такой формат e-mail недопустим”. (more…)

Read full storyComments { 0 }