Жизнь в стиле стартапв корпоративной среде: Agile в помощь?Оксана Гоголева«Петер-Сервис»

О чем речь?

Иллюстрации (слева направо):фотография из статьи Life of a coal miner in Punjab, Justice League DC Comics

Почему это может быть интересно?I. Если хочется приобрести опыт, не наступая

на грабли самому ;)II. Если интересно, как теория работает на

практикеIII. Если хочется сравнить свой опыт с нашимIV. Если хочется узнать, всегда ли одни и те же

практики дают сходный эффект

Наш продуктM2M-платформа — многофункциональный программный комплекс, позволяющий организовать на новом уровне полный цикл предоставления М2М-услуг (телематика и телеметрия)• управление SIM-картами• мониторинг и антифрод• обработка событий• публичный API

История развития

Переломный 2014

Рост команды в два раза

Доведение продукта до

промышленного уровня

Одновременное внедрение

у двух крупных

заказчиков

161 релиз за год

Привет Максиму Дорофееву

Апогей хаоса

Апогей хаоса

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

При работе в таком режиме скоро потеряем часть команды......уже теряем двоих, могут добавиться ещё двое...

Нет правил. Это усложняет взаимодействие внутри команды. В основе организации нашей работы лежат устные договоренности, которые со временем меняются. Это уже создает «хаос»...С каждым релизом, с

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

Шаги к светлому будущемуI. Разделение группы на две команды со

своими тимлидамиII. Сбор проблем путем опросаIII. Беседы один на одинIV. Составление плана исправления ситуации

Иллюстрация: кадр из фильма Земля будущего 2015 года, Walt Disney Pictures

Список...<сарказм> Чуточку проблем. Их немного! </сарказм>

Зато… у нас были ошибки в планировании контрольных точек!

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

ними;• регламента процесса разработки;• регламента процесса тестирования;• регламента работы над ТС;• визуализации планов — текущих, ближайших, более отдаленных, совсем отдаленных;• плана работы по тех.долгу;• автоматизации тестирования и прогресса в технологиях;• работы с рисками.

Ежедневные стендапы

Ретроспектива (начало 2015г.)

Курс на agile

Курс на agileПочему тяжело пошло?I. Работа шла в отрыве

от принятых на тот момент практик производства

II. Изменения выполнялись в режиме «сверху вниз»

III. Контроль изменений осуществлялся сверху и в режиме жалоб трудящихся ;)

Курс на agileЧто нам помогло?

I. Компания начала стремительно меняться в направлении современных практик

II. Источником изменений стал тот, у кого в них есть потребность, — команда

III. Появились консультанты по гибким методологиям

Источником изменений стал тот, у кого в них есть потребность - команда.

Почему тяжело пошло?I. Работа шла в отрыве

от принятых на тот момент практик производства

II. Изменения выполнялись в режиме «сверху вниз»

III. Контроль изменений осуществлялся сверху и в режиме жалоб трудящихся ;)

Ежедневные стендапы

Ретроспектива (конец 2015г.)

Гоголева ОксанаОставшийся после завершения этапа технический долгМногочисленные претензии к качеству ФСНезавершенная практика написания ТС перед разработкойПлохое качество предыдущих версий, повлекшие отвлечение ресурсов от

текущей работы на патчиСазонов Герман

Неудовлетворительное качество сбора требования заказчика - правка ФС "на ходу". 

Из выше следующего - постоянные изменения в ТС.И всё таки проблемы в планировании - в последних итерациях всё было в

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

Токтаров Роман

Консолидация усилий только ближе к отгрузке. Не было ощущения тонуса на протяжении всей разработки, появился только в конце под давлением сроков. Есть начало и конец работ, а между ними нет никаких жестких вех. Здесь полезно было бы что-то типа ДЕМО, но внутри группы.

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

Недостаточно было выделено на патчи на этапе планирования. Не соблюдено соотношение 57:43.

Отсутствие самоконтроля над плановыми и актуальными трудозатрами от исполнителя задачи.

Слабый охват рабочимим процессами изменений в документации. Требуется развитие и регламентация процесса.

Тункин Адриан

Помимо написания кода, сейчас приходится еще проводить code-review, это хорошо отлавливаем баги, но с другой стороны time-consuming - если проводить качественный анализ кода - это занимает неплохой процент рабочего времени(по моим оценкам 15-20% времени).

Практика написания ТС самими разработчиками: 

это еще одно дополнительная нагрузка на разработчиков - и увеличивает время разработки  60-80% и это в условиях цейтнот.

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

Отгрузка последней функциональности 19 этапа ("Отчет состояния SIM-карт") вообще происходила не лету - без ТС дорабатывая и додумывая ФС в выходной день. И ТС до сих пор не написана и не пишется, а разработчикам некогда этим заниматься (через неделю что там было реализовано уже никто и помнить не будет).

Происходит техническая деградация Аналитического состава M2M-группы (системными аналитиками вас уже назвать нельзя), т.к. ФС предполагает только бизнес-требования. Теряется смысл единого цетра технической компетенции - т.к. она размазываетсяи между разработчиками и  блакополучно забывается. Сам смысл анализа теряется.

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

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

группы будет теперь сводиться к пересказу требований Заказчика в ФС.

Минчук Максим

По факту имеем критическую деградацию некоторых процессов в группе начиная с этого этапа:

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

Процесс написания ТС разработчиками и весь "Марлезонский балет" с защитами и переписываниями ТС оказался по факту неподъемным и чересчур перегруженным. Это ухудшило горизонтальные связи в группе. В результате потратили много человекочасов на генерацию ничего, а после догоняли работая на выходных и игнорируя процесс. Как результат, до тестировщиков и документатора информации дошло еще меньше чем раньше(часть утеряна вовсе), а то что дошло уже по дороге большей частью устарело.

У разработчиков разные настройки студий. Иногда в код-ревью попадает изменение форматирования которое отличается от принятых норм. Сильно отвлекает и замыливает глаз во время ревью.

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

Иногда плохочитаемые задачи на доске, сожность задачи. Было лучше когда на задаче ставили срок.

Озадачивает преобладание красных бумажек и розовых. Хочется красные превратить в желтые. Кто бы это продал заказчику как продукт ))

Мартынов ДмитрийПо процессы проектирования:

Не отлажен процесс написания ФС  в итоговом документе не достаточно информации для

конечной разработкив процессе написания ФС слишком слабое взаимодействие с

архитектором дорабатываемого решения, а каждое решение должно согласовываться именно с ним

в ряде случаев принципиально неверная последовательность действий при составлении ФС - в идеале поступившее требование сразу должно обсуждаться аналитиком и архитектором на предмет возможности реализации и только после этого информация передается заказчику. 

Также не отлажен процесс написания ТСКроме всего прочего ТС не всегда нужна 

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

Документирование - Катя регулярно жалуется на то, что до нее не доходит информация об изменениях в документации.

Зотов Владимир

ПроцессНаличие официального этапа патченья. Т.е. мы как бы

заранее расписываемся в наличии у себя дефектов, в то время как повышение качества процессов должно приводить ко всё меньшему количеству заплаток.

Уточнение ролей не начало реализовываться полноценно. Не редко информация всё ещё не отправляется

заинтересованным лицам. Заинтересованные лица не приглашаются на встречу. Не реализуются действия по повышению экспертизы в обозначенных областях.

Начало разработки при непонятных требованиях, неготовых ФС (причём в 20 этапе это снова прогнозируется).

Некорректный процесс управления изменениями, инициированными при разработке (должно быть всегда согласование с заказчиком, изменение требований, ФС, ТС, ПМИ и кода, всё вместе, а сейчас не так).

Не используются задачи в JIRA (было бы удобно для трекинга работ)

Командный климатВыстраивание в

команде полярного негативного мышления"разработчик vs аналитик".

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

Управление работамиНизкая точность оценок трудозатрат из-за низкого уровня

работы с требованиями и непроработки концепций перед оценкой

Отсутствие планирования и контроля временных затрат на уровне отдельного сотрудника

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

Разработка требованийНедостаточная совместная работа при проработке концепций

и ФС (было в 19 этапе, но в 20 уже улучшено)

До сих пор не развит процесс инженерии требований и управления продуктом

 Общесистемное проектирование

Вместо ФС разработка во многих случаях велась по эскизным проектам и концепциям, а полные функциональные проекты в ряде случаев не были разработаны из-за недостатка времени (ФС)

В работу аналитиков не до конца внедрён комплекс проектных артефактов

До сих пор много проблем в общесистемном проектированииПрограммно-техническое проектирование

Не был поставлен процесс технического проектирования (ТС). Опасения Максима де-факто реализуются, из-за того что не были проработаны вопросы объёма проектирования и распределения ответственности за проектирование среди архитекторов и проектировщиков. Кроме того сложности вызвала необходимость использовать шаблоны word для ТС, что без подготовки было крайне неудобно для коллег, которые редко ранее использовали word.

Качество продукта и тестирование

Проектирование и поддержка нагрузочного тестирования производилось не тестировщиками

Отсутствие контроля характеристик качества продукта Рысева Екатерина  

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

задержка начальных сроков - отгрузка была запланировпна на 13 ноября;

перенос сроков не был обоснован возросшей вдруг нагрузкой - изначально было проведено неграмотное планирование;

цейтнот перед отгрузкой, что не могло не сказаться на качестве: часть функциональности отдавалась в тестирование в последний момент, не оставалось времени на багофикс и документирование. Так, например, отчет по комплексной проверке не дошел до меня, документировался уже в 19-1;

действовали по принципу: "успеем в Чикаго вовремя, но багаж придется выкинуть". Это про ТС, про тестирование и документирование.

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

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

Информационный вакуум: очень усложняло жизнь отсутствие внятной ТС, где были бы описаны все необходимые для документирования сущности (объекты БД, пользовательские процедуры и функции, параметры в каталине, настроечные параметры базы, особенности настройки функциональности). Замечу, что мне требовалось поверхностное описание - хотя бы наименование новых сущностей или изменившихся в ходе реализации. Мне надо было знать, что они есть и их надо включить в документацию. Все остальные детали, я могла бы увидеть из кода. При появлении нового человека описание должно быть настолько полным, насколько возможно.

 Планирование работ осуществляется одним человеком, а не всей

командой. В итоге, цифры, взятые с потолка ни кем не контролируются, сроки не соблюдаются. Вопрос: смысл в таком планировании?

Любые изменения ФС на финишном этапе считаю недопустимым. После начала разработки функциональность, описанная в ФС, считается согласованной с заказчиком. Все нюансы, неточности, вопросы необходимо выяснять ДО начала разработки, а не во время. Для этого сушествует применяемая в командах разработки best practice - brainstorm.

 Также считаю недопустимым изменение МПСИ, написанной на основе ФС.

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

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

закончить.нужна в джире доска!

Ретроспектива (конец 2015г.)

Гоголева ОксанаОставшийся после завершения этапа технический долгМногочисленные претензии к качеству ФСНезавершенная практика написания ТС перед разработкойПлохое качество предыдущих версий, повлекшие отвлечение ресурсов от

текущей работы на патчиСазонов Герман

Неудовлетворительное качество сбора требования заказчика - правка ФС "на ходу". 

Из выше следующего - постоянные изменения в ТС.И всё таки проблемы в планировании - в последних итерациях всё было в

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

Токтаров Роман

Консолидация усилий только ближе к отгрузке. Не было ощущения тонуса на протяжении всей разработки, появился только в конце под давлением сроков. Есть начало и конец работ, а между ними нет никаких жестких вех. Здесь полезно было бы что-то типа ДЕМО, но внутри группы.

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

Недостаточно было выделено на патчи на этапе планирования. Не соблюдено соотношение 57:43.

Отсутствие самоконтроля над плановыми и актуальными трудозатрами от исполнителя задачи.

Слабый охват рабочимим процессами изменений в документации. Требуется развитие и регламентация процесса.

Тункин Адриан

Помимо написания кода, сейчас приходится еще проводить code-review, это хорошо отлавливаем баги, но с другой стороны time-consuming - если проводить качественный анализ кода - это занимает неплохой процент рабочего времени(по моим оценкам 15-20% времени).

Практика написания ТС самими разработчиками: 

это еще одно дополнительная нагрузка на разработчиков - и увеличивает время разработки  60-80% и это в условиях цейтнот.

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

Отгрузка последней функциональности 19 этапа ("Отчет состояния SIM-карт") вообще происходила не лету - без ТС дорабатывая и додумывая ФС в выходной день. И ТС до сих пор не написана и не пишется, а разработчикам некогда этим заниматься (через неделю что там было реализовано уже никто и помнить не будет).

Происходит техническая деградация Аналитического состава M2M-группы (системными аналитиками вас уже назвать нельзя), т.к. ФС предполагает только бизнес-требования. Теряется смысл единого цетра технической компетенции - т.к. она размазываетсяи между разработчиками и  блакополучно забывается. Сам смысл анализа теряется.

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

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

группы будет теперь сводиться к пересказу требований Заказчика в ФС.

Минчук Максим

По факту имеем критическую деградацию некоторых процессов в группе начиная с этого этапа:

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

Процесс написания ТС разработчиками и весь "Марлезонский балет" с защитами и переписываниями ТС оказался по факту неподъемным и чересчур перегруженным. Это ухудшило горизонтальные связи в группе. В результате потратили много человекочасов на генерацию ничего, а после догоняли работая на выходных и игнорируя процесс. Как результат, до тестировщиков и документатора информации дошло еще меньше чем раньше(часть утеряна вовсе), а то что дошло уже по дороге большей частью устарело.

У разработчиков разные настройки студий. Иногда в код-ревью попадает изменение форматирования которое отличается от принятых норм. Сильно отвлекает и замыливает глаз во время ревью.

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

Иногда плохочитаемые задачи на доске, сожность задачи. Было лучше когда на задаче ставили срок.

Озадачивает преобладание красных бумажек и розовых. Хочется красные превратить в желтые. Кто бы это продал заказчику как продукт ))

Мартынов ДмитрийПо процессы проектирования:

Не отлажен процесс написания ФС  в итоговом документе не достаточно информации для

конечной разработкив процессе написания ФС слишком слабое взаимодействие с

архитектором дорабатываемого решения, а каждое решение должно согласовываться именно с ним

в ряде случаев принципиально неверная последовательность действий при составлении ФС - в идеале поступившее требование сразу должно обсуждаться аналитиком и архитектором на предмет возможности реализации и только после этого информация передается заказчику. 

Также не отлажен процесс написания ТСКроме всего прочего ТС не всегда нужна 

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

Документирование - Катя регулярно жалуется на то, что до нее не доходит информация об изменениях в документации.

Зотов Владимир

ПроцессНаличие официального этапа патченья. Т.е. мы как бы

заранее расписываемся в наличии у себя дефектов, в то время как повышение качества процессов должно приводить ко всё меньшему количеству заплаток.

Уточнение ролей не начало реализовываться полноценно. Не редко информация всё ещё не отправляется

заинтересованным лицам. Заинтересованные лица не приглашаются на встречу. Не реализуются действия по повышению экспертизы в обозначенных областях.

Начало разработки при непонятных требованиях, неготовых ФС (причём в 20 этапе это снова прогнозируется).

Некорректный процесс управления изменениями, инициированными при разработке (должно быть всегда согласование с заказчиком, изменение требований, ФС, ТС, ПМИ и кода, всё вместе, а сейчас не так).

Не используются задачи в JIRA (было бы удобно для трекинга работ)

Командный климатВыстраивание в

команде полярного негативного мышления"разработчик vs аналитик".

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

Управление работамиНизкая точность оценок трудозатрат из-за низкого уровня

работы с требованиями и непроработки концепций перед оценкой

Отсутствие планирования и контроля временных затрат на уровне отдельного сотрудника

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

Разработка требованийНедостаточная совместная работа при проработке концепций

и ФС (было в 19 этапе, но в 20 уже улучшено)

До сих пор не развит процесс инженерии требований и управления продуктом

 Общесистемное проектирование

Вместо ФС разработка во многих случаях велась по эскизным проектам и концепциям, а полные функциональные проекты в ряде случаев не были разработаны из-за недостатка времени (ФС)

В работу аналитиков не до конца внедрён комплекс проектных артефактов

До сих пор много проблем в общесистемном проектированииПрограммно-техническое проектирование

Не был поставлен процесс технического проектирования (ТС). Опасения Максима де-факто реализуются, из-за того что не были проработаны вопросы объёма проектирования и распределения ответственности за проектирование среди архитекторов и проектировщиков. Кроме того сложности вызвала необходимость использовать шаблоны word для ТС, что без подготовки было крайне неудобно для коллег, которые редко ранее использовали word.

Качество продукта и тестирование

Проектирование и поддержка нагрузочного тестирования производилось не тестировщиками

Отсутствие контроля характеристик качества продукта Рысева Екатерина  

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

задержка начальных сроков - отгрузка была запланировпна на 13 ноября;

перенос сроков не был обоснован возросшей вдруг нагрузкой - изначально было проведено неграмотное планирование;

цейтнот перед отгрузкой, что не могло не сказаться на качестве: часть функциональности отдавалась в тестирование в последний момент, не оставалось времени на багофикс и документирование. Так, например, отчет по комплексной проверке не дошел до меня, документировался уже в 19-1;

действовали по принципу: "успеем в Чикаго вовремя, но багаж придется выкинуть". Это про ТС, про тестирование и документирование.

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

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

Информационный вакуум: очень усложняло жизнь отсутствие внятной ТС, где были бы описаны все необходимые для документирования сущности (объекты БД, пользовательские процедуры и функции, параметры в каталине, настроечные параметры базы, особенности настройки функциональности). Замечу, что мне требовалось поверхностное описание - хотя бы наименование новых сущностей или изменившихся в ходе реализации. Мне надо было знать, что они есть и их надо включить в документацию. Все остальные детали, я могла бы увидеть из кода. При появлении нового человека описание должно быть настолько полным, насколько возможно.

 Планирование работ осуществляется одним человеком, а не всей

командой. В итоге, цифры, взятые с потолка ни кем не контролируются, сроки не соблюдаются. Вопрос: смысл в таком планировании?

Любые изменения ФС на финишном этапе считаю недопустимым. После начала разработки функциональность, описанная в ФС, считается согласованной с заказчиком. Все нюансы, неточности, вопросы необходимо выяснять ДО начала разработки, а не во время. Для этого сушествует применяемая в командах разработки best practice - brainstorm.

 Также считаю недопустимым изменение МПСИ, написанной на основе ФС.

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

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

закончить.нужна в джире доска!

В 10 раз больше,на самом деле!

Ретроспектива (конец 2015г.)

СпринтыПлан демо1. SMSC-эмулятор настроен так, чтобы при доставке

выдавать ответ EXPIRED (параметр receipt_state = EXPIRED в файле conf\deliver_sm.cfg).

2. Пользователь выполняет СМС-тест.3. На форме результатов СМС-теста отсутствует результат

(красная лампочка), дата отправки также отсутствует. СМСка при этом отправлена (в таблице m2m_activity_test_results для теста ACTIVE_DATE установлено). В поле статус д.б. пусто или EXPIRED.

4. SMSC эмулятор настроен так, чтобы при доставке выдавать ответ DELIVRD (параметр receipt_state = DELIVRD в файле conf\deliver_sm.cfg).

5. Пользователь выполняет СМС-тест.6. Через какое-то время на форме результатов СМС-теста

появляется успешный результат (зеленая лампочка), указана дата доставки СМС. СМСка при этом отправлена и доставлена (в таблице m2m_activity_test_results для теста ACTIVE_DATE установлено). В поле статус д.б. пусто или DELIVRD 

Что практикуем сейчасI. Двухнедельные спринтыII. Ежедневные стендапы — 10 минутIII. Демо по окончании спринта — около 30 минутIV. Планирующий митинг в начале спринта — около 1–2 часовV. Ретроспектива по результатам спринта — 2 часаVI. Идет активное покрытие автотестамиVII. Внедрены Stash, Git Flow, Code ReviewVIII. Готовимся к переходу к CI (идет внедрение TeamCity)

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

Я вижу, что пока рано говорить о переходе. Идет всего лишь третий спринт и решаемые задачи пока незначительны. Те «+», ради которых затевался переход, всем известны, поэтому повторяться было бы странно. Но, на мой взгляд, вроде бы, намечается сдвиг в консолидации работающих в группе «человеков» в Команду.Внедрение итерационной разработки помогает решить проблему равномерного распределения нагрузки на весь этап разработки версии продукта. Из этой базовой цели вытекает множество положительных последствий — четкое понимание сроков реализации конкретных доработок внутри этапа, удобство и сама возможность разбиения комплексных работ на несколько спринтов с демонстрацией промежуточного результата, такие работы акцентируют внимание на модульности продукта, что может положительно сказаться на архитектуре. Также важно, что итерационная разработка позволяет получать от заказчика оценку готовой функциональности задолго до выпуска продукта, что сокращает риск последующих заплаток (патчей).

« »« »«»

Ретроспектива (начало 2016г.)

ВыводыI. Когда команды работают в направлении общего

движения, результат многократно улучшаетсяII. Изменения, которые идут изнутри команды, а не

насаждаются извне, имеют намного больше шансов на успех

III. Помощь профессионалов творит чудеса!IV. Накладные расходы на Agile-ритуалы не

превышают 10% рабочего времени и многократно окупаются

V. Процесс улучшений никогда не заканчивается, т.к. нет предела совершенству