Comments 26
Хорошая полезная статья, но читать невозможно. Скажите, вы русский язык совсем позабыли? пул, feedback и т.д.
все менеджеры любят этот аджайл скрам, всякие графики, но почему-то никто не сравнивает с тем что было до этого, тупо перешли потому что модно и графики красивенькие, но ведь это не показатель, показатель это количество полезной работы которая была зделана, надо сравнить до аджайла и после
померить конечно трудно, но без этого нельзя сказать что стало лучше или хуже.
как показывает практика внедрение управление процессами менеджмента задачами не повышаеат качество и быстроту написания продукта, его повышают внедрение правильных процессов разработки: техническая документация, TDD, код ревью и различные виды тестирования конечного продукта.
померить конечно трудно, но без этого нельзя сказать что стало лучше или хуже.
как показывает практика внедрение управление процессами менеджмента задачами не повышаеат качество и быстроту написания продукта, его повышают внедрение правильных процессов разработки: техническая документация, TDD, код ревью и различные виды тестирования конечного продукта.
Да. Когда читал, отметил про себя, что на двухнедельный «спринт» у них ушло 4 часа на планирование задач и 1,5 часа на обсуждение результатов в конце. Считай целый рабочий день для множества людей. А в двух неделях 10 рабочих дней. Итого 10% времени как минимум, потому что я не учёл время на подготовку ко всем этим встречам (а готовиться к ним нужно не только менеджеру, у которого, готов поспорить, почти всё время уходит на эти бумажки и ежедневное расклеивание их по офису)
Вы правы, на подготовку уходит много времени, и я это отмечал, как большую проблему в статье. Но нет, большинство времени уходит не на это. Потраченный день на обсуждение и разжевывание задач ничто по сравнению с тем, какие потери могут быть, например: разработчик не правильно понял feature и реализовал её не так, как нужно было клиенту, или, недавно был случай: клиенту не показали, как положено по регламенту модель его аппарата и сразу сделали боевой образец, итог, аппарат стоит пылится, такой клиенту он не нужен (банально не провели демо).
Видимо я плохо передал некоторые нюансы. Agile, потому что он позволяет адаптировать разрабатываемый продукт под нужны клиента/руководителя в самые короткие сроки, чем короче итерации, тем быстрее можно перекроить планы, а это нам и было нужно он «фреймворка» ведения проекта. Да, вы правы, для улучшения качества и быстроты нужно внедрять еще множество технических процессов разработки. У нас они внедряются параллельно тому, что описано в этой статье.
но у вас всё равно нет сравнения до и после
как аналогия, взяв машину с мощным двигателем ещё не означает что она доедет из одной точки в другую за более быстрое время, по пути изза большего расхода придёться заправляться намного чаще и в конце она может приехать медленнее чем со слабым двигателем, но меньшим расходом
как аналогия, взяв машину с мощным двигателем ещё не означает что она доедет из одной точки в другую за более быстрое время, по пути изза большего расхода придёться заправляться намного чаще и в конце она может приехать медленнее чем со слабым двигателем, но меньшим расходом
Да, у меня нет сравнения, так как новую систему строил я, а старых данных у меня к сожалению нет. Да и команда/технологии/процессы кардинально поменялись, тут было бы сравнение не в двигателях, а сравнение лошади и машины.
вот не надо про лошадь и машину, лошадь тогда будет аджайлом так как по параметрам ближе,
кстати раз аджайл уже работает и есть оценимые результаты то надо для сравнение поработать без него какоето время и тогда можно не только сравнить, но и убедить всех скептиков в выгоде ну или наоборот тут всё от результата зависит.
думаю довольно разумное предложение, сам бы потестил, но я ни кем не руковожу, а в новой фирме пока достаточного влияния не имею
кстати раз аджайл уже работает и есть оценимые результаты то надо для сравнение поработать без него какоето время и тогда можно не только сравнить, но и убедить всех скептиков в выгоде ну или наоборот тут всё от результата зависит.
думаю довольно разумное предложение, сам бы потестил, но я ни кем не руковожу, а в новой фирме пока достаточного влияния не имею
Agile мы применяем разумно, есть проекты, которые идут по старой доброй каскадной модели, так как мы работаем и с тендерами в том числе, а там нужно иметь четкие сроки завершения того или иного этапа. У всего должна быть мера. Я далеко не из тех, которые пропагандируют agile и только его. И сравнение лошади и машины, — это сравнение того как работали раньше (абы как) с тем, что есть сейчас.
А не пробовали вместо физических досок использовать электронные аналоги? Что-то вроде trello например.
Слово «scrum» в статье используется 24 раза, но при этом сама эта методология у Вас в итоге не используется. Зато есть карточки, листики на стене, графики и презентация. Так что да, как Вы в конце статьи и отметили:
а может быть и опыт, как делать нельзя.
Jira не рассматривали?
На мой взгляд, при организации работы команды совершено несколько ошибок. (На истину в последней инстанции я не претендую, но свою точку зрения выскажу.)
1. Большие затраты времени на планирование спринта. Если в планировании принимают участие 6 человек и тратят на это 4 часа рабочего времени, то потери времени 24 человеко-часа. Это три дня. Зачем это нужно? Люди должны приучаться работать самостоятельно и индивидуально. Можно распределить задачи между членами команды и попросить каждого из них сделать task break-down & estimation. Затем ведущий программист сделает ревью. Другой вариант — поручить эту работу лиду, а затем сотрудник, которому поручается данная задача делает ревью оценки и декомпозиции. Такая процедура займет гораздо меньше времени.
2. Одно совещание для разных команд существенно увеличивает общие затраты времени. Сотрудников команды А не интересуют задачи команды Б (да и не должны интересовать). Они просто тратят свое время впустую, хотя могли бы в это время продуктивно работать над своими задачами.
3. Общие совещания размывают индивидуальную ответственность. Они позволяют части работников элементарно сачковать, соглашаясь с мнением более активных сотрудников. Каждый человек должен делать свою работу. Если кто-то не умеет делать декомпозицию или оценивать задачи, то важно попросить ведущего программиста его научить. Но, в любом случае, задание должен выполнить тот сотрудник, которому оно поручено. А ревью поможет выявить сделанные ошибки.
4. Использование бумажных карточек в то время, когда имеются электронные системы контроля задач — это расточительная трата времени. Карточки не делятся на подзадачи, плохо фильтруются и плохо ищутся (если, конечно, речь идет не о 5 — 7 штуках). Электронные системы учета задач позволяют быстро искать задачи и быстро их фильтровать. Можно обходиться обычным редмайном или джирой без всяких надстроек. Мы идентифицируем майлстоуны при помощи меток. Точно так же можно поступать и со спринтами.
5. Непонятно, как в команде осуществляется контроль качества. Кто верифицирует сделанные задачи с точки зрения пользователя? Как это успевает делаться в течение одного спринта? Или баги могут фикситься и в другом спринте? Как осуществляется верификация технического решения? Кто за это ответственный?
Общий вывод: непонятно, какие проблемы были в самом начале и как они были решены при помощи скрама. Пока что видны большие потери времени, которые команда вынуждена тратить на планирование и ретроспективы.
1. Большие затраты времени на планирование спринта. Если в планировании принимают участие 6 человек и тратят на это 4 часа рабочего времени, то потери времени 24 человеко-часа. Это три дня. Зачем это нужно? Люди должны приучаться работать самостоятельно и индивидуально. Можно распределить задачи между членами команды и попросить каждого из них сделать task break-down & estimation. Затем ведущий программист сделает ревью. Другой вариант — поручить эту работу лиду, а затем сотрудник, которому поручается данная задача делает ревью оценки и декомпозиции. Такая процедура займет гораздо меньше времени.
2. Одно совещание для разных команд существенно увеличивает общие затраты времени. Сотрудников команды А не интересуют задачи команды Б (да и не должны интересовать). Они просто тратят свое время впустую, хотя могли бы в это время продуктивно работать над своими задачами.
3. Общие совещания размывают индивидуальную ответственность. Они позволяют части работников элементарно сачковать, соглашаясь с мнением более активных сотрудников. Каждый человек должен делать свою работу. Если кто-то не умеет делать декомпозицию или оценивать задачи, то важно попросить ведущего программиста его научить. Но, в любом случае, задание должен выполнить тот сотрудник, которому оно поручено. А ревью поможет выявить сделанные ошибки.
4. Использование бумажных карточек в то время, когда имеются электронные системы контроля задач — это расточительная трата времени. Карточки не делятся на подзадачи, плохо фильтруются и плохо ищутся (если, конечно, речь идет не о 5 — 7 штуках). Электронные системы учета задач позволяют быстро искать задачи и быстро их фильтровать. Можно обходиться обычным редмайном или джирой без всяких надстроек. Мы идентифицируем майлстоуны при помощи меток. Точно так же можно поступать и со спринтами.
5. Непонятно, как в команде осуществляется контроль качества. Кто верифицирует сделанные задачи с точки зрения пользователя? Как это успевает делаться в течение одного спринта? Или баги могут фикситься и в другом спринте? Как осуществляется верификация технического решения? Кто за это ответственный?
Общий вывод: непонятно, какие проблемы были в самом начале и как они были решены при помощи скрама. Пока что видны большие потери времени, которые команда вынуждена тратить на планирование и ретроспективы.
1. Пример про четыре часа планирования был приведен из одной команды, в других планирование проходит быстрее. Четыре часа: данная команда работает над сложными техническими решениями и только ведущий разработчик имеет понимание, как решать поставленные задачи. Планерка состоит в том, что вед. объясняет остальным, как решать поставленные задачи, так как оюбому может достаться любая задача, то и на планерка должны быть все. Подчеркну, что длинная планерка только у одной команды.
2. В статье я указал на то, что сейчас команды разделены на разные направления, то есть планерка у всех разработчиков проходят по раздельно в соответствии с проектом.
3. Сейчас, только одна команда большая: 5 человек, все остальные 2-3, планерка быстрые и каждый задействован, сачковать не кому не удается.
4. В статье я подчеркнул, что сейчас перешли полностью в электронный вид. Я считаю, чтобы изначально сотрудники познакомились с новой системой, должна быть наглядная визуализация.
5. Проверка задач на ошибки осуществляется отделом тестирования — отдельная команда, иногда состоят в одной команде с разработчиками, иногда в спринте выделяется время на правку багов, но за частую, — это другой спринт. Верификацию от лица пользователей, осуществляют заинтересованные люди компании: руководство, маркетинг, я и др. Техническая верификация: в каждой команде есть вед, который осуществляет контроль по мердж реквестам.
Основная проблема: отсутствие структурности и системности в работе it-отдела организации.
2. В статье я указал на то, что сейчас команды разделены на разные направления, то есть планерка у всех разработчиков проходят по раздельно в соответствии с проектом.
3. Сейчас, только одна команда большая: 5 человек, все остальные 2-3, планерка быстрые и каждый задействован, сачковать не кому не удается.
4. В статье я подчеркнул, что сейчас перешли полностью в электронный вид. Я считаю, чтобы изначально сотрудники познакомились с новой системой, должна быть наглядная визуализация.
5. Проверка задач на ошибки осуществляется отделом тестирования — отдельная команда, иногда состоят в одной команде с разработчиками, иногда в спринте выделяется время на правку багов, но за частую, — это другой спринт. Верификацию от лица пользователей, осуществляют заинтересованные люди компании: руководство, маркетинг, я и др. Техническая верификация: в каждой команде есть вед, который осуществляет контроль по мердж реквестам.
Основная проблема: отсутствие структурности и системности в работе it-отдела организации.
Планерка состоит в том, что вед. объясняет остальным, как решать поставленные задачи, так как оюбому может достаться любая задача, то и на планерка должны быть все.
Если задачи разных разработчиков пересекаются, то тогда — да, лиду имеет смысл собрать команду и объяснить подходы к решению. Однако если задачи не пересекаются или пересекаются слабо, то лучше поступить по-другому — распределить их между членами команды, дать время подумать, выработать подходы к решению и с каждым провести индивидуальную беседу. Это будет и продуктивнее, и не будет отнимать время у каждого члена команды на обсуждение вопросов, которые ему не важны.
Все разработчики, которые компетентны выполнять данную задачу (зачастую, практически все), выкладывают карты рубашкой вверх на стол с цифрой, которая равна story-points на выполнение данной задачи.
Оценивать задачу должен исполнитель. Если у исполнителя нет компетенции в какой-то области, которая важна для выполнения задачи, он должен обратиться к соответствующему специалисту или к ведущему программисту. В ряде случаев оценку может производить и ведущий специалист, но он обязательно должен согласовать свою оценку с программистом, который будет задачу выполнять.
Главное при выполнении эстимейта — это декомпозиция и оценка сложности задачи. Эти навыки пролявляются с опытом, когда человек из раза в раз самостоятельно выполняет данную работу и учитывает ошибки, совершенные в предыдущие разы. Игра в карты не помогает ставить такие навыки.
Я считаю, чтобы изначально сотрудники познакомились с новой системой, должна быть наглядная визуализация.
При работе с электронными системами контроля задач важны следующие навыки:
- грамотно и понятно называть задачи;
- умение пользоваться поиском и фильтрами;
- умение вовремя обновлять статус задачи;
- умение грамотно закрывать задачу (нужно указать номер ревизии, в которой задача реализована);
- умение следить за статусом задачи после того, как она перейдет на тестирование, т.к. задача может тестирование не пройти, и потребуются изменения.
Работа с бумажными карточками эти навыки НЕ ставит.
Планерка состоит в том, что вед. объясняет остальным, как решать поставленные задачи, так как любому может достаться любая задача, то и на планерка должны быть все.
Да, — это по той причине, что задачи пересекаются и могут достаться любому, и чтобы не объяснять по десять раз, если исполнитель поменяется, собираемся, чтобы объяснить один раз.
При работе с электронными системами контроля задач важны следующие навыки:
грамотно и понятно называть задачи;
умение пользоваться поиском и фильтрами;
умение вовремя обновлять статус задачи;
умение грамотно закрывать задачу (нужно указать номер ревизии, в которой задача реализована);
умение следить за статусом задачи после того, как она перейдет на тестирование, т.к. задача может тестирование не пройти, и потребуются изменения.
Я с вами полностью согласен, что нужно пользоваться электронными системами, к этому мы и пришли своим путем.
Оценивать задачу должен исполнитель.
К этому мы тоже пришли, но это правильно, если исполнитель один и не изменим не при каких обстоятельствах.
UFO just landed and posted this here
UFO just landed and posted this here
Sign up to leave a comment.
Как мы познакомились с Agile & Scrum