На прошедшей недавно онлайн конференции ITBrunch все докладчики делились своими ошибками и опытом, который из них почерпнули. Тема «Учимся на чужих ошибках» была выбрана не случайно, ведь именно из опыта мы выносим уроки и уж лучше это делать на чужом опыте, чем на своем 🙂

Мой рассказ был из личного опыта, об одном проекте, о внедрении Agile методологий и о том, почему им ничего не помогло. Помимо самой истории, что и как я делал, я рассказал свои мысли о том, что повлияло на «провал» всего проекта.

Успех внедрения процессов не всегда приводит к успеху проекта. К сожалению, ИТ специалисты не всегда задумываются об этом, хотя могли бы.

Ниже сама презентация и ответы на вопросы участников…

Q: Что дальше случилось с командой после грандиозного провала проекта? Каким образом сохранить команду, если даже проект провалился?

Те, кто слышали доклад или дослушали запись до конца, уже поняли мою основную мысль: проект был успешен с точки зрения внедрения процесса, организации команды и даже организации выпуска продукта, но он оказался коммерчески не рентабельным и был закрыт высшим руководством.

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

Q: Какие действия были предприняты командой, когда QA оказался перегружен?

Q: Что делать если QA не успевает покрыть функционал автотестами, и потом из-за этого вылезают баги?

Поскольку я обучал эту команду самым главным принципам,  то потом мы вспоминали то, что было на тренинге. В частности, я всегда стараюсь рассказать о потоке работы, который проходит через команду. На входе в нашу «систему» поступают хотелки/требования, а на выходе мы выдаем рабочий продукт. Наша задача организовать процесс так, чтобы оптимизировать поток. Известно, что любой поток движется со скоростью своего самого узкого места.

Основных принципов работы с узким местом не так уж и много:

  • Расширить узкое место — добавить еще ресурсов
  • Снизить нагрузку на входе — ведь все равно больше не выйдет — и синхронизировать все остальные этапы с этим узким местом
В нашем случае, в частности, это выразилось в том, что разработчики начали брать на итерацию меньше работы, даже если и казалось, что кто-то будет простаивать. Нет смысла брать функциональность, которую мы точно не успеем протестировать.
Отдельно разработчики предприняли шаги, чтобы помочь тестировать вручную. Плюс ввели тест-листы вместо расширенных сценариев и стали чаще делиться знаниями устно, что позволило разработчикам самим писать авто-тесты.

Q: Как передавали знания от тим-лида команде, в которых был компетентен только он?

Универсального совета нет. Насколько я знаю, другой опытный разработчик стал работать с ним в паре, пересматривать его код. Разработчики стали сами разбираться в кусках системы, которые раньше не знали. Что-то оказалось проще переписать заново 🙂

Q: А если команда недостаточно сильная изначально. Нужен сильный лид, чтобы все организовать по agile?

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

Если в команде нет внутреннего лидера, то может помочь внешний «Agile коуч». Когда-то, я публиковал статью Консультанты, тренеры, коучи и другие милые люди, где рассказывал об основных отличиях между разными понятиями. Ведь даже человек, который может поделиться своим опытом и поддержать вас на пути к цели, уже хорошо.

При желании опыт можно почерпнуть из многих источников. Кроме личной работы, есть еще конференции, тренинги и статьи на профессиональных сайтах. Подписывайтесь на наш RSS, у нас много полезных и практических материалов — не зря мы называемся The Improved Methods 🙂

Успех не всегда означает победу — рассказ на онлайн конференции ITBrunch: "Учимся на чужих ошибках"
Tagged on: