Что значит эта команда
Значение слова «команда»
3. кого или какая. Небольшая воинская часть, выделенная в особую единицу или же временно сформированная для определенной цели. Команда разведчиков. Музыкантская команда. Команда квартирьеров. □ [Кожух] — великолепный пулеметчик. В горах забрался с пулеметной командой в тыл туркам. Серафимович, Железный поток. Они пошли рядом во главе команды новых солдат. Казакевич, Весна на Одере. || Группа лиц, выполняющих определенное задание. Пожарная команда. Спасательная команда. □ На зимний лов снаряжали рыболовные команды с главного промысла. Гладков, Вольница.
4. Личный состав, экипаж судна. Через минуту вся команда была наверху, и старший офицер взбегал на мостик. Станюкович, Беспокойный адмирал. Они спустились по крутому узкому трапу, и Чесноков очутился в помещении для команды. Н. Никитин, Северная Аврора. || Спортивный коллектив, возглавляемый капитаном. Футбольная команда. Сборная команда. Команда советских шахматистов. □ Мы собрались на футбольном поле, разбились на две команды, чтоб играть по всем правилам. Носов, Витя Малеев в школе и дома.
5. кого или какая. Разг. шутл. Группа лиц, компания, ватага. Среди молодой своей команды няня преважно разгуливала с чулком в руках. Пущин, Записки о Пушкине.
Источник (печатная версия): Словарь русского языка: В 4-х т. / РАН, Ин-т лингвистич. исследований; Под ред. А. П. Евгеньевой. — 4-е изд., стер. — М.: Рус. яз.; Полиграфресурсы, 1999; (электронная версия): Фундаментальная электронная библиотека
КОМА’НДА, ы, ж. [фр. commande]. 1. Словесный краткий приказ по установленной форме (воен.). Слова команды едва были слышны. Раздалась к. Работать по команде. Слушаться команды. 2. перен. Принуждение, проявление прихоти, каприза (разг. неодобрит.). Тебе (жене) в угодность, как ни грустно, пускаюсь по команде в пляс. Грбдв. 3. Начальствование над какой-н. частью войск, командование (воен. разг.). Принять команду над полком. Быть под командой строгого начальника. 4. Небольшая воинская часть, выделенная в особую единицу (воен.). Саперная к. Учебная к. || Небольшая воинская часть, временно выделенная для какой-н. особой надобности (воен.). К. фуражиров. К. квартирьеров. 5. Экипаж судна, матросы вместе с начальством (мор.). Вся к., как один человек, бросилась к орудиям. 6. Служащие какой-н. пожарной части при исполнении служебных обязанностей (спец.). Вызвать пожарную команду. К. из соседней пожарной части. 7. Группа участников спортивного состязания, одна из борющихся сторон, подчиненная своему капитану (спорт.). Футбольная комагда. На состязаниях по легкой атлетике первый приз получила к. текстильщиков. 8. Всякая группа лиц, ватага, компания (разг. фам. шутл.). В комнату ввалилась веселая к.
Источник: «Толковый словарь русского языка» под редакцией Д. Н. Ушакова (1935-1940); (электронная версия): Фундаментальная электронная библиотека
кома́нда
1. военн. краткий устный приказ командира по установленной форме ◆ Лейтенант дал команду «отбой». ◆ По команде рота остановилась.
2. устное указание лица, направляющего чьи-либо действия
3. разг. распоряжение, приказание ◆ Тебе в угодность, как ни грустно, // Пускаюсь по команде в пляс. Грибоедов, «Горе от ума», 1824 г.
4. автоматически передаваемый сигнал, вызывающий действие какой-либо системы, механизма
5. информ. элементарная инструкция, директива как элемент языка программирования, командного интерфейса различных программ и операционных систем
6. начальствование над какой-либо группой лиц (обычно над воинским подразделением, экипажем судна); командование, руководство ◆ Принять команду над полком. ◆ Быть под командой строгого начальника.
7. разг. о чьём-либо главенстве, власти кого-либо над кем-либо
8. военн. небольшое воинское подразделение ◆ Сапёрная команда. ◆ Учебная команда.
9. военн. воинская единица специального назначения; группа военнослужащих, выполняющих определённое задание ◆ Команда фуражиров. ◆ Команда квартирьеров.
10. морск. личный состав, экипаж судна ◆ Судно остановилось, между тем как от крейсера помчался паровой катер с командой и лейтенантом в белых перчатках. Грин, «Алые паруса», 1923 г.
11. рабочая группа, коллектив, выполняющий какую-либо работу, занятый какой-либо деятельностью ◆ Как идеальная пожарная команда приезжает за полчаса до пожара, так у идеального ученика готовы ответы за полчаса до вопроса. Чехов, «Идеальный экзамен», 1884 г.
12. группа ближайших помощников, окружение какого-либо политического, общественного, спортивного и т. п. деятеля
13. спорт. спортивный коллектив, возглавляемый капитаном ◆ Футбольная команда. ◆ На состязаниях по лёгкой атлетике первый приз получила команда текстильщиков.
14. разг. группа, объединившаяся по каким-либо общим интересам (обычно имеющая какую-либо символику)
16. разг. шутл. о какой-либо группе лиц, компании ◆ Дедушка ваш к нам тотчас и прислал своего ловчего Бауша с командой… Тургенев, «Однодворец Овсянников», 1847 г. ◆ В комнату ввалилась весёлая команда.
Простые консольные команды, которые стоит знать всем
Навыки работы в терминале помогают быть более продуктивным.
Каждый современный разработчик старается совершенствоваться и быть более продуктивным. Терминал — инструмент, позволяющий работать быстрее. Вместо того чтобы кликать мышью для перемещения по графическому интерфейсу, можно просто выполнить ту же самую работу в терминале, но гораздо быстрее. Хотя, это потребует некоторых знаний о консольных командах, которые можно использовать.
Эта статья для тех, кто хотел бы освоить ниндзюцу консольных команд, но пока не имеет сколь значимого опыта работы с командной строкой. Ну и для тех, кто просто хочет больше знать и глубже понимать широкий спектр команд, доступных в терминале — вдруг встретится что-то новое.
Сразу перейдём к списку консольных команд, которые, надеюсь, сделают разработчикам жизнь немного проще и повысят производительность.
Список базовых команд:
Статья переведена при поддержке компании EDISON.
Мы очень любим работать с интефейсами! 😉
1. pwd ⇑ →
Команда pwd выдаёт некоторый контекст о текущем рабочем каталоге. pwd — это сокращение от print working directory т.е. распечатать рабочий каталог. Результат команды — полный системный путь для текущего каталога.
Хотя pwd не имеет столько параметров, сколько у большинства других команд (поскольку она довольно проста), с её помощью можно игнорировать символические ссылки. Для этого надо передать опцию -P.
Это одна из наиболее часто используемых команд вместе со следующими двумя командами в этом списке.
Другая часто используемая команда, это cd. cd — это сокращение от change directory, т.е. смена каталога. Как следует из названия, она позволяет изменить текущий рабочий каталог.
Также есть возможность переместиться сразу на несколько уровней. Для этого нужно указать полный путь к каталогу, к которому необходимо перейти.
В этом примере мы переходим в папку проекта, которая находится внутри папки «Загрузки»:
, используя те две команды, которые уже рассмотрели.
Следующая команда — это ls, сокращение от list, т.е. список. Она выводит список всех файлов в каталоге. Можно также указать каталог, чтобы получить список файлов в нём. Если каталог не указан, используется текущий рабочий каталог.
Обратите внимание, что есть несколько очень полезных опций, с помощью которых можно извлекать ещё более ценную информацию. Опция -a, например. Эта опция позволяет увидеть в списке скрытые файлы (названия которых начинаются с точки). Опция -l выдаёт длинный список, в котором, помимо прочего, указаны размеры файлов и разрешения.
Опции можно комбинировать:
4. cp & mv ← ⇑ →
Команда cp происходит от слова copy, т.е. копирование. Позволяет копировать файлы и каталоги. Первый указанный файл/каталог является исходным (что копируем), на втором месте — местом назначения (куда копируем). В следующем примере мы перемещаем изображение в папку «Загрузки».
При копировании каталога можно использовать опцию -R для рекурсивного копирования (то есть, вместе с подпапками). Обратите внимание, при этом скрытые файлы также будут скопированы.
Существует довольно много вариаций, как копировать файлы и каталоги. Например, возможно скопировать только файлы с определенным расширением. В следующем примере копируются все файлы с расширением jpg в папку «Загрузки».
Помимо команды cp есть также команда mv, которая обозначает move, т.е. перемещение. Эта команда используется для перемещения файлов и каталогов. Работает в целом так же, как и cp. Тем не менее, есть различия. Например, команда mv не идёт с опцией -R.
Чтобы изучить все параметры, доступные для команды mv, просто введите:
5. mkdir & touch ← ⇑ →
Чтобы создать каталог, можно воспользоваться командой mkdir, которая обозначает make directory, т.е. создание каталога. Эта команда требует обязательный аргумент: имя нового каталога. Проверить, была ли команда выполнена успешно, можно с помощью ls, рассмотренной выше.
Создать файл так же просто, как создать каталог. Вместо mkdir нужно использовать команду touch для создания нового файла.
Следует знать, что новосозданный файл будет пустым. И ещё раз, если хотите проверить, была ли команда выполнена успешно — используйте команду ls.
6. rmdir & rm ← ⇑ →
Так же, как есть две разные команды для создания файлов и каталогов, также имеются две отдельные команды, когда речь идёт об удалении файлов и каталогов.
Чтобы удалить каталог, можно использовать команду rmdir, что является сокращением от remove directory, т.е. удаление каталога. Имейте ввиду — команда удаляет только пустые каталоги.
Более мощной является команда rm. Как вы, наверное, догадались, это сокращение от remove, т.е. удаление. Команда rm удаляет каждый указанный файл. Хотя с помощью этой команды можно удалить и каталоги, по умолчанию она этого не делает.
Когда rm выполняется с опцией -r, рекурсивно удаляются соответствующие каталоги, их подкаталоги и все файлы, которые там содержатся.
Чтобы игнорировать несуществующие файлы и никогда не запрашивать подтверждение их удаления, можно использовать опцию -f.
7. cat, tail & head ← ⇑ →
Когда дело доходит до чтения содержимого файла, есть несколько вариантов. Первый — команда cat — сокращение от concatenate, т.е. конкатенация. Несмотря на то, что команду можно использовать в разных целях, одна из вещей, которую она может делать, — показать содержимое файла.
Обратите внимание: выводится весь файл. Также есть случаи, когда вам нужны только первые или последние X строк файла. Для этого используется команды tail и head. tail выводит последние 10 строк файла, тогда как head — первые 10.
Используя опцию -n, можно указать, сколько строк нужно выводить. Тут приведён пример с tail, для head работает точно так же.
8. grep ← ⇑ →
Команда grep, это сокращение от global regular expression print, т.е. глобальный вывод регулярного выражения. Используется для поиска текста. Файл будет просканирован на предмет информации, которую вы требуется получить, и результат будет представлен в указанном формате.
Начнём с очень простого примера. Есть файл, содержащий названия всех стран. Мы хотим проверить, есть ли слово Netherlands (Нидерланды) в списке. Обратите внимание, по умолчанию grep чувствителен к регистру.
Первый передаваемый аргумент — слово, которое ищем. А второй — файл, в котором будем искать.
Для поиска без учёта регистра используется опцию -i. В следующем примере найдётся и BeL и bel и BEL.
Обратите внимание, в приведённых выше примерах видно, что grep выводит всю соответствующую шаблону строку в терминал. Для ограничения количества совпадающих строк, используйте опцию -c.
9. find ← ⇑
Последняя команда на сегодня — find (поиск), позволяющая быстро найти файл или каталог. Допустим, нужны все CSS-файлы в текущем каталоге. Мы могли бы получить их список, используя команду find.
Обратите внимание, команда find ищет и в подпапках тоже.
Теперь, когда мы прошли весь список, я надеюсь, что вы углубили свои знания для работы с терминалом. Может, вам что-то и пригодится, или даже узнали для себя о новой команде или опции к ней.
Если считаете, что в этом списке отсутствует команда или у вас просто есть отличное дополнение к этому списку, пожалуйста, дайте мне знать.
Нужно ли подчиняться решению большинства: особенности командной работы
Что такое команда, командная работа и чем она выгодна для компании?
Как думаете: смог бы один человек без команды построить целую империю? Конечно, нет. Каждая история успеха связана со слаженной командой. Значит, всем, кто стремится к великим свершениям, нужно уметь строить команду, работать с командой и в команде.
Поговорим о том, что такое командная работа, и какой должна быть работа с командой, чтобы это было максимально эффективно.
Разберемся с тем, что дает компании команда, какую роль играет команда для всей организации и для каждого отдельно взятого сотрудника.
Чем командная работа отличается от обычного взаимодействия между людьми
В каком случае люди взаимодействуют в рамках бытовых или рабочих ролей и условий, а в каком происходит командное взаимодействие? С какого момента на работе начинает происходить работа с командой и что такое команда?
Сначала термин «команда» применялся к спортсменам, сейчас активно используется в бизнесе. Командой называют небольшие группы, от трех до двенадцати человек, у которых одна общая цель или общие правила и интенсивное взаимодействие между участниками.
Командной работой считается эффективная и продуктивная деятельность, нацеленная на определенный результат. Командой может называться войско, которое нацелено на победу над противником: чтобы победить, нужно делать все слаженно и сообща. Вместе команду держит одна цель.
Главные черты команды
Определим главные черты команды. Это:
Исходя из характеристик команды, видим, что команда – не простое взаимодействие между рядом находящимися людьми. Люди, которые сидят в одном кабинете или сотрудничают в работе над одним проектом далеко не всегда являются командой.
Командная работа – это труд группы людей, сосредоточенных вокруг какой-либо задачи, а работа с командой – это работа с автономной единицей, внутри которой свои правила и взаимоотношения.
Принципы и особенности команды
Исследователям удалось определиться с принципами команды. Это:
Было доказано, что чем меньше команда, тем она продуктивнее. Команды до 5 человек работают быстрее. Большая команда более функциональна. Но чтобы она держалась и эффективно функционировала, важно профессионально установить роли и правила внутри команды.
Почему команда лучше, чем сотрудничество
Команда эффективнее сотрудничества и это стремятся использовать в целях повышения эффективности организации. Поэтому от лидеров требуется умение создавать команды и работать с командами.
В чем конкретно эффективность команды?
Отдельный человек ограничен полномочиями и компетенциями. В команде, где присутствуют люди с разными полномочиями и профилями, можно выйти на нестандартную идею, которая способна родиться только на стыке компетенций. Причем, команда способна не только найти идею, но и реализовать ее.
Эффект синергии возможен только в команде, значит, совместная работа команды способна дать больше эффекта компании, чем если каждый будет работать сам по себе.
Команда менее подвержена внешнему влиянию, а значит, крепче.
В команде остаются только взвешенные идеи, поскольку каждая из поступающих тщательно обсуждается и поддается многостороннему анализу. Обсуждается как вся идея, так и ее детали, поэтому меньше вероятности появления ошибок.
В командной работе устраняют ошибки, поскольку все они более заметны, чем при работе одному. За собой труднее замечать недочеты.
Наконец, команда – тот сегмент, который способен реализовать каждого сотрудника лучшим образом. Формирование команд – это самое желательное и логичное, что может произойти с рабочим коллективом, поэтому работа с командой для любого руководителя должна быть одним из обязательных навыков. Часто бывает, что команда благодаря своей синергии способна заменить собой одного очень креативного и высококлассного специалиста, оплата труда которого компании не по карману.
Повышение эффективности каждого
Команда обладает еще одним удивительным эффектом – работа в команде способна увеличить эффективность отдельного сотрудника. Хорошая команда способна повысить эффективность отдельного участника не только на время командной работы, но и вне команды. Вот почету так эффективны тренинги по работе в команде и игры на командообразование – после них каждый становится эффективнее. Опыт пребывания в команде настолько силен, что для эффекта бывает достаточно даже нескольких часов командообразующей игры.
Теперь только представьте, насколько лучше, эффективнее и гармоничнее становится человек, который постоянно работает в команде.
Работа в команде делает каждого более открытым и терпимым, учит взаимодействовать с другими людьми, налаживать связи и эффективно сотрудничать. В команде нужно подчиняться решению большинства, и это воспитывает в человеке адекватное восприятие мира, учит логическому и критическому мышлению. Человек в команде учится проявлять эмпатию, развивает эмоциональный интеллект, учится слушать, уважать, понимать других.
Умение работать в команде является положительной характеристикой сотрудника. Такие специалисты высоко ценятся на рынке труда.
В свете выше сказанного, командная работа – это с одной стороны мощный инструмент для достижения компанией своих целей, с другой – средство повышение личной эффективности каждого участника команды.
Командная работа и общий успех
Приведем реальные исторические примеры успеха, который был достигнут благодаря слаженной работе команды.
Стив Джобс и компания «Pixar»
Джобс приобрел себе небольшую компанию в конце 90-х. Компания производила компьютеры. Офис находился в здании, где было три отдельных помещения – для аниматоров, компьютерщиков и руководителей. Казалось бы, все удобно. Но Джобс не успокоился, пока не нашел способ разместить всех в одном помещении. Поместив всех в одно открытое пространство, где они могли бы общаться и совместно решать задачи, Джобс не прогадал, а попал в самую точку. Коллеги почувствовали себя одним целым, способным создать нечто великое. Что из этого получилось – известно всем.
The Rolling Stones: у каждого своя роль
Легендарные The Rolling Stones не теряют популярности уже более 50-ти лет. Своим секретом музыканты делились не раз – он в командном подходе. Перед каждым туром группа готовится вместе на протяжении двух месяцев. Подготовка представляет из себя постоянные интенсивные репетиции. На репетициях участники отрабатывают общий ритм. Кейт Ричардз делился, что он следит за играющей рукой Чарльза Уоттса, чтобы поймать момент, если он сбивается, подает знак Ронни Вуду, что нужно подстроиться под ритм. Каждый знает свою роль и каждый дополняет друг друга.
Интересное наблюдение от Google
Однажды в Google провели исследование секретов успеха идеальных команд компании и к своему удивлению пришли к выводу, что сила не в подборе кадров, как все полагали, а в присутствии чувства психологической безопасности каждого участника команды. Каждый сотрудник должен верить в то, что команда – безопасное место для возможности чувствовать себя комфортно, быть открытым, доверять, обсуждать идеи и черпать вдохновение друг у друга.
Правила участников команды
В команде существуют правила, благодаря которым команда существует и остается командой. Рассмотрим основные:
Плюсы и минусы командной работы
У командной работы есть свои преимущества и недостатки. О преимуществах мы уже говорили, а недостатки не упоминали. Соберем теперь вместе плюсы и минусы.
Преимущества командной работы:
Есть у командной работы и недостатки:
Специалисты ManGO! Games могут сформировать факторы успеха для командной работы в вашей компании, разработать тренинги, а также укрепить командный дух в ходе деловой игры. С примерами работ можно ознакомиться в портфолио, а с нашими тренерами – на ютуб-канале.
Что такое настоящая команда
В команде участники помогают друг другу, а не как тут.
скачать видео
В организации, выстроенной как команда, интересы руководства и сотрудников – общие. Руководитель и сотрудники – не враги.
Если у вас у кого есть хорошая семья, то команда – это самая лучшая на свете семья. Все дружат, все любят друг друга, все помогают. Кому вынести ведро – не вопрос, кто сейчас идет, тот и выносит. Кого назначили – тот по расписанию и выносит. Кто-то может кому-то помочь – тот рад этой возможности.
В команде принята открытость, здесь можно спрашивать и ответам здесь можно доверять. В команде меня не обманут. Мои коллеги – честные люди, за их словами нет двойного смысла, подставы не будет.
В команде люди доверяют друг другу. Контролировать работу каждого здесь не нужно, в команде понятно, что люди сюда пришли работать, а не отлынивать. Своих нужно поддерживать, а не контролировать. За ошибки не бьем. За ошибкой видим недостаток опыта и умений: поэтому не ругаемся, а поддерживаем и учим. Пишем для памяти, а не для защиты. Не нужно все фиксировать письменно, доказывая свои слова: тут говорят правду.
Вхождение в хорошую команду нового руководителя
На работе очень желательно научиться делать команду для того, чтобы научиться делать отличную семью дома. И дома, тренируясь и создавая отношения в семье, эти навыки переносите на работу. И тогда вы везде органичны, одно поддерживает другое, и нет разницы – вы на работе ли, дома ли – обстановка одна и та же.
Один в поле не воин. Путь до эффективной командной работы
Команда — это группа людей, которые вместе двигаются к общей цели, распределяют между собой задачи и ответственность за конкретный результат. Команды создаются, чтобы решать задачи, которые один человек выполнить не сможет. Эффективная команда достигает цели за минимальный срок с минимальными затратами.
Собрать несколько человек и сказать: «Теперь вы команда, ждем от вас результата», не получится. Людей нужно организовать, дать им вменяемую цель, мотивацию и решать возникающие проблемы.
Как раз об этом расшифровка доклада Евгения Федореева на TeamLead Conf. В докладе Евгений поэтапно описал процесс организации эффективной команды разработки в Banki.ru: про найм, общение, обмен знаниями и развитие разработчиков и тестировщиков внутри коллектива и отдела.
Что такое Banki.ru?
Контекст компании, чтобы знать, о каком опыте пойдет речь. Banki.ru — это крупнейший независимый финансовый портал Рунета с ежемесячной аудиторией больше 8 миллионов уникальных пользователей.
В IT-отделе работает 50-70 человек, поделенных на 7 команд разработки. Вся разработка ведется in-house, удаленных разработчиков нет, поэтому в соответствующих процессах и метриках нет необходимости.
Основная задача команды разработки
Когда готовился к докладу, я задавал людям вопрос:
— Какая цель у команды разработки?
— Разрабатывать.
— Что это значит? Если человек сидит, рефакторит, не приносит пользы, не решает бизнес-задач — это тоже разработка?
— … Нужно эффективно разрабатывать.
Эффективность разработки
Понятие эффективности для менеджера одно, а для разработчика другое.
Для управленца эффективная разработка — прогнозируемая: когда известна дата релиза фичи или срок выполнения задачи, чтобы провести какие-то бизнес-мероприятия.
Для разработчика — это работа с техническим долгом. Это одна из болей, так как на работу с тех. долгом, на рефакторинг, на исправления и улучшения дается очень мало времени.
Следующий критерий эффективности — минимальное количество багов. Можно было бы написать, что критерий — полное отсутствие багов, но мы знаем, что такого не бывает. Кроме того, обидятся тестировщики, ведь они будут не нужны.
Заделы на будущее. Я специально не написал «продуманная архитектура». Заранее углубляться и продумывать архитектуру — зло, поэтому в разработке должен быть задел на будущее, но без фанатизма.
Любой другой критерий, который есть у каждой команды.
Процесс разработки
Строить процессы разработки в Banki.ru мы начали после того, как компания стала развиваться и расти. Появились новые партнеры и проекты, и 6-9 backend-разработчиков не хватало. Мы пришли к тому, что нужно выстроить процесс разработки и формализовать его, для эффективной работы.
Изначально у нас было 3 команды, в каждой по 3 бэкенд-разработчика и менеджер, который отвечал за части сайта. Backend-разработчики, кроме своей работы, еще верстали и подключали jQuery-плагины, так как в тот момент на фронтенде было мало людей.
Мы взяли двух фронтенд-разработчиков и еще двух тестировщиков, чтобы жить без багов и считали, что этой конфигурации будет достаточно.
В идеальном мире процесс разработки должен выглядеть так.
После обновления схемы, мы решили, что все круто и стали по ней работать — проводили планирование спринтов, а бэкенд-команды сами ставили задачи в план. Поработали 2 месяца и поняли, что что-то не так.
Наша схема трансформировалась. Задачи прыгают, как мячик в пинг-понге: от QA к фронт и бэк разработчикам, и даже долетают до менеджеров.
Стрелочки занимают много времени — процесс доставки задачи на боевые сервера слишком длинный. Нас это не устраивало. Мы хотели минимизировать количество стрелок, чтобы задачи выполнялись быстрее.
Как сократить время доставки?
Первое, что пришло на ум — задать вопрос о том, почему мы возвращаем задачи? Почему бэкенд, фронтенд и QA понимают задачу по-разному? Почему взгляды различаются? Мы пришли к тому, что нашли виноватого в менеджере проекта, что он описывает задачи не полностью, и сказали PM описывать задачи полнее, чтобы всем понимать, что имелось в виду.
Планированием у нас занимались три бэкенд-команды. Мы привлекли к планированию тестировщиков и фронтенд-разработчиков, но на 3 команды было всего 2 фронтенд-разработчика и 2 тестировщика. Часто звать их не получалось, потому что кому-то надо работать.
Поделили задачи отдельно на frontend и backend, чтобы отдавать их в разработку параллельно, быстрее тестировать и не ждать всю цепочку.
Мы попробовали все решения. В результате время сократилось, но все равно нас не устраивало.
Мы думали, что делать дальше. На рынке много компаний и практик, и мы стали изучать, смотреть, копать и дошли до feature-team.
Feature-team
Это когда в команде есть все полный набор людей для выполнения задачи:
Проблемы feature-team
На тот момент у нас появилось 6 проблем.
Bus-factor
Изначально каждая команда состояла из фронтенд-разработчика, тестировщика и трех бэкенд-разработчиков. Мы взяли в штат дополнительных фронтенд-разработчиков — продублировали роли.
Ввели еженедельные встречи по направлениям. Фронтенд-разработчики собирались отдельно каждую неделю и обсуждали новые технологии, решение задач и договаривались об общих практиках и подходах. Тестировщики тоже собирались, совещались, решали, как тестировать, обсуждали автотесты.
Фронтенд-разработчики ввели кросс-командное code-review, когда один разработчик решает в одной команде задачу и отдает ее на review в другие команды, и после минимум двух утверждений задача идет в тестирование.
Добавили автотесты. В команде был один тестировщик и продублировать его не получалось, так как задач на такое количество не было. Мы договорились о помощи тестировщика из другой команды: он будет присматривать за задачами соседней команды, и подменять сотрудника, который уходит в отпуск. Это немного увеличило время, но задачи проходили тестирование.
Долгое планирование
Мы разбирали задачи на планировании. В момент спринтов все работали и кодили, а на планировании чуть ли не в первый раз открывали задачи и разбирались, что надо делать, тестировщики уточняли «definition of done», чтобы понять как тестировать задачу.
Процесс отнимал много времени. Мы решили разбирать задачи до планирования: предложили разработчикам посмотреть задачу в свободное время, задавать вопросы, чтобы на планирование приходить подготовленными.
Мы предложили менеджерам описывать задачи подробнее, но не слишком, чтобы не закопаться в тонне документации.
Мы целенаправленно выделили на дополнительные груминги час а не в свободную минутку. Собирались всей командой, обсуждали задачи и на планирование приходили подготовленными.
Незакрытые спринты
Это боль. Может у кого-то они закрываются, а у нас на тот момент — нет.
Мы решили сократить емкость спринта с 10 рабочих дней, до 8-ми. Думали, что будем планировать на 8 дней, а 2 дня оставим тестерам.
В реальности оказалось, что когда разработчик видит меньше задач, то он их и выполняет неспешно. На 20% меньше задач в спринте ничего не дали.
В начале спринта, пока есть время, тестировщик составлял тест-кейсы. В теории, в начале спринта, пока разработчики работают, у тестера нет задач. Мы договорились, что в это время тестировщик может пройти все задачи, составить тест-кейсы, а когда задача придет на тестирование, — он прогонит ее по подготовленным тест-кейсам, и сократит время на тестирование. Глобально это не помогло, хотя время немного сократилось.
Сокращение емкости спринта и загрузка тестера не помогли и мы думали, как все-таки решить проблему. В тот момент нам на глаза попалась книга про цель и несколько практик Максима Дорофеева. Мы поняли, что впихнуть «невпихуемое» не получится и стали планировать спринт от узкого места — от тестирования. На планировании тестировщик ставил оценку, емкость спринта рассчитывали от него, и набирали задачу в спринт под тестера.
Класс! Мы пошли к менеджерам продавать эту идею:
— Мы решили планировать от тестеров. Спринты будут закрываться, будет круто!
— Подождите, а что в этот момент будут делать свободные разработчики? Задач будет меньше, у них появится свободное время!
— Ты хочешь, чтобы спринты закрывались, чтобы разработка была прогнозируемая или главная цель людей занять?
— Нет, все-таки прогнозируемая разработка. Давайте спринты закрывать.
После диалога одна команда стала работать по-новому. Схема показала свою живучесть, мы по ней работали, закрывали спринты и у разработчиков оставалось время.
Оказалось, что разработчики могут делать очень много дел, когда они свободны.
А именно: работать с тех. долгом. В команде всегда есть общий тех. долг на отдел. Эти задачи можно брать в работу и тестировать. Как правило, тех. долг — это системный рефакторинг. Для этих задач нужно проводить регрессионное тестирование, и не всегда это должен выполнять тестер команды. Отдел тестирования выделил специальных тестировщиков, которые проводили регресс, в том числе и руководитель отдела тестирования. Задачи по тех. долгу отдавались в тестирование другим сотрудникам и наши тестировщики не страдали.
Разбирать задачи из backlog и уточнять требования. Когда у разработчика не было задач, он смотрел backlog, уточнял требования. К моменту планирования задачи полностью описаны, все вопросы заданы, а решения приняты. Осталось уточнить детали и все — тестер оценивает, и задача пошла.
Помогать другим командам. В тот момент у нас еще практиковалась помощь другим командам, в которых аврал, кто-то в отпуске или заболел, а проект горит. Обособленные частные задачи можно брать и помогать другим командам.
Кроме того всегда есть отпуска, обучение, участие в конференциях, на которые тоже надо выделять время, для подготовки. Когда сотруднику в рабочее время дают возможность что-то изучить, почитать Хабр, посмотреть видео по работе — лояльность повышается. Мы эту проблему решили, и всем стало комфортно.
Разный характер задач у команд
У нас есть продуктовые команды, которые делают что-то новое. У них двухнедельное планирование, спринты, длинные проекты и к релизу они приходят через 1-2 месяца или больше.
У нас есть маркетинговые команды, которые работают более реактивно: пришла задача — сделали, пришла задача — сделали. Допустим, коммерческий отдел продал лэндинг — надо его быстро сделать. Эти команды первоначально тоже работали по Scrum и двухнедельным спринтам, но получалось, что в конце спринта задачи совсем другие, чем в начале. Неудовлетворенность команды, постоянный аврал, спринты не завершаются — ситуация неприятная.
Мы решили поговорить с PM и с бизнесом:
— Ребята, у нас Agile, Scrum, спринты, процессы — давайте не будем вкидывать новые задачи, а будем прогнозируемо разрабатывать.
— Смотрите, мы продаем лэндинг, его надо сделать через 3 дня. Нам за это платят миллион. Какие процессы? Деньги надо тоже зарабатывать!
Миллион нас убедил. Мы стали думать дальше.
Решили сократить спринты до недели — так мы сможем быстрее реагировать. Тоже не пошло, потому что планировать в тот момент для этой команды совсем не получалось.
Дальше решили не планировать спринты, а работать по Kanban вместо Scrum: пришла задача, взяли в работу, выпустили. Это сработало. Команда работала продуктивнее, потому что изначально понимала, что планирования нет, а есть только задачи на выполнение.
Чтобы улучшать процессы в команде и получать обратную связь, мы стали проводить ретроспективы каждые 2 недели: команда собиралась, обсуждала, что прошло хорошо, что нет, какие плюсы и минусы, и работали с этим.
Появление новых команд
В тот момент мы начали расти, у нас появлялись новые команды: приходит тимлид, разработчики, команда обрастает, а люди между собой еще не притерлись. В этот период о планировании не говорим — люди в первый раз видят наш код, а он может быть и плохим, например, у нас есть чуть-чуть Битрикса. Что-то с этим надо было делать
Можно было взять тот же Kanban, чтобы разработчики выполняли задачи, как могут, но это продуктовая команда, ее надо учить. Мы решили — пусть они учатся планировать и оценивать задачи, но сократили спринт до 1 недели.
Увеличим время до 2 недель через 1-2 месяца, когда команда притрется, войдет в общую продуктовую работу, наладит процессы и разработчики смогут нормально оценивать задачи.
Обмен опытом между командами
Внутри команды разработчики и тестеры общаются между собой и обмениваются опытом, но этот опыт не обновляется, потому что команда «варится в себе». Новому опыту неоткуда взяться.
Мы стали думать — что с этим делать, и ввели еженедельные встречи тимлидов. Цель встреч — перенести опыт от одной команды к другой через тимлидов.
Первые встречи проходили так:
— Здравствуйте, меня зовут Евгений, мы сейчас пилим новости.
— Круто!
— Здравствуйте, меня по-прежнему зовут Евгений, мы продолжаем пилить новости.
— Ок.
Ничего неординарного не происходит.
Третья встреча: Здравствуйте… И все то же самое.
Мы поняли, что надо менять формат. Почитали книги о проведении совещаний и
ввели фиксированную повестку.
Теперь у нас есть wiki-страничка с датами проведения тимлидских встреч, в которую в течении недели набрасываем проблемы и задачи для обсуждения.
Плюсы такого решения
Мы ввели кросс-командное code-review. Это некий обмен опытом, который уже практиковали фронтенд-разработчики, а позднее и ребята из бэкенд. Отдавать весь код на кросс-командное code-review не обязательно, достаточно только важных вещей, например, общие библиотеки или общие куски кода. Дляcode-review мы выбирали только заинтересованные команды, не было обязательного approve.
Возникают ситуации, когда соседняя команда, которая занимается банками, просит доработать функционал — добавить поля, а мы занимаемся кредитами.Можно попросить другую команду, но у них свой план и непонятно, когда они выполнят просьбу, а ждать нельзя. В такой ситуации мы помогаем соседней команде, но на code-review отдаем другой.
Бывает так, что разработчики просят перевестись на другое направление или сменить технологию. Например, у нас один сотрудник год занимался кредитными картами и просит сменить область, а другой хочет поменять технологию с UI на Symfony. По договоренности мы организуем переход разработчиков между командами.
Некоторые компании практикуют встречи по пятницам: люди собираются для обмена опытом, что-то обсуждают, рассказывают. Мы тоже решили организовать пятничные посиделки — завели страничку в Wiki, где каждый, кто хочет выступить, пишет тему своего доклада.
Все было круто. На посиделках команды рассказывали, чем занимаются, что нового. Например, с одной из команд у нас возникло непонимание, никто не знал, чем она занимается. На пятничной встрече команда рассказала про свою работу, показала аналитику и все поняли смысл их работы. Фронтенд-разработчики рассказывали как происходит сборка, обсуждали общетехнические темы, например, как пользоваться Debugger’ом в PHPStorm, как происходит деплой.
А потом темы по разработке закончились, мы перешли на психологические и история стала угасать. Как дальше простимулировать разработчиков что-то рассказывать?
И тут мы вспомнили про KPI! Давайте каждого разработчика научим выступать и включим в его KPI 2 доклада за полгода на пятничных посиделках. Мы думали, что идея крутая и все будут выступать.
Оказалось, что после введения KPI, разработчики перестали делать доклады. К обязательным выступлениям возник негатив. Программисты решили пожертвовать 100% выполнением KPI, лишь бы не делать добровольно-принудительные доклады.
Выводы
Принципы эффективной команды
Каждый член команды — самостоятельный сотрудник.
Мы учим людей выполнять задачу полностью. Например, когда у человека не хватает требований или доступов, мы хотим, чтобы он мог найти эти данные сам: пойти к админами, к PM, попросить логин или пароль.
Задача должна быть сделана одним человеком — если ты взял ее на себя, то должен довести до конца.
Бывали случаи, когда разработчик говорит:
— У меня нет паролей на интеграцию с партнерами.— ОК, напиши письмо или скажи PM.
Сказал PM и опять сидит день или два.
— Вася, что случилось?— Я PM написал, а пароля все нет.
Мы пришли к тому, что человек должен дожимать, чтобы как можно быстрее получать необходимые данные.
Важно общение внутри команды. Меньше формальностей.
Так как мы все работаем в одном офисе, важно минимизировать формальности внутри команды. Есть инструменты вроде Jira или Slack, которые помогают общаться с удаленными работниками по интернету, а у нас люди общаются между собой лично, решают и обсуждают проблемы сразу. Мы даже ушли от еженедельных Scrum-митингов, потому что они не нужны.
Когда у нас появляется проблема, мы ее сразу обсуждаем и решаем.
Тимлид поддерживает единство в команде.
Тимлид следит за настроением в команде и решает проблемы. Например, у нас один разработчик работал год. Мы заметили, что команда перестала с ним общаться. Человек сидит, что-то делает, а к нему никто не подходит — это уже сигнал, — что-то не так. Когда люди создали внутри команды чат для обмена сообщениями, сигнал вопил как пожарная сигнализация. Разработчик спрашивает:
— А что происходит?
— Мы в командном чатике общаемся!
— Меня туда добавьте!
— А у тебя не Айфон, мы в iMessage!
После этого я пошел к директору по разработке и сказал, что надо что-то делать: команда демотивирована, классный специалист не может работать.
Мы перевели его в другую команду, и всем стало лучше: взяли нового разработчика, который влился в команду, а предыдущий нашел себя в новой команде, проработал 2 года, и получал хорошие отзывы от тимлида.
Тимлид защищает команду от «внешних факторов».
Тимлид — это фильтр, который решает какую информацию извне допускать в команду, а какую нет.
Объясню на примере. В отделе маркетинга или в руководстве, всегда «лучше»знают, сколько времени уходит на разработку — им друзья рассказывали, что у себя фичу запилили за месяц, а наши полгода делают. Руководству не объяснить, что у нас куча подводных камней, которые решаем, но быстрее не можем. Когда такая информация доходит до команды, часть разработчиков демотивируется, уходит в себя.
Будьте фильтрами между внешней средой и командой. Всю информацию надо дозировать, чтобы не демотивировать разработчиков.
Сбор программы TeamLead Conf, которая пройдет 25 и 26 февраля в Москве, в самой жаркой стадии. О результатах расскажу здесь, когда уже все будет привязано к расписанию, а в рассылке будут приходить регулярные тематические подборки.