Адель Шигабутдинов

Сеньор помидор. Бложек ведущего разработчика и тимлида, трансформировавшегося в менеджера проектов :-)

В августе 2016 года на одном из проектов установили ограничение Work In Progress равное количеству девелоперов работающим над проектом. Т. е. если кто-то заболевал или уходил в отпуск, ограничение Work In Progress уменьшалось на единицу. При добавлении разработчиков, увеличивалось на единицу.

На скриншоте Control Chart в Jira и эффект от внедрения данной практики:

Rolling avarage дней между «взято в разработку» и «готово к релизу» (конкретно на этом проекте даже выкачено на продакшен) снизилось с 7.4 дней до 2.7 дней.

То есть бизнес стал получать свою функциональность в два раза быстрее.

Недавно проводил мастер-класс новой проектной команде по Канбану и WIP:

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

Частая картина в девелоперских командах:

  1. Программист взял Задачу 1 в разработку
  2. Отправил Задачу 1 на тестирование
  3. Тестер приступил к тестированию через 5 часов
  4. Программист пока взял Задачу 2
  5. Задача 1 вернулась с багом
  6. Программист решает закончить Задачу 2
  7. Через 3 часа программист отправляет Задачу 2 на тестирование
  8. Программист возвращается к доработке Задачи 1
  9. Через час исправляет баг и отправляет Задачу 1 на тестирование
  10. Через 2 часа Тестировщик приступает к тестированию Задачи 1
  11. Задача 1 отправляется в релиз

Итого время простоя задачи
на пункте 3: 5 часов
на пункте 7: 3 часа
на пункте 10: 2 часа

Проблемы бесконтрольного набора задач:

  1. Задача долго отлеживается, перед тем как её возьмут на тестирование, потому что тестировщики заняты тестированием других задач
  2. Задача долго отлеживается после возвращения на доработку, потому что программист пока ждет результатов тестирования, взял себе на разработку уже другую задачу, и пока ее не закончит, к доработкам вернувшегося тикета не приступит.

Как итог: куча полуфабрикатов, недоделок, незавершенных задач — одним словом, связанный капитал: время и деньги на разработку потрачены, а результата нет.

Так вот, в моих командах, процесс устроен следующим образом:

  1. Ограничение WIP = кол-во девелоперов на проекте
  2. Пока программист реализует задачу, тестировщик ждет: читает хабр, доки, занимается планированием собственной работы, какими-то улучшениями, общением с аналитиками по задачам в разработке
  3. Как только задача готова, тестировщик принимается за ее тестирование.
  4. Программист находится в активном ожидании обратной связи от тестировщика и читает хабр, документацию, занимается самосовершенствованием, помогает тестировать
  5. Как только задача возвращается на доработку — берет ее в ту же минуту и быстро исправляет недочеты. Это легко, т. к. программист находится в контексте задачи и прекрасно помнит что именно где править
  6. Как только задача завершена, тестировщик в ту же минуту проводит повторное тестирование, и если все ОК, отправляет в релиз.

Как результат:

  1. минимальное время на реализацию задач
  2. минимальное количество задач погрязших в болоте доработок
  3. у программистов и тестировщиков есть время на саморазвитие
  4. бизнес подразделение довольно: новая функциональность начинает приносить деньги сразу же, а не «через 2 недели, когда будет релиз»

+ Полезное из переписки на facebook:

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

3 мая 2017, 11:55

Про скрам

Возни много, все потеют, а к забитым голам отношения никакого.

28 апреля 2017, 10:33

х

Вот какая мысль мне пришла о несоответствии выпускников ВУЗов с требованиями на работе. К нам приходят бакалавры и магистры, а мы ждем инженеров.

В итоге выпускник ВУЗа тратит несколько лет на то, чтобы в бою освоить:

  • Объектно ориентированное программирование
  • Паттерны проектирования ООП
  • Работу с реляционными базами данных
  • Работу с не реляционными базами данных
  • Несколько фреймворков
  • Несколько ORM
  • Базовые функции операционных систем
  • Основы администрирования серверов
  • Опасные баги
  • Способы решения каких-то нетривиальных задач
  • Системы контроля версий
  • Технологический процесс производства ПО
  • Пару методологий ведения проекта
  • Как выяснять требования
  • Как тестировать
  • Как рефакторить
  • Как работать в команде

И дальше уже ставший инженером, идет дальше работать, развиваться, приносить пользу себе, работодателю, миру.

Я очень люблю умных ребят. Огромное уважение вызывают те, кто умеют сходу оценивать O-сложность алгоритмов, разбираются в структурах данных, вообще с хорошими скиллами в Computer Science. Но на практике же большинство этих скиллов в решение повседневных задач практически и не применяются. Опыт решает.

Такие дела.

22 апреля 2017, 22:55

Иннополиса ребят пост

В этом году университет Иннополиса выпускает вполне себе умных, живых и интересных ребят. Удивляет, что много ребят из Казахстана, Сибири, Москвы, а из Казани, наоборот, совсем немного. По крайней мере из тех, кто до меня дошли.

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

Фото сделано при выходе из междугороднего автобуса в 8:55 21 апреля 2017 г.
Когда еще снегопад за неделю до майских праздников увидим? :)

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

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

http://www.mann-ivanov-ferber.ru/books/kanban/

Иду я между рядами всяких технологических стартапов, а там паренек одиноко стоит грустит с  фигурками отпечатанными на 3d принтере. Чего, говорю, делаете? Вот говорит берем оригинальные фигурки, сканируем смартфоном и потом можем их напечатать, например.

Достает обычную сони иксперию, запускает их какую-то аппу, которая в «панорамном» режиме снимает селфи. Потом приложение 5 минут думает и выдает вот это:

https://www.astrivis.com/scan3d/viewer/xfS04yh59mdRTcjdK2gtBw== (можно покрутить мышкой)

24 февраля 2017, 23:07

Инструментов второй пост

Созрел пост об используемых инструментах. В этот раз не о программах, а об организации.

1. Trello вместо Wunderlist

Списки дел неудобны т. к. не отражают прогресс выполнения
В трело у меня доска на 5 колонок:
куча | сделать | в работе | жду ответ | сделано

Пробовал сделать шкалу прогресса выполнения 20% 40% 60% — как-то не зашло. Слишком много ресурса отбирает оценка готовности. Зачет/незачет проще и быстрее.

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

2. Список коммуникаций за день

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

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

3. Матрица принятия решений, когда все не так однозначно

Что будет если ДА Что не будет если ДА
Что будет если НЕТ Что не будет если НЕТ

Составляется перечень результатов, получаемых при принятии того или иного решения.
Дальше все получаемые результаты взвешиваются и принимается наиболее выгодное решение.

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

4. Диаграммы последовательности

Это мой любимый инструмент уже много лет

Позволяет описывать последовательность взаимодействия различных сторон какого-либо процесса. С программированием вообще не связано, можно в этих диаграммах хоть сказки описывать.
Легко рисуются на доске, листочке, Visio с комплектом UML или специализированных инструментах.

5. Загрузка правого полушария

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

Ссылки:

Гугл выпустил сервис https://quickdraw.withgoogle.com/

Рисуешь, а он угадывает что это.

Иногда не угадывает, но чаще все-таки да.

4 декабря 2016, 17:13

On demand maniac support

Когда обратная связь от наших технарей ну очень быстрая :-)

Ctrl + ↓ Ранее