Наверх ▲

Опыт внедрения Kanban

Антон Марченко Антон Марченко У Антона пятилетний опыт работы с Agile методологиями в разных ролях. На данный момент занимает позицию Head of Customer Care Department в компании TargetProcess, Inc.

Антон Марченко: Добрый день! Меня зовут Антон Марченко. Моя должность звучит сейчас – начальник отдела заботы о клиентах в компании "TargetProcess". Мы – продуктовая компания. 

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

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

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

Отсюда идет, как вы знаете, что много интернет-проектов провальные. В последние 10 лет появился тренд к серии методологий agile. Канбан – это одна из самых молодых методологий. Из реальных успехов, получается – естественно, "Toyota". Я еще расскажу немножко об этой истории. 

Из самых последних удачных примеров: "World of Tanks" (если вы знаете такую игру). Белорусская фирма ее выпустила. С помощью методологии канбан они подвинули "Blizzard" по количеству игроков в онлайн. Поставили мировой рекорд. 

Это из последних успехов. Про agile еще могу добавить, что такие крупные компании, как "Skype", "Salesforce", "Facebook" (частично) используют методологию Scrum. Соответственно, все пытаются ориентироваться на лидеров отрасли.

Небольшой дисклеймер. Я обычно говорю много лишнего. Компания может не отвечать за мои слова. 

Хотелось пару слов сказать о Lean Production и кайдзен. 

Канбан вышел из "Toyota". Когда я изучал тему канбан, прочитал много литературы. Самые известные title – это Lean и кайдзен. Они практически одинаковые: пишут об одних и тех же вещах, но разными словами. Здесь уже конкурирует ментальность американская и японская. 

Когда американцы попытались скопировать успех "Toyota", они назвали это дело Lean (бережливое производство). Успех в основном ориентируется на результат. 

Я обычно рассказываю пример с японской чайной церемонией. Японец может прийти и пить чай в течение получаса. Он будет наслаждаться, что все процессы поставлены очень правильно: тот, кто ведет чайную церемонию, делает все абсолютно правильно. Американца же больше интересует: "Как! Я так долго – полчаса – пил чай?". 

Я буду больше в своем докладе ссылаться на кайдзен именно как на процессы. 

 (Демонстрация слайда). 

Еще немножко истории о методологиях. 

Это Фридрих Тейлор. Он в 1911-м году написал трактат, который послужил вообще основой научного менеджмента. 

В социологии есть три типа менеджмента. Один – это диктатура. Второй – это демократический. Третий – гибкий или смешанный. Как диктат полезен, если мы копаем руду или носим мешки, это было у Фридриха Тейлора. 

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

Это Деминг. Был доклад "14 принципов Деминга в agile", поэтому я пропущу. 

Деминг ввел некоторые демократические признаки в Японии. Он был широко принят японским менеджментом. Повлиял на историю многих крупных корпораций (в частности, "Toyota"). 

Отец "Toyota Production System" Taiichi Ohno (я боюсь ошибиться в произношении) сказал, что та методология, которую они используют, это канбан. 

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

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

Мы делаем методологию, которая нам позволит управлять проектом с помощью сигналов. Где что-то не так, мы сразу заметим.  

Первым, кто заявил о канбан в IT, был Дэвид Андерсон (в 2004-м году). Он сейчас выпустил книжку "Канбан" (в 2010-м). Довольно интересная. 

Хенрик Книберг, известный agile-лист, написал интересную диаграмму. Сейчас мир движется к более адаптивным методологиям. У RUP 120 правил, но довольно сложно сказать, что они лягут конкретно на ваш продукт, который вы разрабатываете, или ваш проект.

Здесь таблица, которая показывает, что в RUP 120 правил, в XP – 13 инженерных практик, в Scrum – 9, в канбане – 3. 

В канбане всего три простых правила. 

Первое. Визуализируй как можно больше. 

Второе. Лимитируй поток. 

Третье. Выпускай как можно чаще. 

Мы были маленькой компаний. Был Scrum классический. Здесь у нас, кстати, Tip Box. Мы пытались на daily standart meeting: тот, кто опаздывал, должен был положить туда 5 долларов. Но практика не увенчалась… До сих пор у нас там много денег, но никто не может делать… 

Примерно в 2008-2009-м году (мы следим за agile-трендами) начали много говорить о канбан и о канбан-бордах. Мы серьезно это не восприняли. 

Мы решили перейти на канбан по двум причинам.

Первая. Недостаточная визуализация процесса. Мы не знаем, что выпустит… Burn dawn чартов нам было недостаточно.

Вторая. Product Owner хотел выпускать релизы: буквально через день определенную фичу. 

Концептуальное отличие Scrum от канбан. 

Scram подразумевает, что у нас будет итерация 40-дневная. Заказчик через 40 дней (фиксированное время), или сейчас двухнедельные итерации принято рекомендовать, получит определенный набор функциональности. 

Был известный анекдот из рекламы. Строительная компания рекламировалась в Америке. Говорили: "Мы делаем быстро, качественно, дешево". Потом звездочка и маленькая приписка: "Пожалуйста, выберите любые две вещи из предложенного". 

Как вы видите на треугольнике, мы фиксируем время, мы фиксируем cost. Мы оперируем тем, какие фичи мы выпустим. Если мы видим, что по времени не успеваем, то мы просто выбрасываем фичи из итерации. 

Но если я спрошу вас, когда выйдет "iPhone 5" или когда выйдет новое обновление "Google Chrome", или когда у "Facebook" будет обновление… Есть тренд, что продуктовым компаниям не принципиально выпустить определенные фичи к какой-то определенной дате. Когда будет готово – тогда будет готово. Канбан не дает определенных сроков: отсутствует время конкретного релиза. Мы оперировали фичей, теперь мы оперируем таймами. 

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

На канбан мы переходили плавно. Мы переходили из двухнедельных итераций в Scrum. 

Здесь картинка, которую я взял из Mary Poppendieck Lean production. Визуальное изображение после того, как мы переходим от двухнедельной итерации к однонедельной. После того, как мы решили перейти, мы не выпустили ничего за неделю, потому что мы наткнулись на подводные камни. 

Например, процесс тестирования занимал у нас три дня. Когда было две недели – непринципиально, занимает это три дня, два дня. Когда у нас однонедельная итерация, сразу всплыло, что мы должны над этим работать, больше автоматизировать. 

Потом у нас был еще технический момент. Мы перешли из SVN на git. С SVN у нас были проблемы. 

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

Команда development хочет, чтобы разработка шла как можно дольше, чтобы можно было использовать успешно TDD/BDD, провести user experience тесты, beta-тесты. 

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

У нас в этом конфликте канбан больше становится на сторону Product Owner. Мы можем выпустить любую фичу буквально через день после того, как ее запустили. Нам из технического момента понадобился git, потому что нам нужно было много вести каждую фичу в отдельном потоке. Мы могли выпустить конкретно эту фичу, не используя merge. 

Я надеюсь, все понимают, что я рассказываю. 

В SVN у нас были проблемы с комитами. Когда мы комитили в Master (в SVN-терминологии это назвалось транк), то у нас почему-то терялись комиты. Это было меньше. Всю команду разработки колбасило неделю, потому что смена синтаксиса, логики с распределенной на нераспределенную. 

Следующим пунктом мы хотели визуализировать как можно больше. Это я часто слышу буквально от всех менеджеров: топ-менеджмент хочет визуализировать. Говорит: "Покажите мне, как у вас идет процесс". 

Мы предоставляем канбан-board, по которому можно увидеть процесс – в каком конкретно (дефект записи) находится та или иная функциональность. 

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

Команда разработки тоже полюбила эти большие мониторы, которые стоят в каждой комнате. 

Так выглядел over view. 

Первое. Backlog только функционируют, которые выполняют проблемы.  

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

Стас Фомин до меня выступал с "MediaWiki". Ему сказали про продукт, что он не "секси". С таким продуктом… Сейчас у нас полно конкурентов: мы должны делать продукты, которые удобны. 

При user experience, естественно, еще модно ссылаться на "Apple", которые делали даже проигрыватели. Когда переключаешь, там нет щелчка. Они поставили специальный динамик с приятным звуком, который будет щелчок. Или "iPhone", который тоже по функциональности – нельзя поменять батарейку. 

Но эти продукты доставляют радость и удивляют. Ими в настоящее время… И мы даже считаем, что продаем продукт, который дороже "Gira", дороже "Bugzilla". Мы успешно конкурируем на мировом рынке. Многие предпочитают нас, потому что у нас удобнее, быстрее, понятнее и лучше дизайн. 

Это полунаучная модель Кано, который изобразил ту же мысль. Если мы будем выполнять только базовые потребности клиентов, у нас клиенты будут не очень довольны. Если мы будем выполнять только request (на русском – "хотелки"), то мы все равно окажемся где-то в середине.

Большинство продуктовых компаний, по моему мнению, должны быть сфокусированы на том, чтобы удивлять клиентов и создавать "вау-фактор": "Вау! Это будет круто!". Клиент будет готов за это переплатить. 

Фокус на user experience, в первую очередь, у нас. Мы учим разработчиков: отправляем на специализированные конференции (в Лондоне последняя была по user experience), чтобы они мало того, что обладали предметной областью, но еще учились, как правильно визуализировать дизайн. 

Вся наша разработка происходит через TDD (Test-driven development). Еще год назад мы попытались внедрить BDD (Behaviour-driven development). TDD – это были больше юнит-тесты. BDD – это больше не как юнит-тесты, а как интеграционные тексты, которые позволяют нам обеспечить качество.

Если кто-то сделает рефакторинг, то мы будем уверены, что это не отломает какую-то другую функциональность. 

Также у нас большинство фич разрабатывается в парах. Мы попытались внедрить в практику, что парное программирование обязательно для всех. Восемь часов в день человек должен программировать в паре, а потом меняться. Внедрялось очень тяжело – директивным методом. Сейчас у нас где-то 50/50.

Если разработчик разрабатывает не в паре, то этот код должен обязательно пройти code review другого разработчика. К сожалению, мы еще не имеем автоматизированного tool, чтобы "чекать" code review.

После coded приступает команда тестирования. 

Крайне важно, чтобы agile, взаимодействие… Чтобы после того, как user story попадет в Coded, прошел какой-то meeting, который будет включать в себя Product Owner, разработчика и тестировщика. 

Желательно, чтобы, как только разработчик закончил разрабатывать функциональность, на нее были уже готовы тест-кейсы, по которым будет прогонять тестировщик (чтобы как можно быстрее). Также имеет у нас лимит пять. 

Процесс тестирования у нас происходит примерно так: на одной user story мы пишем 15-20 тест-кейсов. Причем тестировщик помечает от 3-х до 5-ти тест-кейсов, которые он хочет автоматизировать. Для автоматизации мы используем "Selenium Remote Control", и очень довольны.  

Естественно, все потом "мерджится" в Master с лимитом в 3. 

Зачем нужны лимиты?

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

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

Потом "мерджим". 

О процессе тестирования хотел рассказать. 

У нас на тестирование примерно 2-3 дня уходило. Потом я разрисовал… Построил временную диаграмму, которая показывала, что на идеальный процесс тестирования у нас уходит 4 часа. 

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

У нас было выделено примерно 35 областей, которые плохо заавтоматизированы. Потом ad hoc testing, и мы выпускаем релиз. 

Если где-то что-то не прошло (не прошел юнит-тест или упал какой-то функциональный тест), то все начиналось заново. У нас часто уходило на релиз тря дня. 

Сейчас в лучшем случае… Обычно у нас процесс приемочного тестирования занимает 4 часа. Оговорюсь, если нет с инсталляцией изменений. На инсталляцию я написал quick test professional-тесты. Там примерно 15, но нам нужна была кроссплатформенность. Мы не смогли встроить это в "Continuous Integration", поэтому по-прежнему мы тестируем инсталляционные тесты вручную, а все функциональные и юнит-тесты – автоматически.

Автоматические тесты у нас на "Selenium Remote Control". Мы ими вполне довольны. У нас сейчас примерно 2 тысячи юнит-тестов. Наверное, полторы тысячи функциональных тестов. Они позволяют нам сказать – если что-то изменилось, то мы выпустим релиз с приемлемым качеством. Не беспокоиться и выпускать build примерно раз в неделю. 

Отказались от практически всех метрик. Оставили только lead-time и cycle-time, которые классические для канбан. Lead-time – когда мы добавляем user story в backlog, а cycle-time (start-time) начинается, как только она взяла в разработку. 

Мы пытаемся сократить это время. Желательно все user story разбивать на функциональность как можно меньше. Если можно user story разбить на две, то мы стараемся всегда бить. У нас даже были тренинги специальные, как правильно разбивать функциональность, чтобы делать вещи как можно более минимальными. Соответственно, выпустить cycle-time как можно раньше.

У нас сейчас уходит примерно 5 дней: для багов и user story общее время. От того, как пошло в разработку, и выпустили, происходит 5 дней. Примерно каждую неделю мы делаем релизы.

Хотел еще немного рассказать про наш бережливый офис. Как он вошел…

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

Я у "Toyota" прочитал, кто крайне важно и принципиально, чтобы человек – автор идеи – ее и исполнял. Если я хочу новый коврик в офис, то я подам заявку, и офис-менеджер купит коврик не такой, как я хочу, а я видел какой-нибудь красивый. 

Получается, я вешают идею – "Коврик". Кто-нибудь из топ-менеджмента одобряет. Я иду и покупаю. Потом забираю чек. 

Личные канбан-доски у нас тоже стали крайне популярными. Примерно у трети офиса висит, кто что хочет сделать даже по личному, чтобы не забыть. Крайне удобно. 

Это небольшое фото нашего офиса. 

У всех два монитора комфортные кресла.   

Отдельная тема, на которую я хотел поговорить – это обучение. 

У нас было правило, что каждый разработчик имеет право – 5 часов в неделю он может потратить на все, что хочет. Не совсем на все, что хочет – развивать область, которую он хочет развивать. Он может даже изучать другую технологию.

Прочитал сегодня интересный innovation management: "Google" позволяет разработчикам 20% времени уделять на внутренние проекты. Практика была крайне удачная. Но мы обратили внимание, что не все, к сожалению, тратят время на свое образование. 

Еще одна маленькая ремарочка. В Японии пожизненный найм. Человек приходит в компанию, корпорацию и постоянно в ней работает. Наш современный менеджмент (особенно MBA-щики) считает, что если люди через 3 года не растут или не развиваются, то мы будем работать в окружении полных идиотов.

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

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

На agile-тусовках в Белоруссии аутсорсеры мне говорят: "Как мне (как аутсорс) продать заказчику 5 часов рабочего времени? Это же нереально. Никто не будет". Это тоже один из плюсов работы в продуктовой компании: все смотрят на твое личное развитие. Не нужно продавать время.

Ну, это так. Превьюшки офиса: всех развесили. 

Еще доски повесили. Помазали стену "Idea Pad". Это такая специальная краска – что угодно можно рисовать, но потом посчитали… В другой комнате повесили просто обычную доску. "Idea Pad" получился в 10 раз дороже, так что мы не рекомендуем! Неэффективно получилось (улыбается). 

Дальше у нас есть еще "Continuous Integration". Каждый build крутится в "Cruise Control". 

Девелопер работает над какой-нибудь функциональностью. Там чего-нибудь падает – он комитит, и через 5 минут получит feedback, что упал юнит-тест определенный. 

Еще печально, что об этом будет знать весь офис. Я когда общаюсь с клиентами, и у нас просто "тревога" звенит, у меня спрашивают: "У вас в Минске там война? ". Я говорю: "Нет, у нас Continuous Integration". 

Как только build падает – сразу раздается сирена. 

Мы потом улучшили. Перешли на "Jenkins". Цель – визуализировать как можно больше. "Jenkins" позволяет нам увидеть, что конкретно упало: упал build, упали юнит-тесты, упали юнит-тесты на плагины или функциональные тесты. 

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

Это небольшое отступление про мотивацию.

У нас упал один юнит-тест. Попытались стимулировать его фикс – повесили 10 долларов. Но никто не попытался из разработчиков, никто не дернулся. Я попробовал, конечно, но не получилось (улыбается). 

Из нашего опыта: денежная мотивация не прошла. Когда еще был Scrum, пытались сделать 300-400 долларов для разработчика при завершении успешной итерации. Но по нашему опыту, получился эффект отрицательный. Стали работать еще хуже. Тестировщики пошли к разработчикам: "Давай-давай быстрей". Получилось еще хуже.   

Еще одна довольно революционная вещь, которую мы сделали: отказались от репорта времени. 

Когда я общаюсь со своими коллегами из крупных корпораций иногда в чате, они говорят: "Я репортил два часа времени за сегодня. Я так устал".  Активность для разработчика очень стрессовая: репортить время для заказчиков. 

Мы пропагандируем доверие. Мы отказались от "трекания" времени вообще. Единственное правило: приди в 11 часов на daily standup, и время можно не репортить. 

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

Реплика из зала: Как вы боретесь с этим у себя? 

Антон Марченко: Время никто не репортит. Все друг друга знают. 

Реплика из зала: И даже не работают. 

Антон Марченко: Что значит "не работают"? Нет! Мы верим в то, что если человека не контролировать сверху… Вот я люблю работать. Я пришел на работу – я работаю.  Мы верим, что разработчик пришел – ему хочется работать.

Реплика из зала: Это чисто на доверии все?

Антон Марченко: Да, только на доверии.  

Еще одна веселая картинка: "К сожалению, я не могу вам помочь, сэр, потому что я собака. Они нуждались в дешевой рабочей силе, а я как раз работаю за колбасу".  

Есть еще один тренд: сейчас можно продавать не сам продукт, а сервисы. Даже взять бритву "Gillette": сама по себе бритва в подарочном наборе стоит очень дешево. Но если мы хотим купить лезвия, то мы будем продавать… Основной бизнес делается на лезвиях. 

"Toyota" тоже: крайне успешные сервисы и запчасти – основной бизнес. 

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

В техническую поддержку, например, мы не берем людей без опыта. Обычно из (неразборчиво) трансформируем тех, кто уже 3-4 года. Можем предоставить потрясающий сервис на первой линии. 

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

Все, спасибо. 

(Аплодисменты).      

Вопросы и Ответы

Реплика из зала: С переходом на новую схему, когда вы отказались от SVN и перешли к git (как я понял, тестируете и в бранче отдельном, и потом в Master), увеличилось ли у вас количество тестировщиков? Какое у вас соотношение тестеров к девелоперам? 

Антон Марченко: Сейчас команда тестирования у нас 6 человек. Разработчиков, наверное… Сколько их… Может, 15. Примерно 1:3. Но команда тестирования… Юнит-тесты, функциональные тесты у нас пишут девелоперы. 

Был один неприятный момент для девелоперов, что в "Selenium Remote Control" нужно было выучить (неразборчиво). Разработчики лучше могут написать, естественно, чем отдельная команда тестирования. 

О времени – вы имеете в виду…

Реплика из зала: Я имел в виду, что увеличилось ли… Просто в своей компании планируем провести примерно такую же трансформацию. Вопрос – увеличится ли штат тестировщиков после такого перехода. Было ли это у вас? 

Антон Марченко: Я могу сказать, что у нас этого не было. Для команды тестирования особенно больше нагрузки не было. После того, как у нас полностью оттестировано и "вмерджено", мы проверяем немного совсем, что "вмерджено" удачно. На этом все. 

Я уже отмечал, что большое покрытие функциональными тестами. Я хотел еще отметить: по некоторой информации, TDD удорожает разработку на 30%. Где-то у меня была такая статистика. TDD и BDD выгодно использовать только в долгоиграющих проектах. Мы настроены не на то, чтобы год и продать, отдать заказчику.

На длительную перспективу, оказывается, выгоднее. В краткосрочной перспективы выгодно быстро (без TDD и BDD), но в долгосрочной перспективе мы, конечно… 

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

Антон Марченко: Не используем.  

Реплика из зала: Вы упомянули, что отправляете своих разработчиков на различные курсы.

Антон Марченко: Да. 

Реплика из зала: Для решения каких задач, на какие конкретно курсы вы отправляли каких разработчиков? 

Антон Марченко: Ой…

Реплика из зала: Имеются в виду направления – тестировщики…

Антон Марченко: У нас группа ездила в Лондон на "Usability Experience". Там была четырехдневная конференция. Это были два разработчика и три тестировщика. Разработчики ездили в Германию. Я не помню, как называлась конференция, но чисто девелоперская. 

Реплика из зала: Это просто конференция? (Неразборчиво,36:23) специальное обучение системам. 

Антон Марченко: Да, там было два дня конференции и три дня мастер-классов. Мы пытались сделать внутри какие-то такие event. Они у нас тоже присутствуют – раз в полгода internal conference. 

Реплика из зала: Это была на каком-то этапе перехода на конкретные технологии? 

Антон Марченко: Нет, это просто для общего развития и развития  сотрудников. 

Реплика из зала: Спасибо за доклад. Очень интересно. При переходе от Scrum к канбан как изменились фичи? Как вы детализируете, когда какие-то критерии для разбивки фичи на более две более мелкие, например. Было ли это изменение при переходе?

Антон Марченко: Мы, даже когда у нас был Scrum, пытались сделать как можно меньше (в нашей терминологии мы называем их) user story. Разбить как можно меньше функциональность.

Реплика из зала: Можно пример какой-то. Задача и что бьется, а что не бьется. 

Антон Марченко: Так, задача… Ну, что мы в последнее время делали…  

Реплика из зала: (Неразборчиво, 37:46).

Антон Марченко: Мы? Нет, мы (неразборчиво, 37:52). Допустим, мы делали новый e-mail плагин. Полностью собралась команда user experience. Мы пытались сделать когда-то прототипы пользователей, но это не помогло. Допустим, усовершенствование отправки e-mail, нотификации. Функциональность по отравлению e-mail заказчику.

Мы разбили ее примерно на 10 user story. Одно было минимальное – сделать шаблон. Второе… Короче, получилось на 10 частей. Они легли… Каждая user story делалась по 3-4 дня. 

Я прошу прощения, что пример, может, не очень удачный.

Реплика из зала: Какой-то смысл имели эти маленькие кусочки, а уже не конечное целое? Поставка промежуточного (неразборчиво, 38:53).

Антон Марченко: Да, у нас поставка примерно раз в неделю. 

Реплика из зала: Она была осмысленная?

Антон Марченко: Да, осмысленная. 

Реплика из зала: Каждая из этих итераций ушла в produсtion и работала?   

Антон Марченко: Да. Но, к сожалению, так не всегда бывает. Бывают моменты, которые просто как технические. 

Спасибо.  

 

Комментарии

Нет ни одного комментария

Только пользователи могут оставлять комментарии

Возможно, вам будет интересно:

Домас Митузас (Domas Mituzas)

Домас Митузас (Domas Mituzas)

Инженер по производительности баз данных в компании "Facebook".

Домас Митузас (Facebook) рассказывает о веб-масштабировании MySQL, выполняемом специалистами одной из крупнейших социальных сетей в мире.

Михаил Якшин

Михаил Якшин

Координатор команды разработчиков кластерной части Openstat.

Доклад Михаила Якшина об управляемом code injection в Apache Hadoop в системе интернет-статистики Openstat.

Ярослав Сергеев

Ярослав Сергеев

Исполнительный директор компании Wamba, ранее - php-разработчик, архитектор, тимлид, IT-директор и, наконец, CEO. Знает Wamba, как никто другой (речь идёт как о технической стороне проекта, так и о команде сотрудников).

Рассказ о проекте Mamba и "граблях", на которые наступала команда по мере его роста.