Как мы познакомились с Agile & Scrum

[@ifalur]

Хорошая полезная статья, но читать невозможно. Скажите, вы русский язык совсем позабыли? пул, feedback и т.д.

[@1aZzy]

Есть у меня такая проблема. Боремся! Следующий раз постараюсь, чтобы было все лучше!

[@jetcar]

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

[@evocatus]

Да. Когда читал, отметил про себя, что на двухнедельный «спринт» у них ушло 4 часа на планирование задач и 1,5 часа на обсуждение результатов в конце. Считай целый рабочий день для множества людей. А в двух неделях 10 рабочих дней. Итого 10% времени как минимум, потому что я не учёл время на подготовку ко всем этим встречам (а готовиться к ним нужно не только менеджеру, у которого, готов поспорить, почти всё время уходит на эти бумажки и ежедневное расклеивание их по офису)

[@1aZzy]

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

[@jetcar]

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

[@1aZzy]

Решило бы. Просто не те размеры, которые хотел клиент. Разрабатывали по «хотелкам» клиента.

[@1aZzy]

Видимо я плохо передал некоторые нюансы. Agile, потому что он позволяет адаптировать разрабатываемый продукт под нужны клиента/руководителя в самые короткие сроки, чем короче итерации, тем быстрее можно перекроить планы, а это нам и было нужно он «фреймворка» ведения проекта. Да, вы правы, для улучшения качества и быстроты нужно внедрять еще множество технических процессов разработки. У нас они внедряются параллельно тому, что описано в этой статье.

[@jetcar]

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

[@1aZzy]

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

[@jetcar]

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

[@1aZzy]

Agile мы применяем разумно, есть проекты, которые идут по старой доброй каскадной модели, так как мы работаем и с тендерами в том числе, а там нужно иметь четкие сроки завершения того или иного этапа. У всего должна быть мера. Я далеко не из тех, которые пропагандируют agile и только его. И сравнение лошади и машины, — это сравнение того как работали раньше (абы как) с тем, что есть сейчас.

[@WarFollowsMe]

А не пробовали вместо физических досок использовать электронные аналоги? Что-то вроде trello например.

[@1aZzy]

Redmine с плагином backlog's предоставляет некоторую электронную доску задач, но она мне не совсем нравится. Плагин для 1С Битрикса потрогал, но пока дальше в работу не пошло. В ближайшее время планируем внедрять. Посмотрю ту, которую вы посоветовали, спасибо.

[@Odrin]

Слово «scrum» в статье используется 24 раза, но при этом сама эта методология у Вас в итоге не используется. Зато есть карточки, листики на стене, графики и презентация. Так что да, как Вы в конце статьи и отметили:

а может быть и опыт, как делать нельзя.

[@1aZzy]

Рад, что смогу кому-то помочь хоть этим.

[@Exabiche]

Jira не рассматривали?

[@1aZzy]

В долго идущих планах рассматриваем переход на программный пакет от атласиан: jira, confluence и т.п. на данный момент нет времени.

[@Askofen]

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

1. Большие затраты времени на планирование спринта. Если в планировании принимают участие 6 человек и тратят на это 4 часа рабочего времени, то потери времени 24 человеко-часа. Это три дня. Зачем это нужно? Люди должны приучаться работать самостоятельно и индивидуально. Можно распределить задачи между членами команды и попросить каждого из них сделать task break-down & estimation. Затем ведущий программист сделает ревью. Другой вариант — поручить эту работу лиду, а затем сотрудник, которому поручается данная задача делает ревью оценки и декомпозиции. Такая процедура займет гораздо меньше времени.

2. Одно совещание для разных команд существенно увеличивает общие затраты времени. Сотрудников команды А не интересуют задачи команды Б (да и не должны интересовать). Они просто тратят свое время впустую, хотя могли бы в это время продуктивно работать над своими задачами.

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

4. Использование бумажных карточек в то время, когда имеются электронные системы контроля задач — это расточительная трата времени. Карточки не делятся на подзадачи, плохо фильтруются и плохо ищутся (если, конечно, речь идет не о 5 — 7 штуках). Электронные системы учета задач позволяют быстро искать задачи и быстро их фильтровать. Можно обходиться обычным редмайном или джирой без всяких надстроек. Мы идентифицируем майлстоуны при помощи меток. Точно так же можно поступать и со спринтами.

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

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

[@1aZzy]

1. Пример про четыре часа планирования был приведен из одной команды, в других планирование проходит быстрее. Четыре часа: данная команда работает над сложными техническими решениями и только ведущий разработчик имеет понимание, как решать поставленные задачи. Планерка состоит в том, что вед. объясняет остальным, как решать поставленные задачи, так как оюбому может достаться любая задача, то и на планерка должны быть все. Подчеркну, что длинная планерка только у одной команды.
2. В статье я указал на то, что сейчас команды разделены на разные направления, то есть планерка у всех разработчиков проходят по раздельно в соответствии с проектом.
3. Сейчас, только одна команда большая: 5 человек, все остальные 2-3, планерка быстрые и каждый задействован, сачковать не кому не удается.
4. В статье я подчеркнул, что сейчас перешли полностью в электронный вид. Я считаю, чтобы изначально сотрудники познакомились с новой системой, должна быть наглядная визуализация.
5. Проверка задач на ошибки осуществляется отделом тестирования — отдельная команда, иногда состоят в одной команде с разработчиками, иногда в спринте выделяется время на правку багов, но за частую, — это другой спринт. Верификацию от лица пользователей, осуществляют заинтересованные люди компании: руководство, маркетинг, я и др. Техническая верификация: в каждой команде есть вед, который осуществляет контроль по мердж реквестам.

Основная проблема: отсутствие структурности и системности в работе it-отдела организации.

[@Askofen]

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

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

Все разработчики, которые компетентны выполнять данную задачу (зачастую, практически все), выкладывают карты рубашкой вверх на стол с цифрой, которая равна story-points на выполнение данной задачи.

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

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

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

При работе с электронными системами контроля задач важны следующие навыки:

1. грамотно и понятно называть задачи;
2. умение пользоваться поиском и фильтрами;
3. умение вовремя обновлять статус задачи;
4. умение грамотно закрывать задачу (нужно указать номер ревизии, в которой задача реализована);
5. умение следить за статусом задачи после того, как она перейдет на тестирование, т.к. задача может тестирование не пройти, и потребуются изменения.

Работа с бумажными карточками эти навыки НЕ ставит.

[@1aZzy]

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

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

При работе с электронными системами контроля задач важны следующие навыки:

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

Я с вами полностью согласен, что нужно пользоваться электронными системами, к этому мы и пришли своим путем.

Оценивать задачу должен исполнитель.

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

[@1aZzy]

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

[@1aZzy]

В статье я писал, что на предприятии используется битрикс, и в ближайших планах: мы будем с ним взаимодействовать. И про scrumban я писал, даже есть ссылка на магазин. Но чесно говоря, нам в it-отделе, он не особо нравится.