Компания, как единое целое

Зеленый – полностью переделанный кусок текста

Синий – текст переделанный наполовину

Коричневый – не переделанный текст

Настоящее и будущее средств разработки

Будущее средств разработки, какое оно? Полностью визуальное, при котором программисту надо будет лишь передвигать типовые блоки, или же полностью текстовое, времён эпохи машинных кодов, или нечто усреднённое, взявшее лучшие черты из предыдущих стилей? Программы проникают во все разделы человеческого общества. Нам проще посмотреть погоду в интернете, чем встать и посмотреть на градусник. В нынешнее время гораздо проще посмотреть маршрут в телефоне, чем использовать карту. Мы пользуемся программами каждый день, даже не замечая этого.

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

Взглянем на три основные проблемы в разработке программного обеспечения.

Создавать правильные вещи

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

Создавать вещи правильно

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

Скорость

Разработчики ПО зачастую не успевают за пользователями. С каждым разом проекты становятся все сложнее, из-за этого уменьшается скорость. Скорость становится одним из самых главных факторов для разработки в компаниях. Делая ПО быстро, существуют различные возможности, например, найти верный путь быстрее других. Но затягивая разработку, есть огромный шанс на то, что второго раза не будет.

Всякой разработке ПО необходимо иметь в виду эти проблемы. А лозунг должен быть таким: Создавать правильные вещи правильно и быстро.

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

Вот как выглядит эволюция agile процессов на текущий момент. По большому счету, все можно свести к двум основным направлениям: масштабу и скорости.

Говоря иначе, нужно правильно и быстро независимо от масштаба создавать верные решения.

Это база. Первый фактор это скорость. Скорость базируется на двух понятиях: экспертизе и быстрой обратной связи.

Обратная связь

В чём значимость обратной связи? Обратная связь отвечает за две 2 вещи. Сделали ли мы то, что надо. Сделали ли мы это правильно. И чем раньше мы это узнаем, тем лучше. В идеале — сразу после выполнения задачи. Как узнать, как можно раньше, что мы делаем правильную вещь? Решения два: скетчи и прототипы, быстрые поставки.

Скетчи решений

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

Начинать новый проект без подготовки, практически полная гарантия выпуска некачественного продукта, который во многом будет копировать решения конкурентов. Если команда не может предложить больше одного-двух решений, то вы предсказуемы, что непременно будет использовано конкурентом. (Bill Buxton, Sketching the User Experience)

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

Continuous Delivery

Второе решение, ускоряющее обратную связь - быстрые поставки. Поставка после каждого изменения в программном коде — это идея, сокращающая обратную связь до минимума.

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

CD представляет собой практически полную автоматизацию тестирования: юнит тесты, функциональные тесты, тесты на производительность, приемочные тесты. Сама поставка тоже должна быть автоматизирована. Такой уровень автоматизации неосуществим без серьезных трудозатрат и, как показывает практика, без перестройки всего процесса разработки ПО, начиная от постановки требований и заканчивая отделом маркетинга. Иначе говоря меняется масштаб, что создаёт дополнительные трудности при внедрении CD.

Экспертиза

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

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

Знание предметной области

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

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

Концепция мастерства

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

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

Преодоление трудностей

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

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

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

Масштаб

Компания, как единое целое

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

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

Отдельные команды

Глобализация - существенная и давняя проблема agile. Изначально команды были совмещёнными - их члены находились в одном месте. Но в ходе развития интернета возникло множество команд, члены которых находятся на значительном удалении друг от друга, зачастую на разных концах земного шара. И, как следствие, большой проблемой является синхронизация их деятельности. Так как зачастую члены команды живут в разных временных зонах, что на порядок затрудняет непрерывную коммуникацию и сокращение обратной связи.

Решение этой проблемы достаточно трудоёмко, но его суть состоит в увеличении насыщенности инфокоммуникационных каналов. Лучшим решением будет обязательная видеосвязь офисов и членов команды друг с другом.

Заключение
Главная задача индустрии разработки ПО — найти баланс между тремя краеугольными камнями - делать правильные вещи, делать их правильно, делать их быстро. Данный баланс достигается с помощью выполнения следующих факторов:

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

· сокращать время обратной связи всеми способами

· изучать предметную область

· научиться масштабировать agile-mindset на всю компанию и на распределенные команды

Ссылки:

URL: https://ru.wikipedia.org/wiki/Теория_решения_изобретательских_задач

URL: http://agilerussia.ru/

URL: http://habrahabr.ru/company/taucraft/blog/124241/

URL: https://en.wikipedia.org/wiki/Software_craftsmanship

URL: https://en.wikipedia.org/wiki/Lateral_thinking

URL: http://www.ccc.ru/magazine/depot/99_08/read.html?0801.htm

URL: http://citforum.ru/SE/project/scrum/

Поиск по сайту: