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

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

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

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

[slideshare id=13269455&doc=2012-06-09itbrunch-120610143607-phpapp01]

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

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

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

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

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

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

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

• Расширить узкое место – добавить еще ресурсов
• Снизить нагрузку на входе – ведь все равно больше не выйдет – и синхронизировать все остальные этапы с этим узким местом

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

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

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

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

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

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