Мой доклад посвящен истории создания нового продукта и новой команды. Эта история началась в 2012-м году с идеи создания WEB-сервиса для предоставления корпоративным клиентам операторов связи возможности управлять своими M2M-SIM-картами, т.е. SIM-картами, установленными в различных устройствах. Наша история, наверное, похожа на многие, но имеет и свои особенности. С одной стороны, мы являлись представителями крупной и известной компании. С другой столкнулись, практически со всеми проблемами, типичными для стартапа. В самом начале нас было несколько энтузиастов. Мы одновременно разрабатывали продукт, искали заказчика, финансирование, формировали команду и выстраивали в ней процессы. Нас окружал "суровый энтерпрайз" ;) Мы пережили все болезни роста и продукта и команды, несколько раз нам казалось, что все пропало. В какой-то момент, мы осознали, что пора выбираться из хаоса и обратиться к современным методологиям разработки ПО, таким, как Agile. Но осознать мало, надо еще сделать :) На наше счастье, к этому моменту, в нашей компании также начались процессы перестройки всего подхода к производству. О пройденном за три года пути, сделанных выводах и приобретенном опыте я и хочу рассказать слушателям моего доклада.

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

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

3. Почему это может быть
интересно?
I. Если хочется приобрести опыт, не наступая на
грабли самому ;)
II. Если интересно, как теория работает на практике
III. Если хочется сравнить свой опыт с нашим
IV. Если хочется узнать, всегда ли одни и те же
практики дают сходный эффект

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

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

6. Переломный 2014
Рост команды в
два раза
Доведение
продукта до
промышленного
уровня
Одновременное
внедрение у
двух крупных
заказчиков
161 релиз за год

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

8. Апогей хаоса

9. Апогей хаоса
...у нас проблемы c
публичным стендом, версия
не работает, много дефектов.
Женя не может показывать
его, а ему, по его словам, он
сейчас нужен. Еще позавчера
попросил коллег починить...
При работе в таком
режиме скоро потеряем
часть команды...
...уже теряем двоих,
могут добавиться ещё
двое...
Нет правил. Это усложняет
взаимодействие внутри
команды. В основе
организации нашей работы
лежат устные
договоренности, которые со
временем меняются. Это уже
создает «хаос»...
С каждым релизом, с каждым
патчем становится всё больше и
больше комОк или уже ком
затычек, костылей и
всевозможных «if-else» — нужен
рефакторинг узких мест.
Относится как к серверной, так и
к клиентской части.

10. Шаги к светлому будущему
I. Разделение группы на две команды со своими
тимлидами
II. Сбор проблем путем опроса
III. Беседы один на один
IV. Составление плана исправления ситуации
Иллюстрация: кадр из фильма Земля будущего 2015 года, Walt Disney Pictures

11. Список...
<сарказм> Чуточку проблем. Их немного! </сарказм>
Зато… у нас были ошибки в планировании контрольных точек!
10+ вещей, которых у нас не было:
• визуализации планирования, регламентов, обязанностей, схем взаимодействия;
• четкого описания функциональных обязанностей каждого и алгоритмов взаимодействия между ними;
• регламента процесса разработки;
• регламента процесса тестирования;
• регламента работы над ТС;
• визуализации планов — текущих, ближайших, более отдаленных, совсем отдаленных;
• плана работы по тех.долгу;
• автоматизации тестирования и прогресса в технологиях;
• работы с рисками.

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

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

14. Курс на agile

15. Курс на agile
Почему тяжело
пошло?
I. Работа шла в отрыве
от принятых на тот
момент практик
производства
II. Изменения выполнялись
в режиме «сверху вниз»
III. Контроль изменений
осуществлялся сверху и
в режиме жалоб
трудящихся ;)

16. Курс на agile
Что нам помогло?
I. Компания начала
стремительно меняться в
направлении современных
практик
II. Источником изменений
стал тот, у кого в них есть
потребность, — команда
III. Появились консультанты
по гибким методологиям
Источником изменений стал тот, у кого в них есть потребность - команда.
Почему тяжело
пошло?
I. Работа шла в отрыве
от принятых на тот
момент практик
производства
II. Изменения выполнялись
в режиме «сверху вниз»
III. Контроль изменений
осуществлялся сверху и
в режиме жалоб
трудящихся ;)

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

18. Ретроспектива (конец 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.
Также считаю недопустимым изменение МПСИ, написанной на основе ФС. Даже
незначительные изменения будут противоречать тому документу, который
приложен к договору. И если в ходе приемки по новой методике, недостатков
не будет обнаружено, с юридической т.зр мы обязательства все равно не
выполнили.
Мы не умеем пользоваться джирой.
нет прозрачности,
не соблюдаем воркфлоу,
неговорящие названия ишью без описания, что сделать,
нет инфы когда к этому можно приступить и когда нужно закончить.
нужна в джире доска!

19. Ретроспектива (конец 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
раз больше,
на самом деле!

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

21. Спринты
План демо
1. SMSC-эмулятор настроен так, чтобы при доставке
выдавать ответ EXPIRED (параметр receipt_state
= EXPIRED в файле confdeliver_sm.cfg).
2. Пользователь выполняет СМС-тест.
3. На форме результатов СМС-теста отсутствует результат
(красная лампочка), дата отправки также отсутствует.
СМСка при этом отправлена (в таблице
m2m_activity_test_results для теста ACTIVE_DATE
установлено). В поле статус д.б. пусто или EXPIRED.
4. SMSC эмулятор настроен так, чтобы при доставке
выдавать ответ DELIVRD (параметр receipt_state
= DELIVRD в файле confdeliver_sm.cfg).
5. Пользователь выполняет СМС-тест.
6. Через какое-то время на форме результатов СМС-теста
появляется успешный результат (зеленая лампочка),
указана дата доставки СМС. СМСка при этом отправлена и
доставлена (в таблице m2m_activity_test_results для теста
ACTIVE_DATE установлено). В поле статус д.б. пусто
или DELIVRD

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

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

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

25. Выводы
I. Когда команды работают в направлении общего
движения, результат многократно улучшается
II. Изменения, которые идут изнутри команды, а не
насаждаются извне, имеют намного больше шансов на
успех
III. Помощь профессионалов творит чудеса!
IV. Накладные расходы на Agile-ритуалы не превышают
10% рабочего времени и многократно окупаются
V. Процесс улучшений никогда не заканчивается, т.к. нет
предела совершенству 