Проблемы, возникающие в процессе разработки для заказчика
Как правило, все начинается с того, что у компании есть разработчик, который разбирается в бизнес домене, общается с пользователями. Этот разработчик для компании совсем «свой».
И тестируют в этой ситуации обычно пользователи. Причем качество определяется не наличием багов, а умением программистов их обезвреживать.
Производительность у таких разработчиков-одиночек может быть достаточно высокой. Потому что системы, которые ими поддерживаются, обычно небольшие, и взаимодействовать с другими разработчиками нет необходимости. В принципе, если у вас так, и вам не кажется, что у вас плохо, – замечательно! Ничего не меняйте. Вы молодцы!
Но может так случиться, что сложность проекта станет увеличиваться. Появится необходимость поддерживать более сложные продукты, возрастет уровень запросов пользователей. В таких случаях обычно появляется менеджер проектов, который выполняет все остальные роли.
В процессе роста проекта на одного человека может свалиться огромное количество задач, которые за разумные сроки сделать нельзя. Все просто начинает упираться колом. Человек ушел в отпуск или заболел – и все, ничего больше нельзя сделать.
Как быть? Ведь хочется сделать так, чтобы у нас была команда людей, которые за проект отвечают, которые могут его двигать, развивать и т.д.
Обычно в этой ситуации между заказчиком и разработчиком возникает некоторый конфликт:
- Заказчик говорит, что «Долго делают». А разработчик говорит – «Непродуманные требования».
- Заказчик говорит – «Срывают сроки». Разработчик отвечает – «Новые задачи».
- Заказчик говорит – «Низкое качество». Разработчик отвечает – «Не знают, чего хотят».
- Заказчик говорит – «Постоянные баги». Разработчик отвечает – «Сроки с потолка».
Это – некоторый классовый конфликт, классовая борьба, котораяможет длиться довольно долго, и у этой классовой борьбы есть два варианта развития.
Первый вариант развития – это победа бизнеса. Это когда бизнес победил, а разработчики в загоне, фактически для бизнеса они – рабы. Так случается в большинстве компаний. У вас наверняка так.
- Заказчик говорит – «Почему не готово?» Вы отвечаете – «Приоритеты поменялись», «Новые требования», «Программиста забрали на другой проект».
- Заказчик говори – «Чтобы завтра было!». Вы отвечаете – «Придется урезать тестирование».
- Ну и на следующий день у нас спрашивают – «Почему баги?»
Это первый вариант. Он довольно грустный.
Есть другой вариант, замечательный для разработчика, но тяжелый для бизнеса. В этом варианте получается, что разработчики победили, и они теперь привилегированный класс, им о бизнес можно ноги вытирать:
- Когда разработчики говорят – «Ничего делать не будем, пока не согласуем требования».
- Или когда они направляют любые заявки в «Комитет по управлению изменениями». Что это такое? Это такая координационная группа, которая собирается раз в месяц. Если они в процессе своего обсуждения «запрувят» 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