Tag Archives: ошибки

Детские шаги

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

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

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

Read full storyComments { 1 }

Как разочароваться в Agile

Самый простой и легкий способ разочароваться в Agile это начать врать своей команде, что мы работаем по Agile. Больше ничего и делать не надо.

Такая ситуация далеко не редкость. Ко мне регулярно приходят на собеседование программисты, которые жалуются на проблему устроенности процессов в своей бывшей компании. И ладно бы просто был бардак… Хуже. Этот бардак менеджеры называют agile’ом.

Именно так.

Не так давно мы общались с одним разработчиком, который рассказывал о подобной проблеме. Я попросил его более подробно изложить, как у них устроен процесс. Оказалось, что для управления софтверным проектом используется BaseCamp (wtf!), куда заказчик выливает поток сознания в виде messages. Этот поток сознания обрабатывается тим-лидом, который распределяет работу сам на имеющихся разработчиков. Готовый результат заливается на хостинг. Ни итераций, ни управления требованиями, ни толкового планирования, ни митингов не происходит. Судя по всему и биллинг также сопряжен с проблемами, когда по факту месяца приходится выискивать в байзкамповских отчетах сколько стоила для клиента та или иная фича. Типичный саппорт с арендой ресурсов гордо именуется Agile-методикой.

Т.е. я не хочу сказать, что саппорт с арендой ресурсов не может работать по аджайлу. Может. Но в чем смысл называть подобный метод разработки, скажем, скрамом, если каждый разработчик может в любой момент прочитать статью в интернете и узнать, что такое действительно Скрам?

Read full storyComments { 2 }

Неправильное понимание Scrum

Scrum (да и вообще Agile методологии) иногда понимают не совсем правильно. В основном это связано с возведением некоторых рекомендаций в абсолютную степень. Чтобы не повторять долгий путь, проделанный Scrum-методологией (а она развивается с конца 80-х – начала 90-х гг. XX века), полезно изучить некоторые ошибки в понимании Scrum. А заодно и задуматься, а не повторяются ли эти ошибки в данной команде/проекте/компании.

Большую часть ошибок можно разбить на две категории:

  • Взаимоотношения между командой и заказчиком
  • Процесс разработки

(more…)

Read full storyComments { 2 }

Проблемы и ошибки при внедрении Scrum

Введение

При первом прочтении какой-нибудь статьи о Scrum складывается впечатление, что внедрить Scrum проще простого. Всего-то daily stand-up, planning meeting и sprint review. На самом деле, формальный Scrum отличается от работающего Scrum’a. Поэтому предлагаю рассмотреть некоторые ошибки, которые часто встречаются при внедрении Scrum’a без помощи опытного Scrum master’a.

Product ownership

Отсутствие product owner’a

Product owner должен предоставлять видение продукта, истории пользователя, определять приоритеты, отвечать на вопросы и давать постоянную обратную связь. Если такой роли нет, то проект будет двигаться непонятно куда, не удастся получить максимальную бизнес-полезность, команда будет периодически простаивать, продукт в итоге может получиться совсем не тот, что ожидался.

Заказчик не всегда готов (или может) выделить отдельного человека на роль product owner’a. В таком случае можно ввести Proxy product owner’a. (more…)

Read full storyComments { 4 }

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

Автор: Dmitry Zdanovich

О жизни

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

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

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

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

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

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

Read full storyComments { 2 }

Гоните их в шею, или синдром “знающих-как-должно-быть-на-самом-деле”

Вчера днем окончательно решил убрать из своей команды одного камрада. Расстались так сказать по обоюдному согласию. Перед расставанием как водится провели последний разговор. Ну типа на тему “что определяет твое нежелание работать с нами?”. И его ответы живо напомнили недавнюю историю – тут же и решил ее опубликовать.

В июле я вернулся с Алтая. Места умопомрачительные: тот, кто побывал здесь хотя бы один раз – обязательно вернется. Фоток даже добавлять не буду – они даже примерно не передают ощущения Алтая – главным образом потому что посредством фотографии не получается вертеть башкой, плюс на фотографии сделанной впопыхах ощущение глубины исчезает. Короче, поверьте мне на слово – это место, где встречаются небо и земля, где в горах ты идешь по небу.

И вот в этой удивительной стране корячилась группа товарищей, которые умудрились не получить никакого удовольствия и вообще обозлиться на этот замечательный край.

Дело было так. (more…)

Read full storyComments { 17 }

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

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

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

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

Read full storyComments { 0 }