Agile для внутренней разработки

29.09.15

Управление проектом - Agile

Речь пойдет о том, что такое гибкие методологии. Статья написана на основе доклада, прочитанного на Конференции IE 2013 Revolution (7-8 ноября 2013 года).

Проблемы, возникающие в процессе разработки для заказчика

 

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

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

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

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

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

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

Обычно в этой ситуации между заказчиком и разработчиком возникает некоторый конфликт:

  • Заказчик говорит, что «Долго делают». А разработчик говорит – «Непродуманные требования».
  • Заказчик говорит – «Срывают сроки». Разработчик отвечает – «Новые задачи».
  • Заказчик говорит – «Низкое качество». Разработчик отвечает – «Не знают, чего хотят».
  • Заказчик говорит – «Постоянные баги». Разработчик отвечает – «Сроки с потолка».

Это – некоторый классовый конфликт, классовая борьба, котораяможет длиться довольно долго, и у этой классовой борьбы есть два варианта развития.

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

  • Заказчик говорит – «Почему не готово?» Вы отвечаете – «Приоритеты поменялись», «Новые требования», «Программиста забрали на другой проект».
  • Заказчик говори – «Чтобы завтра было!». Вы отвечаете – «Придется урезать тестирование».

  • Ну и на следующий день у нас спрашивают – «Почему баги?»

Это первый вариант. Он довольно грустный.

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

  • Когда разработчики говорят – «Ничего делать не будем, пока не согласуем требования».
  • Или когда они направляют любые заявки в «Комитет по управлению изменениями». Что это такое? Это такая координационная группа, которая собирается раз в месяц. Если они в процессе своего обсуждения «запрувят» changerequest по поводу конкретной заявки, тогда разработчики будут что-то делать.
  • Или когда разработчики говорят – у нас сейчас фаза разработки архитектуры. И во время этой фазы ничего в течение двух месяцев не делают, потому что говорят, что сначала должна быть разработана архитектура. То есть, на клеточном уровне они сильно заняты, по крайней мере те, кто что-то пишет. Но по большому счету в этот период ничего не делается.
  • Есть еще фаза тестирования. Когда разработчики говорят, что перед тем, как выложить разработку в Production, нужно еще запустить фазу тестирования.
  • В принципе, у заказчика есть один-единственный шанс отбиться. Этот шанс называется «приемка у заказчика».Но и тут можно промахнуться, если вдруг окажется, что разработчики выставили требование проводить приемку только по тестовым сценариям, которые заранее согласовали.

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

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

Здесь и приходят на помощь технологии разработки Agile как реальная возможность достичь компромисса между заказчиками и разработчиками.

 

Разработка по гибким методологиям 

 

При разработке по ТЗ получается примерно такая ситуация:

  • У вас есть ТЗ, над которым вы работаете в течение долгого времени. Вы можете даже по Agile и Scrum работать по ТЗ. Приходите в какую-то точку.
  • Потом идет сдача заказчику. После сдачи заказчику вы готовы в разумных пределах переписать что-то из сделанного. Потому что даже если вы в чем-то чуть-чуть потеряли, главное, что контракт подписали, проект сдали.
  • Потом возникает обратный путь, который называется «Эксплуатация». Там уже идет changerequest от бизнеса, и нам приходится в чем-то двигаться в другую сторону.Мы перепиливаем то, что было неправильно реализовано.

Так вот, разработка по технологии Agile – это попытка «упростить» ситуацию, двигаясь через частые промежуточные показы заказчику. На самом деле за счет этого получается существенная экономия за счет разницы между выполненными требованиями по ТЗ и реальными потребностями бизнеса, что показано на этом слайде. Эта разница называется «ложная загрузка» (failuredemand).

Нам не приходится писать лишний код, не приходится этот лишний код поддерживать, не приходится платить за это деньги нашим программистам. Нам не приходится работать в режиме «аврала» и строчить по 300-500 строчек кода в день. В среднем, нормальный промышленный стандарт – около 100 строчек кода в день. Быстрее и не нужно, можно просто попытаться срезать углы. А для этого достаточно делать регулярные показы заказчику. Это могут быть даже не показы, нам просто нужна качественная грамотная обратная связь.

 

Scrum

 

Есть разные методологии. Работа по методологии Scrum – это когда у вас есть беклог (backlog) продукта, в котором описана задача, которую вы собираетесь сделать, некий «план». Вы этот план бьете на подзадачи, рассчитанные, например, на две недели. В конце работы над  подзадачей вы получаете готовый продукт, который можно показать заказчику. В идеале, вы этот продукт для заказчика раскатываете в Production, чтобы получить еще более качественную обратную связь. И потом проводите ретроспективу, обсуждаете, как вам улучшить свой продукт.

Большую часть времени работа в Scrum ведется вокруг доски, которая называется Scrumboard (или Taskboard).

Выглядит это примерно так, как на слайде.

  • Слева у нас находится список задач, который нужно сделать – BackLog
  • В середине располагаются задачи, которые вы собираетесь делать в эту итерацию – ToDo
  • Дальше – те задачи, которые уже обрабатываются – InProgress
  • Потом - CodeReview
  • Тестирование – Test
  • И готовое – Done

Ну и в идеале, при работе над итерацией продукта, задачи постепенно переезжают слева направо.

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

 

Kanban

 

Еще есть такая методология, которая называется Kanban. Методологии Kanban и Scrum – это не то же самое. В Kanban разница в том, что там нет фиксированного времени на итерацию, просто задача переезжает слева направо. Идея такая же, как и в Scrum: ведется очередь задач, вы разрабатываете для них приемочные критерии, у вас разработка, тестирование, deploy и готово. Так же для разбора и обсуждения задач проводят StandUp.

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

 

Фаза «Анализ»

 

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

  • Например, он скажет вам: «выстрели мне в ногу!» И вы ему «да не вопрос!» - и стреляете.
    И он теперь: «у меня нога болит, поправь». Обычно разработчики на это отвечают: «у меня такая же нога – у меня не болит».
  • А если вы спросите: «зачем тебе, заказчик, стрелять себе в ногу?» Он может ответить: «она у меня чешется».
    А вы ему: «так давай я тебе ее почешу». И заказчик удивится: «а что, так можно было, что ли? Замечательно! Мне нравится!»

С точки зрения Scrum, Agile, Kanban и т.д. – это регулируется наличием соответствующих слотов. Есть слот «Анализ», и задачке обязательно нужно пройти фазу некоторого анализа, прежде чем попасть в разработку. Нельзя сразу закодить. С одной стороны, это замедляет разработку, но, с другой стороны, меньше будет «перебрасывания» неправильных алгоритмов на переделку (когда мы делаем не то, что нужно).

Конечно, это возможно только при условии, если вы делаете анализ более-менее качественно.

 

Фаза «Тестирование»

 

То же самое относится к тестированию. Когда у вас все долетает до Production, а потом «валится». Вы, как честный человек, свои баги, конечно, поправите. Но поправлять их уже после сдачи проекта – это слишком дорого для компании-заказчика.

Особенно дорого поправлять баги, которые находят пользователи. Большинство компаний, где зрелость процессов не очень высокая, полагается в тестировании на пользователей. Им кажется, что это бесплатно. На самом деле, тестирование на пользователях – это намного более дорого, чем тестирование своими силами.

Опять-таки, тестирование своими силами приводит к сокращению failureload.

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

 

Нужно ли ТЗ?

 

Перед тем как писать ТЗ, обсуждаем с заказчиком, что он в конечном счете хочет увидеть. Иногда для ТЗ достаточно просто зафиксировать мысли заказчика. А уже потом, опираясь на все это, начинать кодить какой-то конкретный процесс.

 

Критерии готовности

 

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

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

Как мы это делаем в гибких методологиях? Мы просто договариваемся о критериях готовности – Definition of Done. Это такая договоренность внутри команды, как правило, между тремя сторонами – заказчик, команда и руководство (потому что руководство тоже заинтересовано).

Что такое критерий готовности? Что определяет, что Feather Story или какой-то элемент задачи сделан? Обычно вначале две строчки закоммитил – и нормально. Потом мы постепенно увеличиваем глубину проработки технических критериев готовности, появляются требования о том, что сделанное обязательно должно быть протестировано, и критические баги должны быть исправлены. В связи с этим существенно добавляется объем работы, но потом, в дальнейшем, это снижает стоимость поддержки.

Фактически Agile и вообще Soft Engineering как таковой – это не экономия на затратах здесь и сейчас. Это экономия на том, что мы делаем эту работу сейчас, чтобы в будущем двигаться более эффективно. Вместо того чтобы потом, разбежавшись с огромной скоростью, просто упереться в стену, когда выяснится, что по каким-то причинам нет больше возможности развивать продукт.

 

Поток задач

 

 

Конечно, всем этим хотелось бы научиться управлять.

 

Вот этот график на верхнем слайде называется Cumulative Flow – поток задач нарастающим итогом. На нем показано, как в ваш HelpDesk прилетают заявки, и с какой скоростью вы эти заявки делаете. Видите, что здесь у вас есть проблемы? Дальше эти проблемы будут становиться только хуже и хуже. Чем дальше, тем сильнее вы будете отставать. Соответственно, стоит задача попытаться этот график как-то сузить.

 

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

 

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

 

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

 

 

Инструменты управления сроками

 

На этом слайде показана диаграмма Burn-downchart. В методологии Scrum мы используем для этого понятие Velocity – скорость команды, сколько человеко-дней за эту итерацию команда успела сделать. Это не человеко-дни потраченного времени, это человеко-дни вашей оценки планируемых работ. У вас есть backlog, есть какие-то задачи. Вы их оценили в человеко-днях. Сколько оцененных задач вы за итерацию успели сделать? Какую сумму планируемых работ необходимо перенести на следующую итерацию? Таким образом, можно прогнозировать, сколько нам нужно будет делать потом.

Например, вы знаете, что вы сделали за итерацию 20 человеко-дней, а весь backlog у вас на 200 человеко-дней. Это означает, что примерно за 10 итераций вы проект доделаете, конечно, если вам не навалят новых задач.Это неплохо работает. Ситуацию можно прогнозировать с точностью до 5%.

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

Поэтому еще один комикс: «Используй velocity для прогнозирования сроков окончания проекта» – «Я и так знаю сроки окончания проекта. Мне уже руководство их сказало».

Ну и что, что оно тебе их сказало? Ты все равно же должен попытаться понять – успеваешь ли ты уложиться в эти сроки или не успеваешь.

 

«Тогда используй Velocityд ля того, чтобы определить, на что не останется времени». Потому что есть какое-то количество времени, и понятно, что ты только это успеешь, и все. А вам отвечают: «Я и так знаю, на что времени не останется – на отдых и сон». То есть ближе к концу проекта люди прогнозируют, что они по определению будут работать overtime, хотя это не совсем логично.

 

Заключение

 

Ну и напоследок я хотел бы просто сказать, что «есть многое в мире, друг Горацио»…

Есть много практик, подходов, которые можно и нужно пробовать, смотреть, как они работают в вашей конкретной команде. Вы можете погуглить их по ключевому слову Software Engineering. Посмотрите, как они работают в вашей реальной ситуации. Вполне возможно, что по принципу Парето, 20% из них из них могут принести вам 80% полезности.

************

Приглашаем вас на новую конференцию INFOSTART EVENT 2019 INCEPTION.

См. также

Agile Внедрение изменений Бесплатно (free)

Тенденции последнего времени заставляют пересматривать привычные инструменты, менять подходы, подстраиваться под рынок труда. Расскажем об импортозамещении инструментария внедренцев, отличиях Agile от почасовки и рисках дефицита специалистов 1С.

13.09.2024    2537    0    glebushka    3    

8

Agile Бесплатно (free)

В статье рассмотрены практики, применяемые при разработке по методологии Agile.

13.05.2024    4330    0    Dimbayyyy    9    

11

Лидерство Личная эффективность Agile Анализ потребностей и поиск решений Бесплатно (free)

В семнадцатом выпуске второго сезона подкаста Радио “Аналитик“ обсудили, что из себя представляет модель Кеневин, чем и в каких ситуациях она может быть полезна тем, кто работает в сфере ИТ и не только.

19.04.2024    1159    0    Radio_Analyst    0    

5

Agile Бесплатно (free)

Agile в ИТ встречается все чаще, и об адаптации гибких технологий под проекты 1С задумываются многие. Расскажем о ключевых инструментах и точках приложения усилий для успешного внедрения Scrum при разработке в 1С.

28.07.2023    2912    0    olegminkov    4    

7

Agile Руководитель проекта Россия Бесплатно (free)

Продукт команды №7, 6 поток (курс Марии Темчиной «Управление ИТ-проектами. Agile. Практический курс Agile-лидера»)

13.06.2023    1677    12    dimbasbear    1    

2

Agile Бесплатно (free)

На конференции Infostart Event 2021 Post-Apocalypse выступил директор практики БИТ:ERP компании Первый БИТ Глеб Стальной. В ходе доклада он рассмотрел трансформацию проектного подхода в продуктовый, рассказал про имплементацию «современных» практик DevOps и продемонстрировал инструменты для разработки, взаимодействия с бизнесом и клиентами, применяемые в его команде.

27.02.2023    2804    0    glebushka    2    

15

Agile Бизнес-аналитик Руководитель проекта Бесплатно (free)

Это один из вопросов, которые мне задают довольно часто. Ну да, Эджайл, Скрам, технологии, методологии,  красивые слова. Но где вы видели это в реальности в 1С внедрениях????

06.12.2021    4514    0    MariaTemchina    49    

13

Agile Бесплатно (free)

Есть сообщество в Facebook'е и Инстаграм, которое публикует жизненные комиксы про внедрение гибких технологий на практике - Comic Agile.

01.04.2021    4120    0    MariaTemchina    18    

16
Комментарии
Подписаться на ответы Инфостарт бот Сортировка: Древо развёрнутое
Свернуть все
1. mulla1979 9 30.09.15 09:24 Сейчас в теме
Спасибо, очень познавательно!
2. Кузьмич 188 30.09.15 09:33 Сейчас в теме
ууу ... сколько много "умных слов". Сразили.
Software Engineering

Все, о чем тут расписано определяется "устаревшим" понятием "экстремальное программирование". Только напридумывали новые технологии и методологии. А суть осталась там же.

зы. Презентация конечно труд еще тот. Снимаю шляпу за оформление.
Silenser; ZLENKO; +2 Ответить
3. Designer1C 457 30.09.15 10:12 Сейчас в теме
Тема важная. Для меня самое интересное в статье : как не делать лишнюю работу.
Есть просьба использовать русские слова вместо слэнга.
Либо в начале статьи писать словарик. Лично мне было бы более понятно.
sergey512; emakei; +2 Ответить
4. maxx 996 07.10.15 21:41 Сейчас в теме
А при каких размерах проектов стоит применять подобнве технологии?
Например, у меня часто есть проекты на 200-300 часов срок исполнения от 2 нед до месяца. Разработчиков от 2 до 6. Список задач составлен, бюджет задачи в среднем 4-5 часов ( отчеты, печ.формы, мелкие механизмы)

Есть ли время на большое количество показов?
5. ВикторП 350 28.08.16 08:42 Сейчас в теме
3.То что здесь написано - не XP(экстремальное программирование..) Agile Scrum- про управление и организацию, а xp- про инженерные практики,то же парное программирование, к примеру
6. ВикторП 350 28.08.16 08:44 Сейчас в теме
4.Для вас подходит хорошо. Заодно скорость команды узнаете
7. brr 184 04.09.17 12:11 Сейчас в теме
А для этого достаточно делать регулярные показы заказчику. Это могут быть даже не показы, нам просто нужна качественная грамотная обратная связь.


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

Нужное подчеркнуть, отсутствующее добавить
8. Yashazz 4794 07.09.17 11:25 Сейчас в теме
Много картинок, много пыщь-пыщь, всё очень красиво, наглядно, увлекательно, и как всегда на практике заканчивается полным уродством, провалом и жестью немерянной. Любимый приём всех этих многознатцев-консультантов от эйджила - напустить пыль в глаза, очаровать сладкими сказками, как всё будет круто, потом сгрести бабла и сбежать. А реальный проект потом имеет только проблемы.

Я б за попытку распространять все эти agil'ы, особенно применительно к разработке 1С, сажал бы как за вредительство и мошенничество.
9. KSy 07.09.17 16:27 Сейчас в теме
(8) Поддерживаю.
Пусть они без ТЗ с частыми показами заказчику попробуют хотя бы УТ 11 (я не беру ERP) с доработками по планированию закупок/продаж+бюджетирование внедрить.

Такие статьи в стиле "кукушка хвалит петуха..." проходят на ура на хабре.
10. karapuzzzz 63 17.11.17 17:35 Сейчас в теме
(9)Для внедрения продукта используйте Waterfall, а для разработки - Agile. В чем проблема? Каждая методология имеет свою применимость. Хороший PM будет применять то, что необходимо именно в этом случае.
11. karapuzzzz 63 17.11.17 17:36 Сейчас в теме
(8)А какую методологию вы используете?
12. Yashazz 4794 21.11.17 17:34 Сейчас в теме
(11) Никакую. Мы методологиями не заморачиваемся, мы работаем. Дело делаем. Конфигурации создаём, доработки выполняем. Некогда нам, знаете ли, дурью маяться.
К наступлению авралов, частоте факапов, проблемам с клиентами итд - наличие либо отсутствие упомянутой "методологии" и прочей заумной хрени не имеет, как показывает опыт, ни-ка-ко-го отношения.

То же экстремальное, допустим, случается, но от него, по здравому размышлению, ничего бы не спасло. Ибо бизнес захотел всё готовое позавчера, и точка, и плевать ему на все спринты, канбаны, эйджилы и прочая)
13. karapuzzzz 63 21.11.17 22:06 Сейчас в теме
(12)
Ибо бизнес захотел всё готовое позавчера, и точка, и плевать ему на все спринты, канбаны, эйджилы и прочая

Та и не должен бизнес об этом знать. Точнее, желание бизнеса готового на вчера не должно встречать "у нас же спринт" или что-то подобное. Бизнес захотел - делаем. Добавляем новые задачи в спринт и делаем. Эджайл именно так и говорит: "Готовность к изменениям важнее следования первоначальному плану"
Методологиями не заморачиваются, методологиями следуют. Ни один проект не может существовать без управления. А значит, или вы не ведёте проектную деятельность (что мало вероятно при разработках конфигураций) или ведёте, но вы не в курсе.
14. Rico17 32 11.10.18 14:39 Сейчас в теме
Методология нужна когда "все плохо" ;)
Когда "мощность" разработчика не справляется с необходимым объемом в необходимые заказчику сроки.
Оставьте свое сообщение