что такое серебряная пуля в ит

SilverBulleters, LLC

Silver Bulleters, LLC создана в 2014 году. Компания заняла нишу специализированного разработчика сложных ИТ-решений на стыке продуктов компаний 1С и мировых open source инструментов.

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

SilverBulleters, LLC запись закреплена

Знакомство с КафкаКоннектор версии 1.0

«Мы строили, строили и наконец построили. Ура!» (с)

Пара примеров интерфейса:
* настройка подключения к кластеру Kafka
(https://blog.silverbulleters.org/content/images/2021/..)* настройка синхронизации объекта и его «схема»

(https://blog.silverbulleters.org/content/images/2021/..)Почему за основу транспорта сообщений выбран именно Apache Kafka?

* возможность хранения сообщений после их получения;
* тонкая настройка под каждый поток данных;
* масштабирование из «коробки»;
* высокая пропускная способность.

Сейчас в подсистеме есть:

* регистрация объектов для обмена (справочники, документы, записи регистров);
* построение схем данных по выбранным объектам обмена;
* автоматический обмен и обновление схем данных;
* настройка регламентных заданий отправки/получения;
* ведение журнала отправленных/полученных сообщений.

В планах на следующие релизы:

* поддержка Avro формата;
* кастомное создание topic прямо из 1С;
* поставка подсистемы в виде расширения (регламентные задания тоже будут работать );
* интеграции из «коробки»:
* версионирование истории изменения объектов;
* логирование.
* мониторинг через Zabbix / Prometheus.

По всем вопросам пишите нам на b2b@silverbulleters.org или в Intercom на нашем сайте (https://silverbulleters.org/).

P.S. А сколько вы тратите времени на внедрение обмена данными?

SilverBulleters, LLC запись закреплена

Проверка качества кода 1С

Функция должна заканчиваться возвратом

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

Можно написать такой код:

Функция Тест()
Сообщить(«Привет, мир!»);
КонецФункции

и он успешно пройдет валидацию компилятора, несмотря на отсутствие оператора «Возврат». В случаях когда в функциях отсутствует явный оператор «Возврат», платформы 1С скрыто добавляет возврат значения «Неопределено». То есть код выше на самом деле выглядит так:

Функция Тест()
Сообщить(«Привет, мир!»);
Возврат Неопределено;
КонецФункции

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

МассивБанковскихСчетов = Новый Массив;
ПолучитьБанковскиеСчета(Организация, Банк, МассивБанковскихСчетов);
Если МассивБанковскихСчетов.Количество() Тогда
Возврат МассивБанковскихСчетов[0];
КонецЕсли;

// Здесь вернется Неопределено!
КонецФункции

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

Исправить такой код очень просто, необходимо исходить из пессимистичных сценариев и ожидать, что если что-то плохое может произойти, оно обязательно произойдет:

Функция БанковскийСчет(Знач Организация, Знач Банк)

МассивБанковскихСчетов = Новый Массив;
ПолучитьБанковскиеСчета(Организация, Банк, МассивБанковскихСчетов);
Если МассивБанковскихСчетов.Количество() Тогда
Возврат МассивБанковскихСчетов[0];
КонецЕсли;

Возврат Справочники.БанковскиеСчета.ПустаяСсылка();
КонецФункции

Как этого можно было избежать

* не верить всему, что написано в документации к методу и лично проверять, что возвращает функция;
* тщательно тестировать свои доработки/исправления. Даже если у вас нет автотестов или QA, разработчик не должен лениться самостоятельно запустить и проверить свою доработку;
* использование статических анализаторов/линтеров, которые могут в автоматическом режиме проверить все возможные варианты возврата из функции и указать на упущенные кейсы.

P.S. Что может пойти не так в этом коде

Источник

Что такое серебряная пуля в ит

«Кстати, если вампиры на вас все же нападут, [. ] с серебряными пулями лучше не баловаться. Ерунда все это, сам пробовал»

Емец Д.А. Таня Гроттер и трон Древнира

Оказывается, серебряная пуля для ИТ проектов появилась уже 10 лет тому назад! А теперь про нее можно прочитать и по-русски. Вот только так ли она действенна, как принято считать?

Увы, разработка программного обеспечения остается одним из самых рискованных занятий. Процент неуспешных проектов, в том числе не уложившихся в сроки или бюджет, наиболее высок именно в области информационных технологий и именно среди проектов, связанных с разработкой ПО. Можно долго рассуждать, почему проекты проваливаются. А можно подумать о том, почему же часть проектов все-таки выполняется успешно. И по второму пути идут очень и очень многие. Существует масса рекомендаций касательно того, как нужно выполнять проект, чтобы «наверняка» или «почти наверняка» выполнить его в срок, в рамках бюджета и удовлетворить все пожелания Заказчика.

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

Сам автор говорит, что он написал книгу не про Методологию, а просто про методологию. В чем разница? Чем структурное управление проектами отличается от многочисленных методологий разработки ПО, хотя бы от упомянутых выше?

Самое главное отличие состоит в том, что это книга написана для руководителей проектов. И ТОЛЬКО для руководителей проектов. В ней нет попыток объять необъятное и дать рекомендации и ценные указания всем участникам разработки. Конечно, никто не запрещает читать ее аналитикам или программистам. Но в узко профессиональном смысле они не найдут там почти ничего, адресованного именно им. Зато если вы руководите проектами или собираетесь этим заниматься, то эта книга для вас. В ней описано, что должен сделать человек, руководящий проектом. В каком порядке. И как проверить, что он сделал все как надо.

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

И если вы сумеете выполнить их, успех вашему проекту гарантирован.

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

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

А что получат от участия в проекте остальные его участники? А что получит Заказчик? Чему будет радоваться он?

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

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

Третий этап (скорее, это все-таки принцип) я, честно говоря, считаю одним из самых принципиальных с точки зрения успешного выполнения проекта. По мнению автора, всякая попытка разделить руководство проектом между несколькими людьми, например, разделив его на техническое и административное, и даже просто наличие слишком сильного неформального лидера в коллективе приводят почти со 100 процентной вероятностью к провалу проекта. Но не менее пагубно сказывается на проекте и любое нежелание руководителя брать ответственность на себя. Руководитель проекта должен помнить днем и ночью, что он отвечает за все! Совсем необязательно и даже совсем нежелательно Руководителю делать все самому. У него есть более важные занятия. Но в любом случае, перед Руководством и Заказчиком за все в проекте отвечает именно он! Я бы добавил, что если вы не согласны отвечать за все, лучше не занимайтесь руководством проектами. Найдите себе более спокойное занятие вроде укрощения диких зверей или одиночных плаваний через океан.

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

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

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

И еще один момент, о котором часто забывают. Административная работа тоже требует времени! И чем больше участников в проекте, тем больше времени нужно на администрирование. Соответственно, и нагрузку на себя руководитель должен планировать с учетом административных задач. Чтобы сократить объем административных задач для Руководителя (например, если он превосходит естественные возможности) можно ввести среди участников проекта внутреннюю структуру и назначить руководителей групп. В этом случае административную работу придется планировать и для них. Причем учтите, что если у вас нет обученных и проверенных руководителей групп, в начальный период вам придется тратить на работу с ними существенно больше времени, чем на рядовых подчиненных!

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

Пятая стадия знаменует завершение планирования очередной итерации. Теперь пора браться за выполнения планов. И здесь правила не сложнее.

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

Кроме того, в понедельник хорошо собрать всех (или хотя бы руководителей групп, если проект слишком велик) и обговорить планы на неделю. А в пятницу подвести итоги недели.

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

И так до конца итерации. Потом повторить все с самого начала. Не забудьте проверить, не изменились ли ваши цели! Спланируйте следующую итерацию. И выполните ее.

И вот после последней итерации вы, наконец, завершили этот проект! Как пишут в рекламе, вы это заслужили! Но пока все еще в памяти, не забудьте подвести итоги. Что оказалось не так, как вы предполагали изначально? Почему?

На этом книга не заканчивается. В ней приведена масса же конкретных рекомендаций по другим достаточно важным проблемам, часто встающим перед руководителями проектов. Это особенности работы при необходимости одновременно вести несколько проектов. Это принципы разработки и рецензирования планов проекта. Это способы снятия напряжения, приемы разрешения проблем и принятия решений, ведения переговоров и многое другое. И в заключение достаточно полный курс для освоения MS Project.

Надо отметить, что для иллюстрации этапов и принципов управления проектами автор использует много интересных примеров из истории экспедиций Амундсена и Скотта к Южному полюсу и из истории Гражданской войны в США.

Но вернемся к началу. Сумел ли автор найти серебряную пулю? Неужели разработка ПО остается рискованной только потому, что не все прочитали эту книгу?

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

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

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

Потому, что научить правильному стилю руководства очень сложно. Если вы прочитали книжку по UML, то, худо-бедно, вы будете рисовать и понимать UML диаграммы. Если вы прочитали руководство по IDEF1, вы будете понимать диаграммы в нотации IDEF1. А если вы прочитали книжку по структурному управлению проектами, вы, конечно, можете выучить 10 стадий. Но не факт, что вы сумеете их применить.

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

На словах все мы готовы согласиться с тем, что Руководитель должен отвечать за проект. А на деле часто думаем примерно так: «Но ведь я хороший! Это вот только подчиненные мне достались так себе, если не сказать прямее… Иванов в три раза дольше, чем было запланировано, возился со своим модулем! А Петрова вообще в декрет ушла! А кем я ее заменю? А Сидоров? Ну, переназначили его пять раз на новую задачу до того, как он предыдущую доделал. Но ведь это для проекта так нужно было, а он обижается! И после этого, вы скажете, что я плохо руководил, и поэтому проект затянулся на три года вместо шести месяцев? Да дали бы мне нормальных программистов, я бы. А если я планы не писал, так это для того, чтобы больше времени самому программировать. Если бы не я, вообще неизвестно, закончили ли бы мы этот проект хоть когда-нибудь!»

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

Если же вы все-таки сумеете переломить себя и тщательно спланировать проект… Пусть даже не в MS Project, и даже не на бумаге, а в голове по дороге на работу… Если вы будете помнить, кто из разработчиков чем занят, и тщательно продумывать, кому какую следующую работу лучше назначить… Короче, попробуйте, а вдруг у вас получится!

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

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

Источник

серебряная пуля = прямолинейное, эффективное, универсальное, быстрое, простое, упрощенное решение

Тип и синтаксические свойства сочетания
серебряная пуля
Устойчивое сочетание.

«Серебряной пули нет» [ Нажмите, чтобы прочитать ] (англ. «No Silver Bullet») — широко обсуждавшаяся статья Фредерика Брукса об инженерии программного обеспечения, написанная им в 1986 году.[1] Брукс утверждает, что «ни в одной технологии или в управленческой технике не существует универсального метода, увеличивающего на порядок производительность, надёжность и простоту». Он также утверждает, что «мы не можем ожидать увеличения прибыли в два раза каждые два года» при разработке программного обеспечения, как это происходит с разработкой аппаратного обеспечения.

Брукс подчёркивает разницу между возникающими ненужными сложностями (англ. accidental complexity) и имманентными сложностями (англ. essential complexity) и заявляет, что большинство из того, что разработчики программного обеспечения совершают в настоящее время, — относится к последнему, поэтому исключение всех т. н. ненужных сложностей не приведёт к улучшению ситуации. Брукс делает упор на основные части процесса разработки программного обеспечения. Хотя он настаивает на том, что «серебряной пули» не существует, он считает, что ряд инноваций, направленных на исправление имманентных сложностей, может привести к значительным улучшениям (возможно, более чем в десять раз за десять лет).

Статья, в которой Брукс приводит свои собственные размышления, может быть найдена в юбилейном издании книги «Мифический человеко-месяц»[2].

[ Нажмите, чтобы прочитать ] серебряная пуля = прямолинейное, эффективное, универсальное, быстрое, простое, упрощенное решение.

Ну вот, теперь можно перечитать исходный пост Щеглова и ещё помозговать. Например: можно ли серебряные пули применять против серебряных пуль?
Но уже голова болит;-))

Источник

Поиск серебряной пули или Почему не стоит искать простое решение сложной проблемы

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

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

Нет волшебного решения

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

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

Для других предпринимателей все сводится только в деньгам, и если бы они только нашли 50 000 долларов, все было бы лучше. Все их усилия направлены на то, чтобы найти эти 50 000 долларов для решения какой-то предполагаемой проблемы. Они находят деньги; проблема появляется снова спустя некоторое время.

Мы стараемся найти серебряную пулю, чтобы решить симптомы проблемы, но мы не обращаемся к причине проблемы, поэтому она никогда не исчезнет.

Идея серебряной пули привлекательна

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

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

Источник

Scrum: серебряной пули не существует

Дмитрий Кирилкин, ведущий разработчик 1С в торговой сети Реми (Владивосток). С недавнего времени также является техническим лидером во внутреннем отделе разработки. Ранее 6 лет руководил отделом информационных технологий большой фармацевтической компании. В ИТ работает почти 20 лет.

Предисловие

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

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

Что заставило нас искать новые подходы?

Компания Реми – это крупнейшая сеть продуктовых супермаркетов на Дальнем Востоке. Штат компании составляет более 3 тысяч человек в разных городах Дальневосточного региона. Компания начала бурно развиваться в последние два года, до этого отдел разработки состоял из двух человек – меня, как программиста 1С, и руководителя. И в течение буквально 6 месяцев количество разработчиков в отделе увеличилось с 1 до 4.

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

Также в нас проснулся интерес к новому, желание работать не как все. С течением времени появляется такое понятие, как профессиональное выгорание. Становится неинтересно работать, потому что все одно и то же – 1С, задачи, бухгалтерия, управленческий учет. Хочется попробовать что-то другое, хочется работать не как все. Тем более, есть такой миф в профессиональной среде разработчиков, что программисты 1С «несерьезные», мол, у нас даже код на русском языке. Поэтому хотелось приобщиться к профессиональному сообществу разработчиков.

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

Знакомство с методологией

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

И что мы сделали? Первым делом мы просто поставили Kanban-доску, насоздавали там колонок «бэклог», «в работе» и «готово». Начали вписывать задачки, двигать их по колонкам. Вот, вроде как, мы по Kanban и работаем.

Но дальше предстояло разобраться, что собой представляют Scrum и Agile. Долгое время, честно сказать, я считал, что Agile – это такое же направление гибких методологий разработки, как и Scrum. Я думал, что в Agile одни правила, а в Scrum – другие. Но потом я разобрался, что Agile – это в принципе сборник методологий, некий брендбук, если можно так сказать, в котором собрано все, что касается гибких методик экстремального программирования. А Scrum и Kanban – это просто направления Agile.

Когда все встало на свои места и стало понятно, что Scrum – это именно то, что мы будем внедрять, возник вопрос, что можно почитать на эту тему. Начал я с «зеленой» книги Майка Кона, хотя здесь всего лишь зеленая полоска на обложке.

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

И решил я поискать еще, потому что статьи, которые есть в сети по Scrum, не отвечали моим потребностям. В них, как правило, Scrum подается через личное восприятие автора этого материала, либо статья поверхностная. А мне нужна была именно инструкция по каноническому Scrum. Я наткнулся на книгу, которую должен прочитать каждый, кто хочет у себя попробовать гибкие методологии разработки. Это книга Джеффа Сазерленда «Scrum. Революционный метод управления проектами».

У себя в команде мы, кстати, начали называть ее просто «красная книга», потому что каждый раз, когда на нее ссылаешься, а ссылаешься на нее постоянно в своей работе, говорить это из «Scrum. Революционный метод управления проектами» очень долго.

Эта книга все сразу же поставила на свои места. В ней четко и подробно рассказывается, что такое Scrum, как он позволяет изменить понимание процесса разработки, что Scrum – это в принципе общение людей, что в Scrum есть определенные события, которые вы должны соблюдать, и их нельзя нарушать. И еще там есть многообещающее высказывание «делать в два раза больше за половину времени»! Поэтому если сейчас вы находитесь в каком-то упадническом настроении, ваш проект в провале, вы не знаете, как бороться с нерадивостью программистов, рекомендую прочитать эту книгу. Она заряжает очень сильной энергией, позволяет понять, что еще не все потеряно и что, если подойти к решению проблемы управления разработкой программного обеспечения немного иначе, то можно в принципе даже от этого получать удовольствие.

Что мы хотели получить от методологии?

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

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

Повышение производительности. Про это ожидание говорить много не буду, только напомню сакраментальное: «делать два раза больше за половину времени».

Конечно, мы ждали повышения уровня удовлетворения от работы. Многим разработчикам, думаю, я же тоже разработчик, знакома ситуация, когда вы очень долго разрабатываете какой-то функционал, два-три месяца, а потом вам просто уже не хочется жить, и вы идёте на работу не с чувством, что сейчас сделаете что-то полезное, а с мыслями о том, что у вас гора проблем, и неизвестно, когда они закончатся. В общем, ситуация такая, что все просто-напросто надоело, и вы даже готовы уволиться. И вот Scrum, благодаря своей итеративности, благодаря разделению большого продукта на маленькие кусочки и поставки этого продукта пользователю маленькими частями, позволяет разработчику быстрее увидеть результаты своего труда и, соответственно, видеть обратную связь от пользователя, получать удовлетворение от своей работы. В принципе это тоже очень сильно самомотивирует человека: прикольно же, когда вы новую фитчу написали, а уже через неделю вам пользователь высказал свою благодарность. И вы на подъеме, вы ему в этой же фитче еще пять каких-то мелких доработок создадите. Хотя никто вас об этом не попросит, а вам просто приятно.

И последнее ожидание – конечно же, качественная разработка ПО в условиях неопределенности требований. Очень часто пользователи просто не знают, чего они хотят. Они видят у себя в голове какой-то воздушный замок и приходят к вам с этим решением. Вы начинаете это реализовывать, но получается, что вы выдали им что-то, что не отвечает представлениям и требованиям заказчиков. И начинаются взаимные обвинения. Но это не значит, что ничего нельзя изменить. В той же «красной книге» говорится, что наличие технического задания вообще не является обязательным для того, чтобы приступить к разработке какого-то функционала, достаточно видеть небольшую область впереди себя, и когда мы к ней придем, на следующем шаге мы увидим еще какую-то область, и, соответственно, таким образом техническое задание будет уточняться в процессе реализации. В итоге это позволит нам выдать тот функционал, который хотел пользователь. Все это, по заявлениям Сазерленда и Кона, было заложено в Scrum изначально. Это не водопадный процесс, где мы уходим, долго пишем программу, потом приносим, а нас спрашивают: «А что вы сделали?».

Популяризация и понимание Scrum в команде

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

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

И я говорю ребятам: “Представьте, что у вас есть ограниченный отрезок времени – две недели – спринт, в течение которого вы выполняете задачи, набранные на этот отрезок времени, не больше. По окончании этого отрезка времени вы набираете на следующие две недели новый пул задач, которые вы тоже обязаны выполнить за две недели. И тогда вы сможете сказать пользователю, что у нас через две недели закончится спринт, и в следующий спринт мы возьмем твою задачку, соответственно, мы сможем с ней начать работать через 2 недели, а закончим ее еще через 2 недели. То есть ты получишь свой функционал через месяц. Пользователя такой ответ устроит? Скорее всего, да. Потому что он и не ждал от нас конкретной даты, все ведь понимают, что это практически невозможно угадать.”

Был использован еще такой способ: при чтении «красной книги», я очень часто какие-то главы из нее или небольшие параграфы выдергивал и отправлял в общий чат разработчикам, чтобы они на досуге почитали, поняли, что есть такая штука, как стендап, как ретроспектива, как управление счастьем. Это для тех, кто знает, о чем я говорю. В «красной книге» обо всем этом написано.

Так росло понимание того, что Scrum в принципе может решить огромное количество задач, которые раньше вообще никто не знал, как решать.

И началом нашей разработки по Scrum можно назвать такой случай. Я на просторах сети наткнулся на прекрасную статью о том, что такое Scrum-митинг и какие три вопроса должен задавать Scrum-мастер на митинге. Это:

— что ты сделал вчера?

— что ты сделал сегодня? (именно в прошедшем числе)

Скинул эту статью в нашу группу в Telegram и думаю: «Сейчас меня точно закидают помидорами, скажут, что им работать некогда, а я тут со своими статьями, со своими митингами какими-то каждое утро. Делать больше нечего нам что ли, только отвечать на эти три непонятных вопроса?». Но к моему удивлению, утром следующего дня люди пришли и сказали, а давайте попробуем. Причем сами. Их никто об этом не просил. И с этого момента у нас начались ежедневные стендапы, как оно и положено в Scrum.

Это был еще неполноценный Scrum, но это были уже стендапы, на которых мы старались правильно, в прошедшем времени, ответить на все вопросы.

Самый сложный из них был, конечно, последний – «что тебе мешает?».

Выбор владельца продукта и Scrum-мастера

Исходя из определения, владелец продукта по каноническому Scrum – это человек, обладающий видением того, что вы собираетесь делать (производить) и достигать. И тут сказалась специфика разработки на 1С. У нас продукта, как такового, не было. У нас было 4 абсолютно разных конфигурации на поддержке: документооборот, торговля, бухгалтерия и комплексная автоматизация. Плюс к тому во многих случаях за нас при разработке этих продуктов уже подумала 1С, мы только занимаемся адаптацией. Соответственно, и владельца продукта, вроде бы, нет. И долгое время у нас его действительно не было. Но потом пришло понимание того, что все-таки в команде нужен человек, который видит, что именно в данный момент нужно пользователям, и этот человек приоритезирует бэклог, расставляет приоритеты задач, которые разработчики будут набирать на следующий спринт. В данный момент у нас эту роль выполняют ведущий программист, то есть я. И мы считаем это удачным решением, потому что я нахожусь на стыке между командой и пользователями: я знаю возможности команды, я знаю возможности продукта, возможности конфигурации, которые мы разрабатываем, и я знаю, чего хотят пользователи, потому что я общаюсь с ними по новому функционалу.

Со Scrum-мастером тоже все не так просто. По определению, это человек, который следит за ходом проекта. А проекта у нас нет, у нас есть 4 конфигурации. Как быть? Пришли к тому, что у нас есть не 4 конфигурации, а проект, состоящий из 4 конфигураций. И первое время у нас Scrum-мастер просто обеспечивал проведение коротких собраний (митингов), задавал три вопроса. И это был дежурный программист. У нас есть в команде обязательно дежурный программист на неделю, он эту неделю и являлся временным Scrum-мастером.

И опять же, это определение «помогает устранять мешающие препятствия команде». Какие препятствия? Это было неясно. Потом мы поняли, что все-таки это человек, который должен следить за процессом разработки программного обеспечения в команде. Сейчас это у нас один из опытных разработчиков, который смотрит, все ли гладко сейчас в протекающем процессе, в протекающем спринте, не скопились ли задачи в тестировании, что с ними делать, сразу же об этом сигнализирует и пытается моментально выработать решения. Также, этот человек в свое время предложил перейти с недельных спринтов (я чуть позже об этом скажу) на двухнедельные. Потому что за недельный спринт мы просто не успевали сделать необходимый функционал, было слишком мало времени. И именно этот человек будет следить за тем, дал ли переход на двухнедельные спринты какой-то результат.

И чем хорош Scrum: никто не заставляет людей выполнять какие-то роли. Как правило, они сами на себя их берут, потому что им становится интересно.

Обязательные события Scrum

У нас обязательным событием являются ежедневные собрания на ногах. На картинке вы можете увидеть одно из таких собраний. Начинается оно у нас с зарядки.

Придумал ее наш руководитель. Казалось бы, бесполезная трата времени эта йоговская зарядка. Но это не так. Это вносит в Scrum-митинг элемент неформальности: на этих зарядках сотрудники раскрываются совсем по-другому. Когда ты стоишь с этим «кирпичом», улыбаешься, на тебя смотрят другие разработчики, в том числе, молодые, и они уже не видят в тебе какого-то гуру, не боятся подойти. Они знают, что ты простой парень, который каждое утро вместе с ними делает зарядку. Причем на зарядках часто можно, просто стоя с этим «кирпичом», обсудить какую-то проблему, про которую ты вечером думал, например, попробовать внедрить интеграционную шину. То есть они не бесполезны. И по нашему мнению, на митинге обязательно должен быть какой-то элемент, не связанный с работой.

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

Ретроспектива спринта – это очень сложно. Картинка отлично демонстрирует, как это происходило у нас в первое время.

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

Что касается обзора спринта. К сожалению, из-за того, что у нас нет продукта, как такового, а 4 отраслевые конфигурации, в спринт, как правило, набирается огромное количество всевозможных маленьких задач. И провести какое-то демо с пользователями практически не представляется возможным. Они просто не придут: кто-то находится на Сахалине, кто-то в Хабаровске. Поэтому на обзоре спринта, мы, как правило, рассказываем про технические решения для своих же коллег в отделе. Допустим, внедрили мы в продакшене автодеплой, рассказали, как это работает. Внедрили интеграционную шину, рассказали, как работает. Т.е. основная цель обзора спринта у нас – это повышение информированности сотрудников команды, чтобы они знали, чем мы занимаемся.

Новый подход к работе с задачами

Scrum говорит, что всю работу нужно рассматривать с точки зрения пользовательских историй, то есть каждая задача должна нести какую-то ценность для пользователя. Но в реальности это оказалось сложно или вообще непродуктивно – описывать всевозможные технические задачи с точки зрения ценности для пользователя. Я, как бухгалтер, хочу, чтобы документы из управления торговлей заливались в бухгалтерию, чтобы я сдал отчетность. Так неправильно, нам показалось. Потому что разработчик может потратить огромное количество времени на решение таких задач и на поиск решения этой задачи, и лучше ему просто дать готовое ТЗ в данном случае. И сейчас у нас в бэклоге процент пользовательских историй колеблется от 20 до 30 процентов. Это еще связано с тем, что разработчики пока не привыкли описывать задачи.

Хочу еще сказать про эпики. Эпики – это большая непонятная задача. Вначале мы их не использовали, и не использовали их, пока не начали пользоваться спринтами. Потому что когда мы поняли, что есть огромный пул задач, логически сгруппированных, эти задачи нужно как-то отслеживать во времени и понимать скорость их выполнения, мы сразу же решили, что нам нужен эпик. И сейчас для нас эпик – это логическая группировка задач.

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

Оценка задача в Story Points нужна обязательно. В начале начинаешь без нее, но тут Scrum изящно решает проблему оценки задач, он вводит ее относительность. Мы используем числа Фибоначчи для оценки задач, точность при этом нам не очень нужна, потому что главное – оценить количественную сложность задачи.

Жизненный цикл задачи

Расскажу про жизненный цикл наших задач. На картинке – вид текущей Scrum-доски, которая у нас есть сейчас на проекте.

Там есть колонки: «нужно сделать», «непонятное ТЗ», «тестирование не пройдено», «в работе», «ожидает тестирования», «идет тестирование», «готово». И задача в принципе так и движется – слева направо. У нас все задачи тестируются разработчиками. Разработчик, который выполнил задачу, перемещает ее в «ожидает тестирования», а следующий разработчик берет эту задачу в тест. Этим мы решаем две задачи. Во-первых, проводится сразу же Code review, во-вторых, разработчик сразу же входит в курс дела, и в случае если тестирование не пройдено, он переводит задачу в «тестирование не пройдено», пишет свои комментарии. Поскольку в задаче сохраняется последний исполнитель и последний тестировщик, это позволяет не передавать работу из рук в руки. И когда в следующий раз разработчик увидит задачу в колонке «тестирование не пройдено», он ее вернет назад в работу, а в тестирование эту задачу возьмет тот сотрудник, который ее проверял до этого.

Еще. Спринту желательно создавать цель. Этим занимается Scrum-мастер. Но из-за того, что у нас 4 конфигурации, мы не можем часто задавать цель спринта.

Программное обеспечение, которое мы используем

Последнее, о чем хочу рассказать – программное обеспечение, которое мы используем: Jira Software, Confluence, а со стороны пользователей – 1С:Документооборот.

Дополнительное программное обеспечение – GIT, OneScript, Jenkins.

Вместо заключения

Так что в принципе все ожидания, которые были у нас от Scrum, мы удовлетворили.

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

Данная статья написана по итогам доклада, прочитанного на конференции INFOSTART EVENT 2018 EDUCATION. Больше статей можно прочитать здесь.

В 2020 году приглашаем всех принять участие в 7 региональных митапах, а также юбилейной INFOSTART EVENT 2020 в Москве.

Источник