Программное обеспечение проникает во все щели человеческого общества. Мы узнаем погоду через интернет, а не через обычный градусник за окном. Мы едем по новому адресу с навигатором, а не ищем квадрат G7 на странице 59. Мы включаем RunKeeper, когда катаемся на велосипеде, чтобы узнать среднюю скорость и похвастаться в твиттере. Мы используем софт каждый день. Наверное, бОльшую часть жизни мы уже проводим в обнимку с любимыми гаджетами и программным обеспечением, а не с любимым человеком.
Проблема в том, что никто не знает, как на самом деле писать классный софт быстро и правильно. Waterfall благополучно скончался на рубеже веков, а новые методы разработки (agile) пока не могут решить фундаментальные проблемы. Мы живем в очень интересное время. В настоящий момент идет быстрое развитие всей отрасли разработки ПО и накапливается база для качественного рывка.
Всем ясно, что agile становится мэйнстримом и очень скоро по вотерфолу будут работать отдельные мастодонты с предрешенным жизненным концом. Agile выиграл гонку. Microsoft улучшает поддержку agile в TFS и использует итеративную разработку на многих продуктах. IBM выпускает agile платформу Jazz. Даже SAP внедряет agile (хотел бы я на это посмотреть)
А вот цитата Вольфганга Гатнера, CIO of Deutsche Bank
«Мы должны двигаться вперед. Традиционные способы недостаточно быстрые. Они слишком сложны и препятствуют инновациям. Это однозначно ясно.»
По меньшей мере, практически все компании начинают понимать, что прежние подходы разработки ПО не работают. Они стараются изменить положение вещей и agile многим видится как лучшее на текущий момент решение. Но возникает вопрос, насколько радикально улучшает agile разработку ПО? Улучшает. Но не решает всех проблем. По прежнему выпускается ужасный отстой. По прежнему скорость разработки оставляет желать лучшего. По прежнему качество многих решений не выдерживает критики, кишит багами и дает о себе знать при каждом удобном и особенно не удобном случае.
Взять хотя бы недавнее падение Amazon серверов, продолжавшееся несколько дней. Наш сервер лежал почти неделю! Периодически вылетает скайп (особенно после покупки его компанией Майкрософт). Все помнят пляски с бубном, чтобы заставить его работать.
Периодически возникают проблемы с iOS. Например мой телефон после очередного апдейта отказывался уходить в режим ожидания и высаживал батарею за 8 часов, не говоря уже о случайных нажатиях и звонках. Это жутко раздражало. Я ждал фикса почти месяц!
Делать правильные вещи
Давайте пройдемся по трем фундаментальным проблемам разработки ПО. Главная задача — делать правильные вещи.
Что значит правильные? Это значит нужные, решающие конкретные проблемы, и решающие эти проблемы хорошо. На рынке существует несколько тысяч инструментов управления проектами. Сколько из них реально хороших? 10? 20? вряд ли больше 20.
Почему были созданы все эти жуткие монстры с кошмарным интерфейсом, которые истязают своих пользователей, изводят своих создателей и никак не хотят расстаться с жизнью по хорошему? Почему были созданы эти сотни простых как грабли тулов, которые делают одно и то же, отличаясь цветовой гаммой, платформой, и дизайном формы логина? У меня нет ответа. Но очевидно, что мир наводнен софтом, который никому не нужен, тупо скопирован с другого софта, раздражает пользователей своим интерфейсом и держит всех за дураков.
Одна из первых задач нашей индустрии — научиться делать правильный софт. Надо попадать в сердца людей первым релизом.
Делать вещи правильно
Какая же вторая задача? Вторая задача — делать вещи правильно.
Если мы делаем правильную вещь — это половина дела. Но если мы сделаем ее плохо, конечная цель не будет достигнута. Да, пользователь сможет решать свои задачи, но только быстро, от падения до падения системы.
Плохо написанный софт поразительно двуличен. Он вроде бы заявляет о том, что он хороший, и помощник, но на деле оказывается, что он старая развалина, в которой под настроение масло смешивается с антифризом, кондиционер работает только зимой, дворники — только в хорошую погоду, а при скорости 130 поскрипывает полуось. Но он прошел отличную предпродажную подготовку с помощью грамотных сейлс менеджеров и быстро ушел с молотка. А то, что кондиционер не работает, так кто ж его зимой включает. Да и больше 120 по нашим дорогам ездить нельзя, так что это багом не считается.
Несколько месяцев назад я попытался использовать программу OmmWriter. Минималистичный интерфейс для написания больших объемов текста. Расслабляющая музыка. Полноэкранный режим, скрывающий все, кроме текста. Мне программа понравилась и я начал ее использовать.
Однажды я написал большую статью практически в один присест. Около 5 страниц. Конечно, я часто сохранял ее. И конечно, я не сделал бэкап. На следующий день я пришел на работу, открыл бук и OmmWriter радостно завис. Я убил процесс, запустил OmmWriter заново и открыл документ. Он был пуст. Бывали ли у вас моменты, когда вы думали, что забыли выключить утюг? Вот и у меня пробежал холодок по спине, повысился уровень адреналина и ощущение непоправимого встало за спиной. Дрожащей рукой я нашел файл в Finder и проверил его размер — 0 байт. Это был последний день, когда я использовал OmmWriter. Программа, которая теряет мои данные, — теряет мое доверие. Недавно я купил очень похожую программу Byword. Она работает как часы. Я доволен.
Софт, написанный криво, крайне сложно развивать и менять под новые реалии жизни. Развитие такого софта обходится дорого и происходит медленно.
В свое время мы написали TargetProcess быстро. Так как писался он после работы и по выходным — главная задача была проверить идею, насколько она жизнеспособна. Юнит тестов было мало. Архитектура была слабенькая. Например, О/R фреймворк был выбран крайне неудачно. Никто не думал о масштабируемости и производительности. Но главная задача была достигнута — концепция доказала свою жизнеспособность. В итоге, все пришлось переписать с нуля и это заняло 8 месяцев работы фул тайм. В результате чего появился TargetProcess 2.0. Хорошо это было или плохо? С одной стороны, мы как бы потеряли 8 месяцев. С другой, проверили концепцию и убедились, что она работает.
Скорость
Мы плавно переходим к третьей проблеме — скорости.
Разработка ПО не успевает за пользователями. Сложность проектов возрастает — скорость падает. Фактор скорости становится все более и более важным для любой компании. Если мы делаем софт быстро, у нас есть возможность пробовать разные варианты, реагировать на изменения рынка, нащупывать правильный путь быстрее, чем другие. Если мы делаем софт медленно, у нас не будет второй попытки…
В индустрии появились свои легендарные долгострои, такие как Duke Nukem Forever.
Он стартовал в 1996 и был закончен в 2011 году. После нескольких сорванных дедлайнов разработчики перестали делать публичные оценки, а просто говорили, что игра будет выпущена «когда будет готова». К сожалению, Duke Nukem Forever так и не смог оправдать ожиданий геймеров. Геймспот дал игре оценку в 3.5. Игра получилась скучной, неоригинальной и устаревшей.
Какая медлительная страна! — сказала Королева. — Ну, а здесь,
знаешь ли, приходится бежать со всех ног, чтобы только остаться на том же
месте! Если же хочешь попасть в другое место, тогда нужно бежать по меньшей мере вдвое быстрее.
На самом деле нам надо бежать быстро, чтобы не отстать от других. Если мы хотим стать первыми, надо бежать быстрее, намного быстрее.
Любой процесс разработки ПО должен фокусироваться на этих трех проблемах и вообще лозунг любого хорошего процесса такой:
Делать правильные вещи правильно и быстро
Если мы делаем правильный продукт правильно, но медленно, мы можем упустить возможности, которые есть на рынке. Мы можем опоздать и реальность изменится настолько, что наш продукт будет мало кому нужен.
Если мы делаем правильный продукт быстро, но неправильно, мы столкнемся с проблемами развития продукта. Либо мы будем вставлять подпорки и костыли и похороним продукт лет через 10, либо перепишем его с нуля, что дорого.
Если мы делаем неправильный продукт правильно и быстро, то очевидно он мало кому нужен и успеха не будет. Разве что нам удастся понять, почему он неправильный и быстро изменить в нужную сторону.
В идеале мы должны попасть в центр.
Будущее гибкой разработки
Вот как выглядит картина эволюционного развития agile процессов в ближайшее время. По большому счету, все можно свести к двум основным трендам: скорость и масштаб.
Нам нужно научиться делать правильные вещи правильно и быстро в любых масштабах
Это фундамент.
Почему я вынес скорость как главную сущность? Под скоростью я понимаю время решения проблемы заказчика. Что будет, если мы сделаем не то? Придется переделывать или вообще отказаться от идеи. Что будет, если мы сделаем не так? Придется переделывать, чтобы двигаться дальше. Все переделки влияют на скорость самым негативным образом. Поэтому делать правильные вещи правильно напрямую ведет к увеличению скорости в долгосрочной перспективе.
Начнем со скорости. Скорость определяется двумя вещами: экспертизой и быстрой обратной связью.
Обратная связь
Почему обратная связь важна?
Шведский психолог по имени Андерс с оригинальной фамилией Эриксон проводил много экспериментов, связанных с обучением. В частности он заметил, что многие доктора теряют навыки после окончания обучения. Однако, хирурги являются исключением из правил. У хирургов есть постоянная обратная связь и четкие цели. У онкологов все сложнее. Когда онколог изучает снимки, он не знает наверняка, рак там или нет. Он узнает это только через пару недель, по результам биопсии. Или еще позже, через годы, когда станет ясно, что рака нет. Без немедленной обратной связи способности доктора ухудшаются со временем. Эриксон предложил новую модель обучения по старым историям болезней. Можно посмотреть снимки, сделать заключение и сразу получить ответ из реальной истории болезни. В этом случае интенсивность обучения возрастает в разы, за один день можно рассмотреть больше историй, чем за несколько лет обычной практики.
Обратная связь фундаментально позволяет узнать 2 вещи. Сделали ли мы то, что надо. Сделали ли мы это правильно. Мы хотим знать это как можно раньше. В идеале — сразу после выполнения задачи. Как узнать как можно раньше, что мы делаем правильную вещь? Решения два: скетчи и прототипы, быстрые поставки.
Скетчи решений
Скетчи являются мощным средством выяснения требований. Но скетчи не стоит понимать узко. Скетч — это быстрый способ эмуляции реальной системы. Иногда хватает наброска от руки.
А иногда необходимо строить не очень простую модель.
Несколько десятков лет назад компания IBM решила создать голосовой интерфейс управления компьютером. Огромное число пользователей мечтало приказывать операционной системе, а не тыкать в нее мышью. Проект чуть было не запустили, но решили проверить, а на самом ли деле пользователям это понравится? Скетч был простой. Приводили пользователя и сажали его за компьютер. Пользователь вдохновенно отдавал команды, в другой комнате сидел человек, который эти команды слышал и выполнял. Пользователь видел процесс и результат выполнения команды на своем мониторе. Гениально! В итоге большинству пользователей не понравилось так управлять компьютером, это было медленно и не особенно эффективно. Клавиатура и мышь победили, проект закрыли. Несложно себе представить, какие средства ушли бы на алгоритмы распознавания речи, встраивание голосовых команд в операционную систему и так далее. Просто скетч сэкономил много денег и помог принять правильное решение.
Развитие навыков скетчинга — очень важно для любого профессионала по разработке ПО и часто нам этого не хватает. Как происходит создание ПО сейчас? Собираются требования в один большой бэклог, выбираются важные юзер стори, и вперед рисовать UI и писать код. В лучшем случае будет сделан прототип, который в худшем случае разовьется в реальную систему. Этого однозначно недостаточно. На первом этапе команда должна убедиться, что собирается сделать правильную вещь. Да, это задача бизнеса. Но бизнес слабо представляет, как делать софт или проектировать UI. Он не может сам решить такую сложную задачу.
Бросаться с головой в новый проект и начинать делать его сразу, практически гарантированный способ выпустить посредственный продукт, который мало чем отличается от конкурентов. Если у вас есть только одно решение, поведение всей команды и процесс разработки предсказуемы, как пешеход.
Bill Buxton, Sketching the User Experience
На текущий момент практически не существует инструментов, позволяющих создавать быстрые прототипы систем. Все средства прототипирования ущербны и для создания прототипов средней сложности требуются недели. Это очень долго. В ближайшие годы должны появиться инструменты, позволяющие создавать интерактивные прототипы за считанные дни. Такое радикальное сокращение времени позволит ускорить обратную связь, протестировать несколько альтернативных решений и убедиться, что мы собираемся делать правильную вещь.
Continuous Delivery
Вторым способом ускорить обратную связь являются быстрые поставки. Поставка после каждого коммита — это просто супер-радикальная идея, которая сокращает обратную связь до предела.
Для конечного пользователя обычно это не представляет особого интереса. Зато для команды такой экстрим радикально меняет процесс разработки, заставляя серьезно поднять качество кода. Чтобы обеспечить CD компания должна серьезно поднапрячься.
CD включает в себя практически полную автоматизацию тестирования: юнит тесты, функциональные тесты, тесты на производительность, приемочные тесты. Сама поставка тоже должна быть автоматизирована. Такой уровень автоматизации требует серьезных трудозатрат и зачастую перестройку всего процесса разработки ПО, начиная от постановки требований и заканчивая отделом маркетинга. То есть затрагивается проблема масштаба, что усложняет ее внедрение.
Экспертиза
Перейдем к более человеческим материям. Софт пишут люди. Попытки поставить разработку софта на конвейер не увенчались успехом, что не удивительно. Сама индустрия разработки ПО находится в детском возрасте и только-только отпразновала появление вторичных половых признаков.
Люди обладают экспертизой и навыками решения проблем. Именно это нужно развивать и улучшать.
Знание предметной области
Знание предметной области помогает понять, правильную ли вещь мы делаем. Если вы знаете устройство автомобиля, то вряд ли согласитесь добавить к нему пятое колесо по центру. Если вы автомобиль видите впервые в жизни, ничто не взыграет у вас внутри при добавлении пятого колеса и вы сделаете это безжалостно и беспощадно.
Знание предметной области — один из основных провалов всех разработчиков ПО. Конечно, все так или иначе вникают в нее, но мало кто целенаправленно выделяет время на изучение. Когда я работал над софтом в страховом бизнесе, мне только через год пришло в голову почитать про устройство страховых компаний и узнать, чем Carrier отличается от Account в реальной жизни, а не только на уровне классов. Но если мне это пришло в голову, то никому из тех, с кем я рядом работал, вообще не пришло.
Обычно разработчику неважно, как там в реальном мире живет та или иная сущность. Ему важен набор бизнес-правил. Ему важно получить непротиворечивые требования и реализовать их. Ему важно сделать красивую архитектуру и написать чистый код.
Здесь инициатива целиком лежит на компании. Это именно ее задача организовать обучение по предметной области. Например, в нашей компании мы посылаем людей на конференции и настоятельно рекомендуем читать книги по agile project management, однако этого недостаточно. Все должны четко понимать, что мы делаем, зачем мы это делаем и почему именно это сейчас важно.
Команда, где хотя бы несколько человек обладают приличными знаниями предметной области, может на равных обсуждать с бизнесом его проблемы и придумывать решения. Доверие к такой команде повышается многократно. Вероятность того, что команда сделает не то, что надо, снижается. Значит повышается скорость разработки.
Craftsmanship
Более близкой сердцу программистов является концепция Craftsmanship. Суть концепции в улучшении качества решений и развитие профессиональных навыков. Craftsmanship практически полностью фокусируется на том, чтобы делать вещи правильно.
The only way to go fast is to go right.
Uncle Bob Martin
Для улучшения качества решений необходимо строить правильные архитектуры, иметь отличный test-coverage, не усложнять решения без причины.
Для профессионального развития делаются попытки применить методики тренировок спортсменов или практики восточных единоборств, такие как Coding Dojo и Coding Kata. Конечно, это большой вопрос, можно ли применить такие методики для тренировки программистов. Но в любом случае какие-то тренировки нужны. Если все время работать над продакшн кодом, можно решать одни и те же проблемы одними и теми же способами и вообще не развиваться. Похоже, действительно нужны занятия, направленные не на создание чего-то конкретного, а на оттачивание определенных навыков. Самым эффективным методом возможно является решение одной и той же проблемы разными способами, с использованием самых различных технологий. Постоянные улучшения текущей архитектуры тоже хороши. Нужно все время ставить под сомнение текущее положение вещей и пытаться улучшить решение, сделать его проще, гибче, понятнее.
Очевидно, что повышение сложности систем требует от людей многого. Сейчас уже нельзя просто знать C, структуры данных и алгоритмы. Сейчас надо знать ООП, паттерны, библиотеки, кучу смежных технологий и дисциплин. Объем необходимых знаний повышается с каждым годом. Однако уровень абстракции программирования за последние несколько лет не сильно изменился, тогда как сложность систем изменилась значительно. Архитектура Facebook или Twitter крайне сложна, я думаю, ни один разработчик там не представляет, как функционирует вся система целиком. Так что программист не имеет права прекращать обучение.
Решение проблем
Пожалуй, решение проблем — главный навык любого человека. Если он есть, вы без особого труда можете восполнять свои собственные пробелы и пробелы процесса разработки в компании, где работаете.
Посмотрите, как происходит ретроспектива практически в любой команде. Люди собираются, выдвигают какие-то проблемы, которые часто лежат на поверхности, и предлагают решения, которые тоже лежат на поверхности. Очень редко затрагиваются и решаются корневые проблемы. Очень редко предлагаются на самом деле нестандартные, классные решения. На таких собраниях практически не используются никакие инструменты выявления проблем. Системное мышление, ТРИЗ, техники брейнсторминга — большинство команд игнорируют все это, потому что не обладают навыками и знаниями. Программистов не учат системному мышлению. Программистов не учат ТРИЗ. Программистов не учат брейнстормингу. Программистов не учат нестандартному мышлению.
Техники решения проблем не изучаются ни в школе, ни в институте, ни в университете. Это просто невероятно! Один из главных навыков в профессиональной жизни не упоминается ни на одной лекции!
Сами программисты любят изучать все, что касается стратегии и тактики программирования, остальные вещи большинству разработчиков мало интересны. Программисты владеют алгоритмическим способом решения задач, но практически не владеют эвристическим, творческим способом. Задачи по улучшению процессов практически всегда сложные и творческие, которые невозможно решить с помощью алгоритмов. Задачи по созданию архитектуры также требуют творческого мышления.
Опытные тренеры пытаются привнести новые практики в ретроспективы, однако им далеко не всегда это удается. Часто они сами не являются экспертами в problem solving, часто не получается передать свои знания команде.
Agile надеется на самоорганизацию в командах. Значит команда сама должна выявлять и решать свои проблемы эффективно. Иначе она неизбежно будет наступать на одни и те же грабли. Однако, ни одна agile методология не содержит и не пропагандирует инструменты решения проблем.
Что интересно, в сфере дизайна и UX люди используют эти инструменты. Там это является чем-то обыденным, просто еще один набор рабочих инструментов. Разработчикам этого часто очень не хватает.
Отличный разработчик обязан обладать творческим, нестандартным мышлением. Ему необязательно уметь сочинять стихи, но писать связные, хорошие текста обязательно. Развивайте правое полушарие, господа!
Масштаб
Масштаб — серьезное испытание для agile процессов. В основном проблема масштабируемости касается компании в целом и распределенных команд.
Компания в целом
Agile неплохо работает на уровне отдельных команд. Отдельно взятая команда действительно может серьезно улучшить свою эффективность, перейдя на Scrum + XP или Kanban. Но если вы попытаетесь развить идею на всю компанию, очень часто это встретит серьезное сопротивление и непонимание.
В первую очередь agile вступает в противоречие с корпоративной культурой многих компаний. Базовые принципы agile, такие как прозрачность, доверие, скромность — мир бизнеса встречает с недоумением. Прозрачность? Доверие? Скромность? Хммм… Во многих компаниях царят политические игры, карьеризм, хвастовство и некомпетентность. Для таких компаний agile воспринимается как вирус, который угрожает сломать существующий строй.
Agile стремится нарушить гомеостазис традиционной компании и выносит на поверхность все подводные течения, скрытые недостатки, и все, что не тонет в воде при нормальных условиях.
Даже если у компании все хорошо с прозрачностью и доверием, остаются достаточно сложные проблемы. Отдел HR должен изменить свой подход к найму людей и подбирать тех, кто подходит не только по скилам, но и под культуру компании. Отдел маркетинга должен придумать, что ему делать с частыми релизами. Отдел дизайна должен понять, как включить себя в команду разработки. Топ менеджмент должен понять, как организовать взаимодействие между многими agile командами в рамках всей компании. Все это очень сложно и на многие вопросы вообще пока нет ответов. Большие компании только начинают реорганизационные процессы с учетом agile.
В последнее время активно соединяются UX команды и команда разработки. Тут есть серьезный прогресс.
Что касается взаимодействия многих команд — тут все гораздо печальнее. Scrum of Scrum показал свою полную неработоспособность. Никаких четких механизмов пока нет, каждый наступает на одни и те же грабли и изобретает свой велосипед.
Распределенные команды
Давней проблемой agile является глобализация. Развитие интернета привело к появлению распределенных команд. Есть компании с офисами в десятках странах мира, которым приходится синхронизировать работу сотен людей. Так как agile родился на уровне co-located команды, у него изначально серьезные проблемы с командами распределенными. Непрерывная коммуникация и сокращение обратной связи затруднительно, когда продукт оунер просыпается в 9 утра, а разработчики сонно появляются на работе в 4 вечера.
Решение данной проблемы сложное и в первую очередь должно осуществляться с помощью увеличения насыщенности коммуникационных каналов. Прямая постоянная видео-связь между офисами — лучшее решение. Всегда приятно видеть сегодняшнее настроение на небритой роже и знать, можно ли сейчас человеку вопрос задать, или лучше подождать.
Также появляются и развиваются средства для удаленного парного программирования, брейнсторминга и тестирования. Такие инструменты как TargetProcess неизбежны для любой распределенной команды.
Заключение
Главная задача индустрии разработки ПО — попасть в центр. Научиться делать правильные вещи правильно и быстро.
Я уверен, что это возможно. Для этого необходимо (в порядке убывания приоритета):
- изучать техники решения проблем, такие как ТРИЗ, развивать нестандартное мышление и системное мышление
- сокращать время обратной связи всеми способами
- изучать предметную область
- научиться масштабировать agile-mindset на всю компанию и на распределенные команды
P.S. Да, я знаю, что статья большая. Но бить ее на части не вижу смысла.
