Будущее гибкой разработки ПО


    Программное обеспечение проникает во все щели человеческого общества. Мы узнаем погоду через интернет, а не через обычный градусник за окном. Мы едем по новому адресу с навигатором, а не ищем квадрат 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. Да, я знаю, что статья большая. Но бить ее на части не вижу смысла.
    Taucraft Limited 41,54
    Компания
    Поделиться публикацией
    AdBlock похитил этот баннер, но баннеры не зубы — отрастут

    Подробнее
    Реклама
    Похожие публикации
    Комментарии 80
    • +13
      Превосходная статья! Это ваша или перевод?
      • +23
        Моя
        • +11
          На одном дыхании, от и до, и пофиг что там простыня. Хабр торт!
          • 0
            Отличная статья, лучшая из последних которые читал. Продолжение будет?
            • 0
              А что бы вы хотели увидеть в продолжении?
              • +1
                Как вариант: сравнение Scrum и Kanban, для каких команд и проектов подходит та или иная методика. Как правильно их внедрять с нуля, основные ошибки и подводные камни при внедрении. Как будет выглядеть работающая система на стеке Visual Studio и TFS (можно и что-то полегче, например TeamCity + YouTrack), в этом плане лучше всего будет смотреться схема в стиле cheatsheet.
                • 0
                  В интернетах это все уже есть.
                  • 0
                    В интернетах сравнения обычно пишут приверженцы одной из методик, особо не зная другую (особенно изнутри). Процесс внедрения описан либо поверхностно, либо слишком специфично. Опять же пишут либо те кто работает на готовой системе, либо внедрял не более одного раза, не в полном объеме или на однотипных проектах. Хотелось бы узнать именно про реальный опыт и извлеченные уроки, возможно что видение тех кто делает такие системы и тех кто их использует расходятся. В любом случае мое дело предложить…
                    • 0
                      >> В интернетах сравнения обычно пишут приверженцы одной из методик…
                      а статью от этого автора мы можем получить как от приверженца вполне конкретного инструмента
                      • 0
                        Вы меня плохо знаете. Я крайне непредвзят в подобных темах. И инструменты, скажем, для начала внедрения agile я всегда советую брать такие: большая белая доска, маркеры и стикеры. Если команда большая или распределенная, тогда можно пробовать тул типа нашего. Или если команда сама поняла, что тул ей нужен, и точно знает зачем.
          • +1
            Если ваша то почему картинки на англицком? =)
            • +1
              Михаил как правило на английском пишет, рекомендую ознакомиться с блогом:
              targetprocess.com/blog/
              • +1
                Чтобы для английского поста не перерисовывать.
              • 0
                Интересно, на западных сайтах публикую переводы русскоязычных статей? Я бы дал на такую статью ссылку своему менеджеру…
                • 0
                  В ближайшем будущем появится перевод. Думаю недели через 2-3
            • +5
              Очень много воды и очевидных вещей. Вот в конце хорошие тезисы перечислены. Если бы статья последовательно раскрывала бы каждый из них, было бы лучше, мне кажется. А так всё как-то намешано.
              • +4
                Не согласен. Статья получилась такая, которую может осилить и не-разработчик. А это ведь очень важно, чтобы остальные понимали, что работа программиста — это не «ТЫ ПРОГРАММИСТ ТЫ СКОЛЬКО СЕГОДНЯ ПРОГРАММ НАПИСАЛ?!?».
                • +2
                  Вода вначале нужна для правильного фокуса. И я пожалуй соглашусь, что многие вещи очевидны в первой половине. Но очень часто люди сбиваются на мелочи, которые не важны, и теряют фокус на таких важных вещах, а вообще то ли мы делаем?

                  Если раскрывать глубже, то это уже книга получится :)
                • +7
                  image
                  А может быть, там такое пересечение?
                  • +7
                    То, что вы написали, не имеет никакого отношения к правильному продукту. Мы можете сделать все быстро, качественно и дешево — но это никому не надо.
                    • +1
                      Это для примера. У Вас 3 категории: правильное, правильно сделланное и сделанное быстро. Часто оказывается, что пересечения в этом нет. Или оно может быть, но для этого надо затратить время, подготовить инструментарий (библиотеки, IDE). Но тогда это уже не будет быстро. Может, повезёт следующим заказчикам, которые придут, а у Вас инструментарий будет. Но чтобы он был, надо с чего-то начать… Замкнутый круг. Или бутстреппинг, если человек — оптимист :).
                      • +4
                        Мне кажется, я вас понимаю, но дело не в этом. Текущее положение вещей в индустрии таково, что дело не в инструментах и библиотеках (в них тоже, но это менее важно), а в подходах к выяснению требований и выработке лучших решений. Дело в качестве решений на всех уровнях (UX, Development). Нужно менять процесс.
                        • –1
                          Инструменты и библиотеки (и не только они, но и языки, и принципы организации работы команды, и методы управления проектом) — это ко второму кругу относится, к вопросу «как сделать?». А то, что Вы назвали «в подходах к выяснению требований и выработке лучших решений» — это Ваш первый круг, отвечающий на вопрос «Что сделать?». И то, и другое важно. Первое — очевидно, в первую очередь.
                          • 0
                            Не совсем. Качество решений важнее инструментов при ответе на вопрос «как сделать». Инструменты, языки — вторичны.
                        • +1
                          Кстати, это Venn диаграмма
                          en.wikipedia.org/wiki/Venn_diagram
                          Она просто показывает возможные зависимости. На самом деле пересечений может и не быть. Некоторые компании делают медленно, плохо и не то, что надо. Они вообще за всеми кругами :)
                          • 0
                            В том что Вы написали тоже чаще всего нет пересечения. «Мы делаем быстро, качественно, недорого. Выбирайте любые два условия» (с) не помню кто сказал.
                      • +1
                        конечно. на фрилансе это проекты (примерное 90% от общего числа таких проектов) с заголовками «Доработать проект...», «Выполнить правки...», «Маленький проект на 2 часа».

                        правда заказчик думает, что эти круги не то, что пересекаются, даже совпадают.
                        а на самом деле там всё как на картинке.
                      • +7
                        Отличная статья, спасибо автору! «Знай предметную область!!!» вообще на транспарант и на стену.
                      • +5
                        В конце концов всё упирается в человеческие взаимоотношения.
                        Принципы agile [...] мир бизнеса встречает с недоумением. Именно!
                        • 0
                          > изучать техники решения проблем, такие как ТРИЗ

                          Можете какой-нибудь веб-ресурс порекомендовать по теме? Или книгу бумажную.
                            • 0
                              Основной ресурс, который встречал, когда первый раз услышал о ТРИЗ:
                            • +3
                              Интереснее было бы почитать об опыта решения проблем с помощью ТРИЗ, т.к. сколько не читал про него, кроме красивых слов ничего толком и не нашел.
                            • +6
                              programming-motherfucker.com тут предлагают 100% работающую альтернативу Agile :)
                              • 0
                                Супер статья. Очень доходчиво. Спасибо
                                • 0
                                  Очень интересная статья.
                                  Но есть одно но: такое многообразие софтового безобразия существует ещё и потому, что правильность — понятие весьма и весьма относительное. К сожалению )
                                  • 0
                                    Относительно. Но не весьма и весьма, а просто относительное. Думаю, пару десятков вариантов музыкальных плейеров покроют любые потребности в различиях. Но их существует гораздо больше. И многие ничем особо не отличаются. Нужно уходить от этого. Рано или поздно естественный отбор сделает свое дело, но хотелось бы раньше это уметь предвидеть и не выпускать очередной плагиат или отстой.
                                    • +1
                                      Многообразие разных немного-различающихся программ похоже на эволюцию живых существ.
                                      Эволюция программ идет тем же «естественным» путем — огромного количества проб и ошибок.

                                      Не вижу способа как можно от этого уйти, не запрещать же людям кодировать и придумывать, если мы их считаем недостаточно способными :)

                                      • 0
                                        Все так и есть, но можно и нужно сокращать количество «левых» попыток создать нормальный софт. Нужно не только языки программирования учить, но и то, что я перечислил выше. Это поможет. Для инноваций не нужно то количество плагиата и шлака, что есть сейчас.
                                        • 0
                                          > Не вижу способа как можно от этого уйти, не запрещать же людям кодировать и придумывать, если мы их считаем недостаточно способными :)
                                          Почему бы и нет? Михаил таких людей просто увольняет :) Или старается не нанимать.
                                    • +2
                                      Хорошая статья. Автор довольно глубоко описал проблематику разработки высокоуровневого программного обеспечения. Здорово, когда куча автоматизированных средств позволяет тестировать все «на лету».

                                      Получается такое бесконечное прототипирование с постепенно улучшающимся качеством. Благо падение скайпа или iPad пока приносит лишь временные неудобства.

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

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

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

                                        Скорее всего да. Просто для таких систем уровень надежности — приоритет номер один. И скорее всего не стоит использовать Continuous Delivery для mission-critical приложений. Но 80% софта пишется для решения бизнес задач и всяких казуальных задач, а там это уже не так критично.
                                      • +2
                                        image
                                        не по теме, но на вашем профиле хабр что-то заглючило 0_о
                                        • +3
                                          Почему же не по теме? Вполне себе относится к качеству :)
                                          • +1
                                            2^32
                                            • 0
                                              2^32 + 95
                                              • +4
                                                Видимо 9zloy удалось удалить вакансию, не опубликовав её :-)
                                                -1 вакансия (-1 представлено в виде 0xFFFFFFFF == 2^32-1) + 4 статьи + 92 комментария
                                                • 0
                                                  Я гляжу баг вызвал здоровый энтузиазм выявить его причину. Такое впечатление, что хабр специально сохранил пару десятков багов, для поддержки разговоров в топиках.
                                            • –1
                                              Хорошая динамика по карме ))) За такие статьи иногда хочется в карму да побольше дать… Но никак ) Спасибо автору
                                            • 0
                                              Интересная статья, однако я не понял следующего, это рекомендации или шаги к действиям?? Т.е насколько это используется в работе?? Допустим, Вы сказали:
                                              Для профессионального развития делаются попытки применить методики тренировок спортсменов или практики восточных единоборств, такие как Coding Dojo и Coding Kata.

                                              Вы применяете эти методики или нет? И если применяете, то в рабочее время?? И как относятся к этому программисты?
                                              Спасибо.
                                              • +4
                                                Шаги? Изучать ТРИЗ. Развивать правое полушарие. Изучать предметную область. Учиться решать проблемы разными способами. Изучать UX.

                                                Мы пробовали Coding Kata один раз. Было прикольно, но задача попалась сложная и не закончили. Это было в рабочее время. Вообще у нас на обучение каждому человеку выделяется 5 часов в неделю. Кроме того проводятся внутренние конференции, воркшопы и так далее. Все это в рабочее время. В целом примерно процентов 15-20 рабочего времени уходит на развитие и обучение.

                                                Я не утверждаю, что Coding Dojo это единственный способ улучшить скилы. Я не знаю. Но он имеет потенциал на мой взгляд.

                                                Из того, что мы активно делаем, это изучение предметной области, UX, craftsmanship, Continuous Delivery внедряем (пока еще до коммитов не дошли, но через полгода думаю дойдем). ТРИЗ только сейчас начали активно изучать. Решение проблем пока оставляет желать лучшего, но все же раньше было гораздо хуже :)
                                              • +1
                                                Мне кстати TargetProcess2 очень понравился. Хотел протолкнуть своим менеджерам (мы как раз на agile/scrum переходим), так они уперлись в GreenHopper. GreenHopper конечно штука классная, но для неё надо Джиру апгрейдить, а с нашими кастом плагинами это произойдет еще нескоро…

                                                Но зато для своих проектов, я начал использовать и мне очень нравится :) Одно только непонятно, как интегрировать юзерстори в спекфлоу, чтобы достичь полной нирваны. :)
                                                • 0
                                                  Мы кстати тоже BDD используем, только NBehave. Идея сделать интеграцию хороша, но пока не продумывали мы это.
                                                  • 0
                                                    В принципе, это можно реализовать ввиде экспорта эпиков в Gherkin. А уж оттуда можно просто скопипастить в окно студии. Правда для этого потребуется более явная поддержка BDD, а сейчас юзерстори не предполагает какой-то определенный формат.
                                                  • 0
                                                    менеджеры — они такие :)

                                                    стоит им дать выбор между Atlassian и ..Taucraft (если не ошибаюсь) — и выбор в пользу более известной, стабильной, опять же надежной (о чем и в статье речь) компании — становится очевиден…
                                                  • 0
                                                    На следующий день я пришел на работу, открыл бук и OmmWriter радостно завис.

                                                    По интерфейсу сразу видно, OmmWriter делал UX специалтст с развитым правым полушарием, lol.
                                                    • 0
                                                      этот OmmWriter вообще на любителя. Ошибки он не подчеркивает, а слегка выделяет цветом. Из шрифтов только русские рубленые типа Arial. И еще играет музыку :)
                                                      • 0
                                                        И еще может убить весь текст, который был в нем набран.
                                                        Набирал в нем как-то, сохранил, открыл — а там знаки вопроса вместо русских букв, причем код символа везде одинаковый.
                                                    • +1
                                                      Действительно превосходная статья! По-настоящему про Agile. Огромное спасибо!
                                                      • 0
                                                        И вам спасибо, что прочитали.
                                                      • +4
                                                        Пару слов про скетчи и пример с голосовым управлением: Лет пять (или больше?) назад компания N решила открыть производство холодного чая в Китае. Провели жарким летним днём тесты, пригласили кучу участников и напоили их холодным чаем. И почти все китайцы в один голос заявили, что холодный чай — отстой, и покупать они его не будут. Компания N закрыла свой проект и порадовалась, что не слила кучу бабла.

                                                        Через годик компания X тоже захотела выпустить на китайском рынке холодные чаи. Делать маркетинговые исследования им ума не хватило, поэтому они открыли производство и начали продавать чай в милых бутылочках. Окупились они всего за год, став главными игроками рынка и заработав какое-то просто немыслимое баблище.

                                                        Почему так происходит? Причин несколько:
                                                        — прототипы (чай или управление из соседней комнаты) не всегда передают того, каким на самом деле окажется продукт.
                                                        — пользователям иногда нужно время, чтобы понять и принять продукт
                                                        — не все умеют проводить и анализировать исследования :)
                                                        • 0
                                                          По таргет процессу

                                                          TP Tray

                                                          Было бы круто если из него можно было бы сразу баг назначать на разработчика и ставить QA.

                                                          А то сейчас приходится все равно приходится после него открывать баг и через сайт ставить разработчика и тестера.
                                                          Вообще таргет процесс очень нравится. И руководство кампании идет на встречу молодым стартапам.

                                                          • 0
                                                            У нас около 2000 запросов на улучшение. Идея хорошая, но не думаю что в этом году будет реализована.
                                                          • 0
                                                            Отличная статья! Читается на одном дыхании и содержит много полезных идей и рассуждений. Мне близки твои взгляды и приятно знать, что ТаргетПроцесс им следует и делает это успешно.
                                                            В принципе я с большинством пунктов согласна, но мне кажется, что местами ты частный опыт распространяешь на индустрию в целом.

                                                            Приведу несколько примеров. Допустим, знание предметной области. Бесспорно знание командой предметной области софта это огромный плюс. Не только с точки зрения, что это помогает предлагать идеи и эффективные решения. Но даже банально потому, что не понимая предметной области сложно реализовать функциональность правильно и проверить, что она решает поставленную задачу. Но порог вхождения в разные предметные области может быть различным. Мне пришлось столкнуться с двумя предметными областями, которые я так и не осилила. Первая была связана с добычей нефти, там я ничего не поняла, кроме того, что все должно работать по нужным формулам, но я и не пыталась. Второй мой неудачный опыт был связан с грузоперевозками. Вот там я пыталась, даже общалась локально (клиент был из США) с представителями этого бизнеса, чтобы понять о чем говорит заказчик. Но проект был не длительный (чуть меньше года) и хорошо понять бизнес заказчика мне так и не удалось. Наверное клиент был не прав, он должен был помочь команде понять его бизнес. С другой стороны это была маленькая компания, которой нужно было автоматизировать их бизнес процессы. Софт пишется для бизнеса, и бизнес решает сколько инвестировать в софт, чтобы это имело смысл, ну вот они решили инвестировать мало.
                                                            Теперь возьмем ТРИЗ и другие практики для генерации нетипичных решений. А везде ли они нужны? Существует много типичных задач. Возьмем тот же банальный e-commerce. Да, наверное и там можно внедрить какое-то инновационное решение, а надо ли?
                                                            Другими словами, есть бизнес, основной доход, которому приносят не технологии, а продукты и услуги. Нужны ли им в зоопарке все эти навороты настолько высококвалифицированные специалисты?

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

                                                            Собственно бизнес он очень разный, и решения о роли ИТ в нем, каждый бизнес принимает по-своему, исходя из финансовых возможностей и приоритетов. В любом случае, если делать правильные вещи правильно и быстро, это должно принести хороший результат. Но что для этого нужно на мой взгляд все же не так однозначно.
                                                            • 0
                                                              Уже сейчас многие аутсорсеры имеют специализированные подразделения вертикальной интеграции в бизнес заказчика. У вас банковская сфера? Вот у нас отдел G этим занимается. У вас турфирма? Вам в отдел U. Эта тенденция только усилиться. Чтобы делать эффективные решения — нужно знать предметную область. Простая конкуренция. Через пару десятилетий не останется фирм, которые берутся на все и не имеют специализации.

                                                              Я нигде не употребил слово нетипичные решения, а употребил нестандартное мышление. Если у вас есть проблема, можно ее сразу решить в лоб. Почти всегда это не лучшее решение. Если немного подумать, и взять второе, оно тоже обычно не лучшее. Если есть творческое мышление, проблема может быть решена быстрее, эффективнее и лучше. Паттерны не всегда работают. Решать по шаблону может любой, вот и получаются все эти штамповки одинаковые. Творческие люди нужны любой компании, даже выпускающей молоко или табуретки. Не говоря уже об АйТи.

                                                              >Существует много типичных задач. Возьмем тот же банальный e-commerce. Да, наверное и там можно внедрить какое-то инновационное решение, а надо ли?

                                                              Надо. Обязательно надо. Только так можно что-то улучшить и изменить в этом мире. Дизайнеры стульев до сих пор их улучшают и совершенствуют. Стульям хер знает сколько сотен лет. Е-коммерсу сколько лет? 20? И нам не надо в нем ничего улучшить и изобретать? Да ладно!

                                                              > каждый бизнес принимает по-своему, исходя из финансовых возможностей и приоритетов

                                                              И что? Если бизнес считает, что айти ему не сильно надо, то он обязательно прав? Те, кто считали конвейер нелепым изобретением, давно канули в лети. Очень скоро никакой бизнес не сможет обойтись без серьезных инвестиций в информационные технологии. На запада это УЖЕ наступило. Для всех это приоритетно и важно.
                                                              • 0
                                                                Дизайнеры стульев просто меняют внеший вид стула. Принцип действия и юзкейсы стула не менялись с момента изобретения. То-же и с е-комерс.
                                                            • 0
                                                              >> Я нигде не употребил слово нетипичные решения, а употребил нестандартное мышление
                                                              Да, не права.

                                                              >> Надо. Обязательно надо. Только так можно что-то улучшить и изменить в этом мире. Дизайнеры стульев до сих пор их улучшают и совершенствуют. Стульям хер знает сколько сотен лет. Е-коммерсу сколько лет? 20? И нам не надо в нем ничего улучшить и изобретать? Да ладно!

                                                              Почему обязательно надо? Имеет смысл, если это даст конкурентное преимущество.

                                                              >> И что? Если бизнес считает, что айти ему не сильно надо, то он обязательно прав? Те, кто считали конвейер нелепым изобретением, давно канули в лети. Очень скоро никакой бизнес не сможет обойтись без серьезных инвестиций в информационные технологии. На запада это УЖЕ наступило. Для всех это приоритетно и важно.

                                                              То что бизнес обязательно прав, я не писала. Но любой бизнес расставляет приоритеты во что инвестировать бОльше в рекламу, в ИТ, что-то третье. На западе кстати тоже компании разные есть, хотя у них роль ИТ в бизнесе гораздо выше, чем у нас.
                                                              • 0
                                                                >Имеет смысл, если это даст конкурентное преимущество.

                                                                Фишка в чем. Если творчески подходить к решению проблем, это всегда даст конкурентное преимущество. Под творчеством в данном случае я понимаю не просто витание в облаках и удовлетворение личных амбиций разработчика, а реально классное решение проблемы. Я не верю, что нельзя улучшить обычный сайт по продаже книг. Однозначно можно и скорее всего в разы.
                                                                • 0
                                                                  Но вопрос ведь еще и в том, чтобы решить проблему быстро. Если взять не самое оптимальное решение, пусть это в лоб, пусть это не самое лучшее решение, но его можно быстро сделать и книжки сразу продавать. А можно потратить время на поиск более оптимального решения (я кстати тоже не про код, я скорее про UX сейчас говорю), но пока ищешь народ уже закупит себе целую библиотеку у конкурентов. Или сделаешь ты хорошее решение, более удобное для конечного пользователя, чем у конкурентов, а конкуренты возьмут и цены низкие поставят на свои книжки. Пользователи полюбуются немного на твое изящное решение и метнутся сметать книжки с полок конкурента.
                                                                  Нужно развивать творческое мышление, нужно уметь проверять решение на понятность и все такое. Я ж тока за. Я пытаюсь понять, где баланс.
                                                                  • 0
                                                                    А если я книжки буду продавать, как все. Сделаю сайт, как у большинства конкурентов, зато я вложу деньги в более качественный customer support, если смогу наладить процесс доставки более эффективный, если я буду в каждый заказ с книжками вкладывать карандашики в подарок, мне это выгоднее будет или нет?
                                                                    • 0
                                                                      Важны не преимущества, это мимолетные достижения, которые быстро перекроет кто-то другой, а инновационные решения в сфере, тогда преимущества будут всегда на высоте. Нужно именно вкладывать инвестиции в поиск инновационные решения, а не в поиск отличий от других компаний, чем кстати большинство компаний и занимается.
                                                                    • 0
                                                                      Я с тобой совершенно не согласен. Конечно, важна совокупность. И цена, и все остальное. Но это все факторы, которые легко копировать. Сложно копировать творческий потенциал команды. С такой командой ты всегда будешь впереди всех.
                                                                      • 0
                                                                        >> Сложно копировать творческий потенциал команды. С такой командой ты всегда будешь впереди всех.

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

                                                                        Что я пытаюсь для себя понять. Так это будет ли действительно одинаковое будущее во всем ИТ. Грубо говоря все, что ты описываешь это первоочердные вещи для бизнеса, в котором ИТ является двигателем. Это допустим ТаргетПроцесс, ну и многое другое. :)
                                                                        Есть же ИТ, которое является скорее обслуживанием нудж бизнеса, это всякие внутренние системы. Или возьмем теже банкоматы. Кто-то же пишет под них софт? Они неудобные, но зп от этого люди не перестают снимать с карточек, таким образом банку это не первый приоритет. Мне кажется отсюда (из таких отраслей) исходят мнение, что в Ит ваще нет никакого творчества, и все это просто рутинная механическая работа и ты ды.
                                                                        Мне интересно порассуждать произойдет ли из-за разной роли ИТ в бизнесе расслоение в будущем развитии индустрии (в процессах разработки, обучение специалистов). Было интересно твое мнение, а ты защищаешь свою позицию, с которой я не спорю. Потому что мне она нравится, и я считаю ее правильной для себя. :)
                                                                        • 0
                                                                          Так это уже происходит. Аутсорсинговые компании и продуктовые компании разные, у них разные подходы ко многим вещам. Это неизбежно случается прямо сейчас.
                                                                          • 0
                                                                            Да, но разница может сокращаться, а может расти. Продуктовые и аутсорсинговые они тоже разные бывают. Сам выше писал, что есть аутсорсинговые, которые создают у себя центры компетенций, все же левел-ап. То есть аутсорс он может либо просто отставать, а может деградировать.
                                                                            Но я считаю, что аутсорс это все же сервис. И от заказчика во многом зависит его качества, какие требования он предъявляет к исполнителю, такой и результат получает. В свою очередь аутсорс может (и должен) сам повышать качество сервиса, пытаться работать с бизнеса клиента, как со своим. Но вот хочет ли этого заказчик? Нужны ли ему инновации, или все-таки ему дешево и быстро.
                                                                • 0
                                                                  Почему были созданы все эти жуткие монстры с кошмарным интерфейсом, которые истязают своих пользователей, изводят своих создателей и никак не хотят расстаться с жизнью по хорошему? Почему были созданы эти сотни простых как грабли тулов, которые делают одно и то же, отличаясь цветовой гаммой, платформой, и дизайном формы логина?
                                                                  Потому что 90% всего — это барахло, в полном соответствии с законом Старджона :-)

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

                                                                  Самое читаемое