Agile *

В очередной раз столкнувшись с проблемой сбора денег, мы решили посмотреть, какие существуют готовые решения на рынке. Провели анализ существующих продуктов, выявили их недостатки и решили сделать свой продукт (ведь в IT свои "велосипеды" всегда ближе).

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

Эту самую картинку наш технический директор подкладывал в каждую презентацию с комментарием: «Я хочу, чтобы вы были как они.»

Приветствую, дорогой читатель.

В атмосфере взаимодействия гибкости и тесного взаимодействия (на буржуйском — Agile и DevOps) присутствует такое понятие, как Continuous Learning. По сути общая идея заключается в том, чтобы признавать простой факт: как бы усердно ты ни работал, каким бы профессионалом бы ты ни был — ты всегда можешь быть и делать лучше.

Дабы не вызывать комплекс неполноценности, я взял за правило, что мой КПД — 95%.
Эта цифры взята из потолка, но она дает мне право осознавать, что я достаточно вовлечен в процесс, я пытаюсь выжать максимум из своих возможностей, но всегда есть 5% которых мне не хватает до идеала. Набравшись новых знаний, я пробую снова — но цифры всегда остаются прежними — 95% и ни процента больше.

Однако, каждый раз я задаюсь одним и тем же вопросом — становлюсь ли я лучше?

Меня зовут Илья Китанин, я руководитель группы разработки Cofoundit — сервиса для поиска сотрудников в стартапы. Сегодня я расскажу, как с помощью статистики и принципов agile-методологии максимально эффективно работать со сторонними разработчиками, не переплачивать и не выбиваться из графика.

Это перевод недавней записи в блоге разработчиков Discord. Это тот сервис, который всё больше становится похож на конкурента Slack, хотя и не является его явным аналогом. В общем, хорошая эта штука, этот Discord. Хочется написать про него на Хабре немного.

15 декабря 2016



2016 был большим годом для Discord. Мы выросли из маленького притона в платформу, которую используют 25 миллионов людей для того чтобы играть со своими друзьями в игры (да и не только играть: в Discord, к примеру, ещё в конце 2015-го завалилась вся команда React разработчиков — прим. пер.).

Время не стоит на месте, хотя и не снижает наше желание продолжать вести разработку Дискорд под солнцем. Для достижения этого, наши инженеры ушли в свою лабораторию, чтобы приготовить для вас несколько вкусненьких штучек в грядущем 2017-м.

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

Сегодня гибкими методологиями сложно кого-то удивить: со дня принятия манифеста Agile прошло уже 15 лет, еще раньше мир узнал про Scrum. Это уже обыденность для многих компаний, занимающихся разработкой ПО и кажется, что добавить здесь нечего.

Но при всей популярности Scrum в своей работе и на разного рода семинарах и конференциях временами сталкиваюсь с непониманием его базовых принципов. И все чаще в комментариях на Хабре вижу негативные отзывы: у кого-то не получается договориться с заказчиками о переходе на итерационную разработку, кто-то не может адаптировать команду. Наверно, самый популярный отзыв о Scrum, который можно встретить звучит так: «Мы тратим по полчаса на митинги с нулевой пользой, а потом работаем как раньше, только добавилась головная боль с демо, ретро и планированием».

По мнению экспертов, успешность проекта во многом зависит от личных качеств лидеров и «укомплектованности» менеджмента этими качествами. К сожалению, не всегда эти качества учитываются при формировании менеджмента. Это создает риски и часто приводит к провалу. В данной статье рассматривается типология менеджеров по Адизесу и соответствие этих типов различным ролям в Scrum.

-Я хочу устроить панику, понятно?
-Ты там бойню устроишь, а не панику.
«Большой куш»

В течение уже достаточно долгого времени мне попадаются на глаза посты, статьи и даже целые книги, задача которых — донести до читателя советы о том, как правильно делать Скрам. Все они, в общем-то, однотипны и построены на предположении, что большинство людей некорректно понимают предлагаемые практики, их назначение и важность. В этих источниках активно доказывается, что Скрам все-таки работает, говорится о принятии ценностей, о перестроении мышления на уровне компании, о тонкостях организации митингов и прочих нюансах, которых по итогам каждый раз набирается вагон и маленькая тележка. Судя по всему, проблема действительно существует, ведь даже Кен Швабер и Джеф Сазерленд описывают Скрам как “легковесный, простой в понимании и сложный в овладении” [1]. Но только ли дело в практиках? Может быть, люди не понимают саму суть Скрама? Когда что-то начинает приносить серьезные деньги, то не секрет, что именно прибыль становится путеводной звездой этого корабля. Может быть все эти тренинги, сертификации и спешно переучивающиеся в скрам-мастеров менеджеры проектов затмили собой изначальный посыл? Вполне вероятно. Но так ли это? Данный опус — это попытка взглянуть на проблему под немного другим углом, с точки зрения больше технической, чем какой-либо еще.

Привет, Хабровчане! В статье расскажу про опыт использования систем планирования/управления/взаимодействия, каждой из которых пользовались в компании RedHelper не менее 6 месяцев. Упор будет делаться не на функции систем, а на то, что меняется в команде при использовании инструмента автоматизации.

BaseCamp Trello YouTrack Smartsheet Slack YouGile



В конце — обзор собственного инструмента YouGile, который для нас сегодня оказался универсальным местом планирования и общения. Сначала сделали “на коленке” для себя, с очень простой идеей — Agile Board, где каждая задача это чат. Сейчас запущен для публичного тестирования.

Я давно работаю в стартапах и со стартапами. Тема для меня очень близка, у самого было 5 проектов за 4 года со следующей статистикой: 2 закрылось, 1 был целиком продан большой компании, 1 проект трансформировался в другой. Еще один превратился в небольшой действующий бизнес, а также полностью поменял фокус. По двум проектам привлекались достаточно серьезные инвестиции. Особенно по меркам рунета, порядка ~ 0,5 млн $.

Все любят красивые истории о том как стартап стал “единорогом”, но мало говорят о том чего ему это стоило. Вот именно об этом и будет моя статья — короткое эссе о личном опыте на конкретном примере успешного проекта.

Залп скосил 50 офицеров и 760 рядовых. Французы дрогнули, запаниковали и — обратились в бегство. «Тут дела наши пошли не вполне хорошо», — описывает этот момент битвы официальная французская депеша.

Келли Дж. Порох. От алхимии до артиллерии.

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

Пытаясь как-то спасти положение, активисты Scrum вспоминают, что Scrum — это же еще и framework. Объявляется новая стратегия: “Мы не только Scrum, мы еще и Agile! Мы используем best practices, берем из Scrum только самое лучшее, то, что подходит конкретно для нашей ситуации, а все остальное лишнее и необязательно”. А раз так — “Мы — молодцы и все делаем правильно”.

Дэниэль Д. Гэлорат — президент и исполнительный директор Galorath Incorporated и главный разработчик SEER-SEM, программного продукта по алгоритмическому управлению проектами.

Он считается экспертом в области оценки программного обеспечения и автор книги «Программное обеспечение, оценка и риск-менеджмент» («Software Sizing, Estimation, and Risk Management»).

«Книга помогает определить лучший способ инвестировать в улучшение производительности программного обеспечения.»
— Берри Боэм, автор спиральной модели и COCOMO

Сегодня день рождения одного из отцов-основателей Agile-манифеста — Алистера Коберна. Предлагаю вашему вниманию перевод его выступления на TED про командную разработку.



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

Если вы занимаетесь разработкой ПО или инженерных решений, химической инженерией, биохимией, ваш конечный интерпретатор беспощаден. Если вы проектируете что-то для человеческой аудитории, вам очень повезло, потому что она будет снисходительна по отношению к каким-то вещам.

Про Scrum часто можно услышать фразы вроде «православный Scrum», «мы используем best practices из Scrum» или «что почти всегда остается» от техник Scrum при его реализации.

Говоря это, подразумевают, что Scrum — это некоторая эзотерическая методика, которая неприменима в реальной жизни по той или иной причине. Например потому что «для скрам нужно очень много бабла, а мы должны жить по средствам» или «в Scrum разработчики должны быть супер универсальными, а у нас таких нет». А раз так — делается вывод, что «нужно думать головой», и все нужно делать по-своему. В результате такого подхода в рабочем процессе появляются некоторые улучшения, но в целом ничего не меняется, что еще больше убеждает в том что Scrum — это фантазии не имеющие отношения к реальному миру. Это не так.

История велосипеда — более подходящая аналогия для разработки программного обеспечения.
На недавнем семинаре, посвященном разработке программного обеспечения, мы обсуждали одну известную аналогию гибкой методологии разработки. Если вы когда-нибудь читали книги или посещали курсы по обучению гибкой методологии, то вы, скорее всего, тоже это видели. Хенрик Книберг нарисовал довольно оригинальную и узнаваемую картинку.



Эту картинку не стоит воспринимать буквально. Она рассчитана на то, чтобы показать главные преимущества гибкой разработки над каскадной моделью, а именно по отношению к минимально жизнеспособному продукту (MVP).

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

О том, когда задач больше чем ресурсов на их выполнение, очередь задач со временем увеличивается и часть из них можно смело назвать «дурацкими».

Дурацкая задача – когда ожидаемая от реализации польза не оправдывает количества необходимых ресурсов, но Заказчик настаивает на необходимости её выполнения.

О

• управлении потоком задач на разработку,
  Как избавится от «дурацких» задач?
• управлении расходами на разработку,
  Как определить и выбрать самые выгодные задачи?
• распределении ограниченных ресурсов.
  Как сделать так, чтобы все Заказчики были довольны, а количество ресурсов при этом осталось тем же?

Это вводная статья по теме «Систематизация бизнеса». Общая информация.

В последующих статьях, если данная тема вызовет интерес у резидентов Хабры — будут практические разборы и опыт, коих, за последние 3,5 года накопилось достаточно.

Добавил вступление по совету одного из резидентов, для уточнения, благодарю.

Итак, «продукт» создан, есть какой-то маркетинг и первые сотрудники. Суммы «капают» на расчетный счет, пора расти дальше! И в этот момент, как рефлекс собаки Павлова, у 90% предпринимателей в голове возникает вопрос:

«А почему бы не внедрить CRM систему?»

Пошел процесс… Поиск вариантов… Подрядчики… Amo, 1С или Битрикс 24…

А ведь интуиция сидит на плече и подсказывает: «Мужик. Что-то не так. Как-то все очень туманно в этой автоматизации.»

Пришли ребята-«автоматизаторы», накидали терминов и, усыпив бдительность, установили все так, как видят сами (в лучше случае) или просто скопировали стандартные конфигурации с похожей бизнес-модели на вашу. Даже лучше подойдет глагол — «натянули».



Результат? CRM работает на 30% от своих возможностей, управление «не интуитивно», на все нужны инструкции, многие моменты не совпадают с практикой, сотрудники саботируют.

«Любое дело всегда длится дольше, чем ожидается, даже если учесть закон Хофштадтера.»
— закон Хофштадтера


Самый просматриваемый ролик на YouTube по теме agile. 744 625 просмотров на момент публикации данной статьи. Легкий стиль изложения, картинки и всего 15 минут — лучшее что я видел. TED отдыхает.

Эпиграф. «Критика не принимается вообще, принимается только альтернативное построение. Если оно будет лучше, чем моё, тогда я приму его как более правильное».

Статья написана под впечатлением статьи Мотивация каратистов: как перестать беспокоиться о неэффективных сотрудниках?.

В статье приводится альтернативное мнение о том как можно построить систему бонусов. Частично методика опробована на своей шкуре и показала свою высокую эффективность в прикладной области (не разработка ПО).


^{картинка для привлечения внимания}

Я уже давно хочу поделиться уникальной мотивацией для разработчиков, которую создал и внедрил. Постараюсь рассказать без воды, кратко и по делу.



Данная мотивация позволит не заставлять сотрудников работать, если они этого не хотят. А так же быстро выявить неэффективных сотрудников, которые тянут команду к дну.

Наша команда работает in-house в Москве и Воронеже и удалено по разным городам России. Эта мотивация применима для всех, кто работает в компании full-time, в независимости от местонахождения. Отдельно хочу отметить высокую эффективность в случае работы с удаленными сотрудниками.

На текущий момент, в компании работает больше 10 разработчиков. У нас 10 купонных сервисов, 2 мобильных приложения, агрегатор kupon.ru, ERP-система, рассыльщик, который рассылает более 8 миллионов писем в день, и, совместный проект, аналитический сервис gtmix.ru. Каждый разработчик участвует в 2 и более проектах. Работает it-отдел по SCRUM в Trello. Ежедневные митинги разделены по проектам и проходят в точно назначенное время.

Эффективность разработчика измеряется в баллах. Для удобства сбора результатов, мы используем плагин для trello: Scrum for Trello. Балл формируется из коэффициента скорости команды и времени, затраченного на задачу. Есть простая, наглядная табличка:


Из практического опыта, оптимальный коэффициент скорости команды составляет 1,6. Чтобы вы понимали, это 5 часов работы сотрудника в день или 1 балл. 1 человек/час — это время потраченное на написание кода и обмозгование задачи. Время затраченное на чтение книг, кофе, чай и тому подобное не считается.

Джефф Сазерленд (Jeff Sutherland), военный летчик (совершивший более 100 боевых вылетов во Вьетнаме), cоавтор Agile-манифеста и CEO Scrum.



Здравствуйте!
Сегодня я хочу поговорить о жизни, свободе и поиске счастья — о Великой Американской мечте, которая зачастую так и остается неисполненной. Как сказал поэт Роберт Бёрнс: «Даже самые тщательно выстроенные планы идут крахом и у мышей, и у людей», что не может не вызывать неудобств и психологического дискомфорта, вместо ожидаемого удовлетворения.

Впервые я столкнулся с этой проблемой, будучи курсантом военной академии США. Во время нашего обучения нам пришлось пройти через огонь, воду и медные трубы, а в год перед выпуском меня назначили офицером роты Л2, которой требовалось разрешить проблему со строевой подготовкой, поскольку им предстояло участвовать в военном параде. Рота считалась чем-то вроде аутсайдера, потому что за целую сотню лет они ничего не смогли поделать с уже сложившейся репутацией полной посредственности и расхлябанности. Десятилетия уходили на бесплодные попытки научить их чему-то и заставить тренироваться с большими усилиями.