17 ноября 2018 года. Нас четверо. Настроение у всех приподнятое — прошли первый этап ШРИ, Школы разработки интферфейсов. Он состоял из лекций и домашних заданий: осваивали разные фронтендерские и околофротендерские технологии, инструменты, Скрам. Знали, что всё это придётся применять в боевом проекте на втором этапе. Но одно дело знать, и другое — действительно реализовать этот проект за ближайшие 5 недель.
Жизненный цикл программного обеспечения известен большинству современных программистов.
Даже школьник, написав свою первую программу
<?php
echo "Hello! На пхп"
?>
или
fprintf( 'Привет Хабр на Матлабе!n');
понимает технологический процесс.
Между 1-5 этапами нитиобразно мы имеем непрерывно взаимодействующие процессы.
Для этого существуют всякие Водопады, Скрамы итд.
Так вот дело в том, что когда у вас проект раздувается до нескольких типов фронтэнда,
как требует современный IT мир заказчику хочется максимально покруть аудиторию для максимизации собственной прибыли.
И по этой причине мы все наблюдаем обилие проектов, в которых одновременно существуют несколько типов фронэндов, взаимодействующих по API с централизованным бэкэндом.
Читать полностью »
Гильдии и сообщества — что вы слышали о них? Это что-то из онлайн-игр или социальных сетей? Оказывается, не только. Эти инструменты давно используются в современных компаниях, чтобы помочь людям начать больше общаться, делиться опытом и учиться принимать решения самостоятельно.
21 июня Tutu.ru совместно с AgileVerse приглашают посетить митап «Как запускать гильдии и сообщества?». Ребята поделятся своим опытом, а мы вместе составим описание эффективного сообщества. Пропишем конкретные шаги для создания подобного сообщества в вашей компании.
Читать полностью »
Предисловие: целью данной публикации ставится получение обратной связи и сбор критики по статье от ИТ-сообщества в преддверии её печати в периодическом издании. В статье будет представлено краткое описание, в хронологическом порядке, популярных методологий в области управления информационными проектами.
В 1958 году консалтинговая компания «Booz Allen Hamilton Inc.» совместно с центром разработки «Lockheed Martin Space Systems» и подразделением программных разработок специального проектного центра департамента ВМС США разрабатывают технику оценки и анализа программ (проектов) «Program Evaluation and Review Technique» под кодовым названием PERT — для проекта разработки системы вооружения подводных лодок «Polaris» [1] (баллистические ракеты).
PERT разрабатывался для экономии времени при управлении крупными проектами, в которых время является критическим показателем. Методология предполагает анализ отдельно взятых задач в ракурсе их влияния на завершение всего проекта, в частности, анализируется время на выполнения каждой задачи, в результате чего определяется минимально необходимое время на прохождение всех этапов. Данная техника может применятся в условиях неопределенности, когда неизвестны детали каждого этапа и точное время на их выполнение, более того, это событийно ориентированная техника применяемая к проектам, где время более важный фактор, чем стоимость.
Данная методология применялась при подготовке к зимним олимпийским играм 1968 года в Гренобле [2], она же была первая в своем роде, возрождающая подход «Научной организации труда» [3] впервые описанный Тейлором Фредериком Уинслоу в 1911 году, пытавшегося применить науку для инженерии процессов и управления.
Читать полностью »
За последние 3 года работы мне довелось работать в самых различных ипостасях: исследователем, разработчиком и руководителем проектов. Есть различные стили управления: западный (когда предоставляется большая свобода в коллективе и многое построено на доверии, уважении, личной организованности отдельного индивидуума) и восточный (когда штрафуется каждое опоздание, жестко фиксируются сроки, во главе угла стоит железная дисциплина коллектива и если человек не справился с поставленными целями — наступает расставание ). Руководитель проекта должен сочетать в себе два этих элемента: яблоко и кнут, подпускать людей к себе, чтобы разработчики Вам доверяли, но и соблюдать субординацию, так как отношение-отношениями, а нацеленность на результат должна быть всегда.
Но куда важнее: как Вы двигаетесь к поставленной цели, как организуете свой рабочий процесс… В этой статье хотелось бы поделиться с достопочтенной публикой одной из наших непрофессиональных видео лекцией, которую мы снимали для себя. Думаю в каждом коллективе наступает такой момент, когда что-то может идет не совсем так, как хотелось бы. Хочется каких-то изменений и лучше прежде всего начинать их с себя. Как говорится — если хотите изменить мир, то стоит это начать прежде всего с Вас самих же и Вашего ближайшего окружения.
Для удобства сделал субтитры к видео, чтобы смотреть его было проще. Замечу лишь, что это не профессиональная видео лекция и лектор нигде эту методологию не читает специально. Дина Насырова (Тим Лидер из Fujitsu) пришла к нам в знак уважения, чтобы помочь наладить процесс работы коллектива и заодно поделилась своим собственным богатым опытом. Встреча прошла год назад — с тех пор много воды утекло. Но спустя время до сих пор вспоминаю ее, так как информация представленная в ней мне очень сильно пригодилась.
Читать полностью »
Давно хотел систематизировать свой взгляд на методологии разработки ПО, на взаимодействие менеджера и программиста (функционального тимлида и тимлида разработки), но всё не попадалась точка опоры, оттолкнувшись от которой, можно порассуждать. И вот эта точка опоры появилась. Коллега прислал ссылку на манифест (RU), который, как представляется, легко овладевает неокрепшими умами посредством своей категоричности и ненормативной лексики.
Читать полностью »
Термин «скрам-бат» (scrumbut) впервые начал использовать Кен Шуэйбер что бы описать неверную трактовку или умышленную модификацию правил скрам, что бы уйти от болезненной правды о процессе, которую он помогает открыть.
Типичная формулировка скрам-бата выглядит так:
У нас скрам, но <Причина>, <ОбходнойПуть>
Где Причина — это описание дискомфорта, неприятного открытия с которым команда в силу тех, или иных причин не может справиться. А Обходной путь — это способ закрыть глаза на проблему, или устранить «симптомы», не разобравшись с причинами «организационного заболевания».
Типичные примеры скрам-батов, соответственно, выглядят так:
Мы стараемся термином «скрамбат» не злоупотреблять, поскольку некоторые типы отклонений свойственны началу внедрения аджайл и являются частью эволюции процесса. Например, если у вас скрам, но вы не делаете TDD, у вас нет парного программирования и слабо выраженное коллективное владение кодом — возможно, вы просто в начале пути. Причины могут быть разными — от неумения «продать» ценность инженерных практик менеджменту до неумения их «готовить». И то и другое можно научиться делать, но это занимает определенное время, верно?
Однако, каждый раз, когда я слышу «у нас скрам, но» в зрелых командах, я пытаюсь услышать нечто большее большее о причинах, которые такую модификацию обуславливают. И знаете, что? Веских причин на самом деле очень мало. Скорее, это непонимание ценностей гибкой разработки, недостаток смелости и силы что бы им следовать, которые вместе образуют процессное «скрамно».
Работая с командами, мы собрали список из 85 заблуждений и препятствий успешного внедрения гибкой разработки. Многие выходят за рамки правил карсасса скрам. В зависимости от контекста проекта, некоторые пункты могут иметь большее или меньшее влияние, и иметь оправдания обстоятельствами. Однако мы верим, что каждый элемент этого списка провоцирует искаженение ценностей и принципов Agile.
Читать полностью »
Недавно, на Скрам портале была опубликована статья Майка Кона об Общепринятых практиках в Скраме — практиках, которые довольно часто встречаются в Скрам-проектах, но не являются базовыми правилами Скрам.
Скрам поощряет подобные добавления и специально построен минималистично, дабы команды могли добавить то, что им по вкусу. Не стоит путать подобные улучшения процесса с печально известным Скрам-ном. В отличие от последнего, добавленные практики улучшают процесс, повышая эффективность выпуска продуктов и выравнивая поток работ.
Сегодня я хочу поделиться множеством таких практик, собранных вокруг работы с требованиями. За последние несколько лет перечисленные практики мне не раз довелось наблюдать за кулисами у успешных команд в роли agile-коуча и рассказывать о них на тренингах Certified ScrumMaster в роли скрам-тренера.
Я ни в коем случае не претендую на полноту практик и буду рад услышать дополнения. Некоторые из перечисленных практик заслуживают отдельных статей — это work in progress.
Многие компании уверяют, что работают по гибким методологии. Но там ли это? Возьмем, к примеру, скрам. Скрам давно испытанный и отточенный на практике рабочий процесс, но всегда ли он помогает в разработке? Может ли хорошо отлаженный процесс служить не поплавком, но грузилом? Я не являюсь скрам-тренером или кем-то подобным, просто хочу дать несколько анти-советов, которые, надеюсь, помогут взглянуть на скрам со стороны.
Scrum — достаточно простая методология. Работать же по скраму не так и просто. Точно так же происходит со многими инструментами, например с покером для планирования. Практика сама по себе вполне понятная, но продуктивно её использовать в течении длительного времени затруднительно.
В этой статье я расскажу про технику, которая упрощает процесс оценок в работе скрам команды.
Итак, в чём же сложность?
Как вы знаете, story points — это относительные оценки объёма работы в истории. Нет способа оценить одну единственную историю в story points, вы всегда сравниваете историю с другими историями через story points. Покер может хорошо сработать в начале проекта, когда команды оценивает много историй в течении короткого промежутка времени.
Но позже, во время регулярной переоценки существующих историй и оценок новых историй становится значительно труднее, потому что калибровка одного story point забывается: «что такое один story point», «что-то я не уверен, что эта история действительно в 3 раза больше нашего золотого эталона», «эти две истории размером 5 не выглядят одинаковыми в размере, с моей точки зрения». Знакомые проблемы?
Читать полностью »
