Автоматизация учета

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

Как правило, все начинается с того, что у компании есть разработчик, который разбирается в бизнес домене, общается с пользователями. Этот разработчик для компании совсем «свой».
2 тыс. 13
Agile для внутренней разработки
Фото Бориса Мальцева. Клерк.Ру

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  • Когда разработчики говорят – «Ничего делать не будем, пока не согласуем требования».
  • Или когда они направляют любые заявки в «Комитет по управлению изменениями». Что это такое? Это такая координационная группа, которая собирается раз в месяц. Если они в процессе своего обсуждения «запрувят» 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% полезности.

Комментарии

1

До 1 апреля надо сдать бухотчетность за 2023 год

Организации на всех режимах налогообложения должны сдавать бухгалтерскую отчетность не позднее 3-х месяцев после окончания отчетного года. Крайний срок сдачи за 2023 год – 01.04.2024 включительно.

Курсы повышения
квалификации

18
Официальное удостоверение с занесением в госреестр Рособрнадзора
ПСН

🔨 ИП на ПСН должен сам оказывать услуги, а не перезаказывать их у других ИП. Эксперт: достаточно спорная позиция Минфина

Заключение предпринимателем договоров субподряда с другими ИП не вписывается в рамки патента.

83

ТОП-15 курсов по 1С:Документоборот (делопроизводство) в 2024 году

В этой статье мы собрали платные и бесплатные курсы по 1С:Документообороту.

ТОП-15 курсов по 1С:Документоборот (делопроизводство) в 2024 году
Лучшие спикеры, новый каждый день
Банки

Клиенты ВТБ будут получать кешбэк в рублях

ВТБ по программе мультибонусов будет начислять кешбэк в реальных рублях. Клиенты могут установить избранные категории товаров для получения повышенных бонусов до 25% с покупок.

🏃 Какие выплаты положены работнику при увольнении переводом. Эксперт: допвыплаты на уровне закона были бы странными

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

133

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

Больше трети руководителей в России готовы отказаться от своей должности, чтобы начать строить карьеру в новой профессии.

Опытом делятся эксперты-практики, без воды

Инвесторы жалуются на «Лукойл» из-за сокрытия финансовой отчетности

Компания в отчетности по МСФО за 2023 год не сравнила результаты с прошлым годом, ссылаясь на постановление, которое перестало действовать.

Верховный Суд поддержал рекомендации Роспотребнадзора обеспечивать водой и спецодеждой работающих в жару

ВС РФ признал законными Рекомендации по работе в условиях сильной жары и повышенных температур, изданные Роспотребнадзором.

Бесплатно с Кадры

Кадровое законодательство 2024: изменения и дополнения. Мини-курс с видео, конспектом и тестами

Обо всех изменениях кадрового законодательства, нововведениях в ТК, нюансах заполнения ЕФС-1 и новых формах налоговой отчетности рассказываем в мини-курсе.

Кадровое законодательство 2024: изменения и дополнения. Мини-курс с видео, конспектом и тестами

Обновления на «Клерке». Все уже заметили?

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

Обновления на «Клерке». Все уже заметили?

Прокуратора может изъять акции «Макфы» в пользу государства

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

96
ЭДО

Минтранс хочет провести эксперимент с переходом на ЭДО грузоперевозок на всех видах транспорта

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

Миникурсы, текстовые и видеоинструкции для бухгалтеров

Что ест бухгалтер. Давно не ели десертов

Лекарство от негатива. Тирамису — самый популярный в мире десерт.

Что ест бухгалтер. Давно не ели десертов
131
Банки

Приложение Райффайзенбанка снова работает

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

Как нанять толкового бухгалтера в компанию: рекомендации экспертов

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

Как нанять толкового бухгалтера в компанию: рекомендации экспертов
2
96

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

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

Иллюстрация: Вера Ревина, Клерк.ру

Верховный Суд защитил недвижимость предпринимателя от притязаний церкви

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

3
114

ФРМР: обязательная регистрация (до 01.04.2024) медицинских и фармацевтических работников

Медицинские и фармацевтические работники, а также лица, которые обучаются медицинским и фармацевтическим специальностям, должны зарегистрироваться в ФРМР. Разбираемся в этой подсистеме ЕГИСЗ.

ФРМР: обязательная регистрация (до 01.04.2024) медицинских и фармацевтических работников

Управление персоналом. Принципы управления человеческим ресурсом

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

Управление персоналом. Принципы управления человеческим ресурсом

Интересные материалы

🔥 Четыре новые онлайн-курса этой весны уже в подписке Клерк.Премиум!

Оформите годовую подписку Клерк.Премиум со скидкой 50% за 9900 рублей и получите доступ к самым свежим материалам и курсам!