Анализ дня: парный дизайн

    Сегодня попробовал описанный вчера подход с задачей дня. В принципе неплохо сработало. Задачей дня я выбрал собственно то, что не успел во вторник - создать диаграмму конвейера сборки, который станет основой continuous delivery на нашем проекте. 

    День как специально выдался в лучших традициях релизного дня: постоянные отвлечения, срочные вопросы и прочее. Т.е. часам к 4-м я понял, что начинаю пролетать со своей задачей дня. Опять ничего не сделаю. 

    Не знаю, что в конце-концов решило ситуацию, то что мозг имел установку на определенную задачу или просто повезло, но мозг сразу же начал искать выход из этого тупичка. Как включится в задачу несмотря на постоянные помехи и решить ее? Собственно то, что мне предложил мозг было достаточно неожиданно: использовать подход парного программирования для решения этой чисто дизайнерской задачи. Я попросил помочь товарища и, в результате, мы смогли за два часа обсуждений и черканий в тетрадке выкатить решение устроившее нас в большинстве аспектов. 

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

• перестал убеждать себя о необходимости вникнуть в таску, поскольку рядом сидел человек, который уже ожидал от меня конкретных действий и решений;
• меньше отвлекался, поскольку другие, увидев рядом со мной другого человека, решали подойти позже;
• подействовал принцип объяснения: одной из причин откладывания задачи с моей стороны была сложность понимания, что в ней первичное, что приоритетное. Пока рассказывал, все сложилось в картинку;
• банальное: две головы лучше одной.

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

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

    Всем доброй ночи.

Анализ дня: задача дня, бранчи и снова бранчи

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

    Сегодня был достаточно продуктивный день. Я зачеркнул много задач в своей тетрадке. Правда есть и один, существенный, минус. Уже вечером подбивая итоги дня понял, что основная задача дня так и не была решена. Мне нужно было составить планы и диаграммы работы конвейера, а я этого так и не сделал.
    Потом пока пел дочке колыбельную, придумал себе концепцию "задача дня". Сейчас каждое утро я выписываю в отдельную тетрадку задачи, которые хочу сделать в течении дня. В принципе они не равноценны, но особых приоритетов я не ставлю. Вот это и буду в себе исправлять. Завтра и все последующие дни буду выбирать одну задачу, которую должен буду решить. Все остальные задачи можно подвигать ради только этой одной. Успехами данного мероприятия обязательно поделюсь.

    Вторая тема более практична.
    На проекте, как и у всех, у нас есть транк (основная ветка) и бранчи, созданные по разным причинам. Один из этих бранчей называется stable. Работа строится следующим образом: две недели набиваются фичи в транк, после чего готовые вещи интегрируются в ветку stable и мы еще неделю тратим на стабилизацию данной ветки. После стабилизации собирается клиентский билд и прямо из ветки идет обновление сервера.
    Естественно скрипт обновления сервера работает по head ревизии и естественно, если кто-то во время стабилизации stable случайно дернет этот скрипт, то всем поплохеет.
    Собственно, чтобы обезопасить себя, неделю назад добавили ветку stable_candidate. Расчет прост - стабилизация билда идет в новой ветке, а потом по готовности все это интегрируется в stable. Но не все идет так как хочется. После недели терзаний и мыканий поняли, что все равно остается открытым два критичных вопроса:

1. То что стабилизировали stable_candidate, не гарантирует что stable будет рабочим после интеграции
2. Некоторые фичи и процессы просто невозможно протестировать в stable_candidate. Соответственно возвращаемся к исходной проблеме - stable ветка какое-то время все равно будет в неопределенном состоянии

    Решение пришло одновременно двоим и оно до банальности простое. Новый бранч нужно делать не до стабилизации, а после.

    Всем доброй ночи

Kanban vs Scrum

Привет всем. 

Сегодня тема не совсем соответствует названию сайта, но я думаю что с автором мы договоримся. 

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

Для начала посмотрим, что нам говорит Вики по поводу канбана. 

Канбан (камбан) — система организации производства и снабжения, позволяющая реализовать принцип «точно в срок».

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

Вот ссылочка на книгу: Scrum и Kanban: выжимаем максимум от Хенрика Книберга и Маттиаса Скарина. Книга на русском и помогает сделать первый шаг в понимании того, что такое канбан. 

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

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

Например у нас есть команда: 5 программистов. Ставим ограничение на количество задач в 9. Дальше у нас есть проект с набором задач, количество которых конечно же огромно. Лид (продюсер, владелец продукта) выбирает первые 5 задач и программисты начинают работать над ними. И вот по каким-то причинам они не могут закрыть ни одну из задач, тогда программист, который заблокирован приостанавливает свою задачу и берет новую у лида. Таким образом в работе оказывается уже 6 задач. Если у команды накапливается 9 незакрытых задач, то она больше не может брать новые задачи, а должна во что бы то не стало закончить хотя бы одну из уже взятых задач. Такой подход позволяет увидеть проблемы проекта очень быстро, поскольку мы обязаны завершать все задачи, чтобы получать новые и если где-то образуется затык, то вынуждены его исправлять, а не откладывать на будущее. 

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

Когда же такой подход наиболее приемлем? На каком проекте или на какой стадии проекта?

Я для себя нашел как минимум один тип проекта, когда можно применять такой подход. Это багафикс. Многим из вас наверное приходилось работать на проекте в период багафикса и вы знаете, что скрам при багафиксе работает не очень хорошо. Основная проблема для скрама - это отсутствие фиксированного объема работы, которую можно оценить и взять на спринт. Ситуация меняется каждый день, приходят задачи, которые нужно сделать вчера, начальству плевать на ваши попытки объяснить "что спринт и скрам и вообще..." и весь спринт летит к чертям.

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

Пост получился намного больше чем планировал изначально, но как-то понесло. Написал прямо на одном дыхании. 

Единственное, что упустил, это слабые стороны и недостатки канбана. Оставлю это вам и буду рад услышать ваше мнение. 

Всем доброй ночи.

Agile первая попытка

Сегодня составляли спринт бэклог на 2 недели. Потратили 3 часа, но все таки сделали.
Самая большая проблема это заставить людей активно работать. Половина команды согласна работать по тем планам и срокам, которые сделаю я. Не зависимо от того сколько это займет в реальности.
Что это? Нежелание учится чему-то кроме программирования? Отсутствие понимания что все вместе отвечаем за результат? Или же нежелание принимать на себя хоть какую-то ответственность, чтобы потом можно было говорить, мол это не я виноват, это лид дал нереальные сроки?
С другой стороны опыта проведения таких митингов у меня с гулькин нос. Возможно не смог донести важность этой работы? Может сам до конца еще не понял сути Agile и еще нужно учится мне?

Вопросов как всегда море. Будем искать ответы.

Всем доброй ночи.