Как перестать ловить яйца в спешке, попутно роняя дедлайны? Какой тулчейн выбрать, чтоб уничтожать по несколько тасков за раз? Все это раскроем в нашей статье.
В те времена, когда наша компания только зарождалась в пронизанной солнцем, стеклянной утробе офиса, а в команде было лишь три человека (менеджер и два разработчика), полных энтузиазма и кофе, мы не имели абсолютно никакой методологии по управлению проектами и действовали по наитию, подходя к работе по принципу “один человек – один проект”. При этом, речь даже не шла о том, чтобы разработчики, взаимодействуя внутри одной задачи, мержили отдельные куски кода между собой, а весь ландшафт девелоперской среды висел на машине самого разработчика. В качестве репозитория и системы управления версиями мы тогда использовали SVN, который на тот момент больше был похож на папку с zip — архивчиками. Несмотря на то, что SVN является одной из крупнейших систем управления версиями и имеет соответствующее комьюнити, его функционал устраивал нас только в плане сохранения кода, в остальном все было как-то скудновато: не было локальной версии и возможности мержить код. Поэтому мы начали искать что-то более подходящее нашим аппетитам — началась выработка рабочего процесса. Первое что необходимо было решать это вопрос с планированием и постановкой задач, а также их распределением относительно друг друга, чтобы уйти от монопроектности к совместной разработке и выдерживанию дедлайнов. На тот момент единственным видом планирования были совещания с тетрадками. При таком подходе до эффективности и оперативности было как до луны на запорожце, кто-то успевал все отметить, кто-то забивал или забывал. В итоге люди уходили с совещания без четкого понимания что и как им делать, с кучей информации в голове и с парой каракуль в блокноте.
Первым шагом в уменьшении энтропии рабочего процесса было создание нормального репозитория, для совместной работы над проектами и соединения отдельных частей кода. Мы выкинули старенький SVN и подняли GIT на локальной машине нашего CEO. Для просмотра и соединения кода использовали простые консольные утилиты. Это было не совсем удобно, но хотя бы позволяло поддерживать порядок и прозрачность изменений в проекте.
У нас все также оставались проблемы с планированием, и как следствие, с выдерживанием дедлайнов. Для этого необходимо было найти средство декомпозирования задач и отображения статуса их выполнения. Попыткой решения этого вопроса стало применение приложения для управления проектами RedMine, с которого и начался активный бенчмаркинг тулчейна. Утилита хорошо подходила для разработчиков (возможности ведения проектов, форумы, отслеживание ошибок), но к сожалению, менеджерам она давалась очень тяжко. Разработчикам постоянно приходилось обрабатывать всю информацию (мержреквесты, пулреквесты и т.д.) из СУВ, и вносить ее в программу RedMine, для того, чтобы менеджеры могли отследить степень завершенности задачи. Вдобавок к этому, не хватало и дополнительных функций по управлению проектами, поэтому мы начали поглядывать в сторону FengOffice.
Инструмент обладал довольно широким спектром функциональности, давая возможность пофантазировать на тему объединения коммуникации и средств планирования вроде диаграммы Ганта в единую рабочую систему. Однако при всей оснащенности этого продукта, разработчикам приходилось вручную закрывать задачи, параллельно ведя статистику у себя, так как не было автоматической синхронизации по выполняемым таскам. Кроме того, реализация внутреннего чата, была больше похожа на подобие старенькой версии ICQ, чем на нормальный корпоративный чат, а для нас этот момент был очень важен.
Мы понимали, что для того чтобы весь механизм работал слаженно, простых совещаний явно не хватает. Встала необходимость выбора оперативных инструментов для налаживания коротких коммуникаций, которые были нужны даже для людей, сидящих рядом друг с другом в одном помещении. Тут возникает два момента: первый – если проводить короткие разговоры в обычном формате, то они будут занимать слишком много рабочего времени, что привет к краху всех дедлайнов и жесткому отставанию от графика, и второй – если делать минимум коротких взаимодействий, то это приведет к потере тесной коммуникации между членами команды, несогласованности их действий, дублированию кода и прочим траблам. Поэтому мы пришли к простому решению — перевести микросовещания в командный чат, который позволяет постоянно общаться без сильного отвлечения от рабочего процесса, согласовывать действия разработчиков и избегать повторного выполнения одних и тех же тасков, а также споров о том, кто выполнил задачу лучше. Решение может показаться очевидным и тривиальным, но дело не в средстве взаимодействия, а в подходе и качестве использования инструмента. Вопрос был в том, как превратить чат из места для флуда и угара, в частичную замену совещаниям и персональным разговорам.
Тем временем обычного GIT уже не хватало, ощущалась сильная нехватка веб-интерфейса. В меню у нас было два варианта: приватный репозиторий на GitHub и репозиторий на GitLab. GitLab бесплатный — его и взяли. К тому же у него крутое, дружелюбное комьюнити. Кроме того, GitLab уже имел, встроенную систему планировки задач и давал удобный интерфейс для мержреквестов. Если вы работали в команде, то наверняка знаете насколько важно быстро получить одобренный мержреквест. В конечном счете мы похоронили FengOffice и остановились на GitLab. Тем более на тот момент мы уже использовали Slack в качестве командного чата, а учитывая тот факт, что у GitLab намечалась взаимная интеграция со Slack, и все это добро было еще и бесплатным, выбор для нас стал как никогда очевиден.
Затем наступил момент, когда необходимо было выбрать наиболее подходящую под наши реалии методологию по гибкому управлению проектами. Мы остановились на двух наиболее развитых и популярных подходах: Kanban и Scrum. Инициатива целиком и полностью исходила от нашего CEO Ильи Быкони, который с прометеевым огнем в глазах глаголил команде о грядущих переменах. Но к его большому удивлению, команда, поначалу, встретила нововведения, как спартанцы встречали Ксеркса, с ожесточенным упорством консервативных копий. Что поделаешь, иллюзии, иллюзии, ведь в книгах предупреждали…Тут же был подмечен интересный факт, что негативное отношение к новым подходам никак не коррелирует с адекватностью и трудоспособностью людей. Даже молодые джуны, которые должны были, по идее, с легкостью все это подхватить, сопротивлялись, аргументируя тем, что: “они лучше 15 минут попрограммируют, чем будут тратить это время на очередное дейли”, “ зачем вообще планирование, если дедлайны все равно не выполняются или выполняются, но с отклонениями”, “зачем разработчику фронтетенда слушать про бэкенд” и т.д. Дело в том, что методология Agile- подходов подразумевает такой стиль работы, при котором не получается по-старинке сесть на атлантовы плечи сильного разраба и доехать до выполнения проекта на его скилах, а ведь многие так и привыкли работать, поэтому для них подобные изменения становятся болезненными.
Когда мы начали вводить Agile в работу, то в полной мере ощутили ценность коротких и качественных коммуникаций. Часто случается так, что, когда на вход RnD отдела поступают схожие задачи из нескольких источников, менеджеры проектов не могут отловить дубликаты. И вот здесь как раз большую роль начинают играть кратковременные взаимодействия и дейли митинги, которые напрочь защищают от подобных проблем, за счет выявления точек соприкосновения между разработчиками разных команд. Есть и еще один интересный момент — большая часть программистов являются интровертами, т.е любая коммуникация — это микростресс, особенно когда речь идет о митингах в больших командах, где человеку приходится выступать перед широкой аудиторией из разнородных специалистов. И многие люди под страхом подобного дискомфорта не осознают, что альтернатива для таких непродолжительных собраний, может быть даже более неприятная чем дейли. Заменой этому будут постоянные коммуникации на протяжении всего дня, в попытках привести работу к управляемому процессу. Для себя мы сделали вывод, что Agile учитывает интровертность разработчиков и сводит дискомфорт, связанный с необходимостью общения, к минимуму. Конечно, для молодых сотрудников фирмы в любом случае какое-то время это будет стрессом, пока он не вникнет в специфику своей работы и не познакомиться поближе с коллективом, поэтому чем дружелюбнее и эффективнее выстроена культура Agile в фирме, тем быстрее закончится процесс адаптации.
Одним из ключевых мотивационных моментов гибкого подхода является, то что люди привыкают минимизировать свои факапы и баги. Дело в том, что если взять стандартную вертикальную структуру управления, то разработчик несет ответственность за свои косяки перед непосредственным начальником, который наказывает и “бьет палкой по башке” если сотрудник факапит или “гладит по головке” если все сделано четко. Т.е в вертикальной структуре у человека есть вариант отскочить за счет личных отношений или “вкусных печенек”. В Agile взаимодействие коллектива строиться по горизонтально, а значит человеку приходится отчитываться перед всей командой на ежедневных митингах. У него просто тупо не хватит денег на такое количество “печенек”. Поэтому приходится привыкать к тому, что твои ошибки будут подвергнуты обзору твоих коллег, и либо ты окажешься на коне и они будут сыпать на тебя лепестки роз из похвалы твоего профессионализма, либо будешь под конем… В любом случае это сильная прокачка личностных скилов человека, и если атмосфера в фирме достаточно теплая, то человек начинает потихоньку раскрываться, внося все больший вклад в экосистему своего отдела и компании в целом. Также мы прочувствовали на личном опыте фильтрующий эффект Agile, не один раз сталкиваясь с ситуацией, когда объективно слабые разработчики не выдерживают постоянного разбора их ошибок, и в конечном счете просто сливаются, если понимают, что у них не хватает внутренней мотивации и сил для того, чтобы перейти из статуса багодела в статус богакода.
Надо сказать, что процесс заведения Agile машины оказался достаточно продолжительным, и очень напряженным, “не обошлось и без насилия” — первоначально народ приходилось практически палкой загонять на митинги и дейли, чтобы люди как-то начинали обозначать свою позицию по решаемым ими задачам. Хотя нам постоянно приходится “лезть под капот” и возится с “движком”, пачкая руки в мазуте, но оно стоит того чувства, когда команда набирает обороты и мчится вперед, собирая чекпоинт за чекпоинтом. Мы не прекращаем свою эволюцию ни на секунду, всегда находимся в статусе вечных экспедиторов, постоянно изучаем новые и дорабатываем существующие модели управления и взаимодействия между сотрудниками. Одно мы понимаем абсолютно точно – там, где нет движения и борьбы, нет и жизни. Как говорят дзен-монахи: “Дошел до вершины, продолжай восхождение…” Всем удачи в ваших восхождениях и пусть каждый идет навстречу к своей вершине, несмотря ни на что!
Вот примерный список и тайминг этапов которые мы прошли:
А вот небольшая подборка от нашего CEO:
Пытаемся поймать все яйца
В те времена, когда наша компания только зарождалась в пронизанной солнцем, стеклянной утробе офиса, а в команде было лишь три человека (менеджер и два разработчика), полных энтузиазма и кофе, мы не имели абсолютно никакой методологии по управлению проектами и действовали по наитию, подходя к работе по принципу “один человек – один проект”. При этом, речь даже не шла о том, чтобы разработчики, взаимодействуя внутри одной задачи, мержили отдельные куски кода между собой, а весь ландшафт девелоперской среды висел на машине самого разработчика. В качестве репозитория и системы управления версиями мы тогда использовали SVN, который на тот момент больше был похож на папку с zip — архивчиками. Несмотря на то, что SVN является одной из крупнейших систем управления версиями и имеет соответствующее комьюнити, его функционал устраивал нас только в плане сохранения кода, в остальном все было как-то скудновато: не было локальной версии и возможности мержить код. Поэтому мы начали искать что-то более подходящее нашим аппетитам — началась выработка рабочего процесса. Первое что необходимо было решать это вопрос с планированием и постановкой задач, а также их распределением относительно друг друга, чтобы уйти от монопроектности к совместной разработке и выдерживанию дедлайнов. На тот момент единственным видом планирования были совещания с тетрадками. При таком подходе до эффективности и оперативности было как до луны на запорожце, кто-то успевал все отметить, кто-то забивал или забывал. В итоге люди уходили с совещания без четкого понимания что и как им делать, с кучей информации в голове и с парой каракуль в блокноте.
Подбираем тулчейн
Первым шагом в уменьшении энтропии рабочего процесса было создание нормального репозитория, для совместной работы над проектами и соединения отдельных частей кода. Мы выкинули старенький SVN и подняли GIT на локальной машине нашего CEO. Для просмотра и соединения кода использовали простые консольные утилиты. Это было не совсем удобно, но хотя бы позволяло поддерживать порядок и прозрачность изменений в проекте.
У нас все также оставались проблемы с планированием, и как следствие, с выдерживанием дедлайнов. Для этого необходимо было найти средство декомпозирования задач и отображения статуса их выполнения. Попыткой решения этого вопроса стало применение приложения для управления проектами RedMine, с которого и начался активный бенчмаркинг тулчейна. Утилита хорошо подходила для разработчиков (возможности ведения проектов, форумы, отслеживание ошибок), но к сожалению, менеджерам она давалась очень тяжко. Разработчикам постоянно приходилось обрабатывать всю информацию (мержреквесты, пулреквесты и т.д.) из СУВ, и вносить ее в программу RedMine, для того, чтобы менеджеры могли отследить степень завершенности задачи. Вдобавок к этому, не хватало и дополнительных функций по управлению проектами, поэтому мы начали поглядывать в сторону FengOffice.
Инструмент обладал довольно широким спектром функциональности, давая возможность пофантазировать на тему объединения коммуникации и средств планирования вроде диаграммы Ганта в единую рабочую систему. Однако при всей оснащенности этого продукта, разработчикам приходилось вручную закрывать задачи, параллельно ведя статистику у себя, так как не было автоматической синхронизации по выполняемым таскам. Кроме того, реализация внутреннего чата, была больше похожа на подобие старенькой версии ICQ, чем на нормальный корпоративный чат, а для нас этот момент был очень важен.
Мы понимали, что для того чтобы весь механизм работал слаженно, простых совещаний явно не хватает. Встала необходимость выбора оперативных инструментов для налаживания коротких коммуникаций, которые были нужны даже для людей, сидящих рядом друг с другом в одном помещении. Тут возникает два момента: первый – если проводить короткие разговоры в обычном формате, то они будут занимать слишком много рабочего времени, что привет к краху всех дедлайнов и жесткому отставанию от графика, и второй – если делать минимум коротких взаимодействий, то это приведет к потере тесной коммуникации между членами команды, несогласованности их действий, дублированию кода и прочим траблам. Поэтому мы пришли к простому решению — перевести микросовещания в командный чат, который позволяет постоянно общаться без сильного отвлечения от рабочего процесса, согласовывать действия разработчиков и избегать повторного выполнения одних и тех же тасков, а также споров о том, кто выполнил задачу лучше. Решение может показаться очевидным и тривиальным, но дело не в средстве взаимодействия, а в подходе и качестве использования инструмента. Вопрос был в том, как превратить чат из места для флуда и угара, в частичную замену совещаниям и персональным разговорам.
Тем временем обычного GIT уже не хватало, ощущалась сильная нехватка веб-интерфейса. В меню у нас было два варианта: приватный репозиторий на GitHub и репозиторий на GitLab. GitLab бесплатный — его и взяли. К тому же у него крутое, дружелюбное комьюнити. Кроме того, GitLab уже имел, встроенную систему планировки задач и давал удобный интерфейс для мержреквестов. Если вы работали в команде, то наверняка знаете насколько важно быстро получить одобренный мержреквест. В конечном счете мы похоронили FengOffice и остановились на GitLab. Тем более на тот момент мы уже использовали Slack в качестве командного чата, а учитывая тот факт, что у GitLab намечалась взаимная интеграция со Slack, и все это добро было еще и бесплатным, выбор для нас стал как никогда очевиден.
Книги не соврали
Затем наступил момент, когда необходимо было выбрать наиболее подходящую под наши реалии методологию по гибкому управлению проектами. Мы остановились на двух наиболее развитых и популярных подходах: Kanban и Scrum. Инициатива целиком и полностью исходила от нашего CEO Ильи Быкони, который с прометеевым огнем в глазах глаголил команде о грядущих переменах. Но к его большому удивлению, команда, поначалу, встретила нововведения, как спартанцы встречали Ксеркса, с ожесточенным упорством консервативных копий. Что поделаешь, иллюзии, иллюзии, ведь в книгах предупреждали…Тут же был подмечен интересный факт, что негативное отношение к новым подходам никак не коррелирует с адекватностью и трудоспособностью людей. Даже молодые джуны, которые должны были, по идее, с легкостью все это подхватить, сопротивлялись, аргументируя тем, что: “они лучше 15 минут попрограммируют, чем будут тратить это время на очередное дейли”, “ зачем вообще планирование, если дедлайны все равно не выполняются или выполняются, но с отклонениями”, “зачем разработчику фронтетенда слушать про бэкенд” и т.д. Дело в том, что методология Agile- подходов подразумевает такой стиль работы, при котором не получается по-старинке сесть на атлантовы плечи сильного разраба и доехать до выполнения проекта на его скилах, а ведь многие так и привыкли работать, поэтому для них подобные изменения становятся болезненными.
Когда мы начали вводить Agile в работу, то в полной мере ощутили ценность коротких и качественных коммуникаций. Часто случается так, что, когда на вход RnD отдела поступают схожие задачи из нескольких источников, менеджеры проектов не могут отловить дубликаты. И вот здесь как раз большую роль начинают играть кратковременные взаимодействия и дейли митинги, которые напрочь защищают от подобных проблем, за счет выявления точек соприкосновения между разработчиками разных команд. Есть и еще один интересный момент — большая часть программистов являются интровертами, т.е любая коммуникация — это микростресс, особенно когда речь идет о митингах в больших командах, где человеку приходится выступать перед широкой аудиторией из разнородных специалистов. И многие люди под страхом подобного дискомфорта не осознают, что альтернатива для таких непродолжительных собраний, может быть даже более неприятная чем дейли. Заменой этому будут постоянные коммуникации на протяжении всего дня, в попытках привести работу к управляемому процессу. Для себя мы сделали вывод, что Agile учитывает интровертность разработчиков и сводит дискомфорт, связанный с необходимостью общения, к минимуму. Конечно, для молодых сотрудников фирмы в любом случае какое-то время это будет стрессом, пока он не вникнет в специфику своей работы и не познакомиться поближе с коллективом, поэтому чем дружелюбнее и эффективнее выстроена культура Agile в фирме, тем быстрее закончится процесс адаптации.
Одна палка — больно, много палок – смертельно
Одним из ключевых мотивационных моментов гибкого подхода является, то что люди привыкают минимизировать свои факапы и баги. Дело в том, что если взять стандартную вертикальную структуру управления, то разработчик несет ответственность за свои косяки перед непосредственным начальником, который наказывает и “бьет палкой по башке” если сотрудник факапит или “гладит по головке” если все сделано четко. Т.е в вертикальной структуре у человека есть вариант отскочить за счет личных отношений или “вкусных печенек”. В Agile взаимодействие коллектива строиться по горизонтально, а значит человеку приходится отчитываться перед всей командой на ежедневных митингах. У него просто тупо не хватит денег на такое количество “печенек”. Поэтому приходится привыкать к тому, что твои ошибки будут подвергнуты обзору твоих коллег, и либо ты окажешься на коне и они будут сыпать на тебя лепестки роз из похвалы твоего профессионализма, либо будешь под конем… В любом случае это сильная прокачка личностных скилов человека, и если атмосфера в фирме достаточно теплая, то человек начинает потихоньку раскрываться, внося все больший вклад в экосистему своего отдела и компании в целом. Также мы прочувствовали на личном опыте фильтрующий эффект Agile, не один раз сталкиваясь с ситуацией, когда объективно слабые разработчики не выдерживают постоянного разбора их ошибок, и в конечном счете просто сливаются, если понимают, что у них не хватает внутренней мотивации и сил для того, чтобы перейти из статуса багодела в статус богакода.
Подытожим
Надо сказать, что процесс заведения Agile машины оказался достаточно продолжительным, и очень напряженным, “не обошлось и без насилия” — первоначально народ приходилось практически палкой загонять на митинги и дейли, чтобы люди как-то начинали обозначать свою позицию по решаемым ими задачам. Хотя нам постоянно приходится “лезть под капот” и возится с “движком”, пачкая руки в мазуте, но оно стоит того чувства, когда команда набирает обороты и мчится вперед, собирая чекпоинт за чекпоинтом. Мы не прекращаем свою эволюцию ни на секунду, всегда находимся в статусе вечных экспедиторов, постоянно изучаем новые и дорабатываем существующие модели управления и взаимодействия между сотрудниками. Одно мы понимаем абсолютно точно – там, где нет движения и борьбы, нет и жизни. Как говорят дзен-монахи: “Дошел до вершины, продолжай восхождение…” Всем удачи в ваших восхождениях и пусть каждый идет навстречу к своей вершине, несмотря ни на что!
P.S:
Вот примерный список и тайминг этапов которые мы прошли:
- Формирование планирования ~ 4 месяца
- Работа с короткими коммуникациями ~ 1 месяц
- Поиск подходящего тулчейна и выработка рабочего процесса ~ 2 месяца
- Выбор методологии ~ 2 месяца
- Введение Scrum в рабочий процесс ~ 8 месяцев
А вот небольшая подборка от нашего CEO:
- «Постигая Agile» — Эндрю Стеллман и Дженнифер Грин
- «Путь скрам-мастера» — Зузана Шохова
- «Scrum Революционный метод управления проектами» — Джефф Сазерленд
- «Канбан Альтернативный путь в Agile» — Дэвид Андерсон
- «Во главе трансформации. Применение принципов Agile и DevOps в масштабе всей компании» — Гарри Грувер и Томми Маузер
Комментарии (3)
mskotyn
28.08.2018 14:56Интересно, сколько сейчас людей, какова организационная структура, распределение обязанностей и насколько разнородные проекты.
Просто проекты бывают разные — добавить несколько полей к табличке или хоткеи к скрину (и еще 99 подобных несвязанных изменений в рамках одного проекта), миграция многосервисной системы с HP Blades на VMs, миграция между датацентрами (ага, перенос системы состоящей из кучи сервисов и перемалывающей терабайты данных в сутки занял более полугода зато даже физическое повреждение основного оптоволоконного канала между датацентрами осталось незаметным для клиентов). Некоторые не запускаются вообще — после сбора реквайрментов (например инициатор тихо слился без объяснения как баззворды соединить так, чтобы получить прибыль) или оценки необходимых вложений («Собрать месячный архив для постобработки вполне реально, но потребуется не менее 60ТБ хранилища потому, что сейчас обрабатывается потоково 2ТБ данных в сутки. Может аналитики воспользуются одним из существующих инструментов фильтрации потока данных или объяснят чего именно не хватает в существующих инструментах?» И внезапно оказалось, что аналитики забыли о существовании этих инструментов).
P.S. Про палки забудьте, если не хотите получить дикие оверестимейты и партизан в гестапо. Дейли скрамы они не про отчет перед всей командой, они для информирования о прогрессе. И не ошибается тот, кто ничего не делает.
agafonovpsy
Хотелось бы от вас более подробную статью про введение Scrum.
Про повседневные коммуникации в Slack-почему на нем остановились?
Nova07 Автор
Постараюсь написать отдельную статью на интересующие Вас вопросы. Эта статья была больше обзорной, чтоб не делать совсем лонгрид. Согласен с тем, что моменты по Scrum можно и нужно раскрыть поподробнее.