Давно хотел систематизировать свой взгляд на методологии разработки ПО, на взаимодействие менеджера и программиста (функционального тимлида и тимлида разработки), но всё не попадалась точка опоры, оттолкнувшись от которой, можно порассуждать. И вот эта точка опоры появилась. Коллега прислал ссылку на манифест (RU), который, как представляется, легко овладевает неокрепшими умами посредством своей категоричности и ненормативной лексики.
Читать полностью »
Метка «скрам»
О менеджерах, разработчиках и скрамах
2014-03-28 в 13:30, admin, рубрики: agile, scrum, методологии разработки, отношения с коллегами, разработка, скрам, метки: agile, scrum, методологии разработки, отношения с коллегами, скрамАты-баты шли «скрам-баты», или 85 заблуждений и препятствий гибкой разработки
2013-03-07 в 7:30, admin, рубрики: agile, scrum, аджайл, Блог компании «SCRUMguides», гибкая разработка, ошибки управления, скрам, управление проектами, метки: agile, scrum, аджайл, гибкая разработка, ошибки управления, скрам 
Термин «скрам-бат» (scrumbut) впервые начал использовать Кен Шуэйбер что бы описать неверную трактовку или умышленную модификацию правил скрам, что бы уйти от болезненной правды о процессе, которую он помогает открыть.
Типичная формулировка скрам-бата выглядит так:
У нас скрам, но <Причина>, <ОбходнойПуть>
Где Причина — это описание дискомфорта, неприятного открытия с которым команда в силу тех, или иных причин не может справиться. А Обходной путь — это способ закрыть глаза на проблему, или устранить «симптомы», не разобравшись с причинами «организационного заболевания».
Типичные примеры скрам-батов, соответственно, выглядят так:
- У нас скрам, но мы не всегда успеваем закончить всю взятую работу, поэтому меняем длину итерации.
- У нас скрам, но все проблемы, которые мы могли устранить мы уже устранили, поэтому мы не проводим ретроспективы .
Мы стараемся термином «скрамбат» не злоупотреблять, поскольку некоторые типы отклонений свойственны началу внедрения аджайл и являются частью эволюции процесса. Например, если у вас скрам, но вы не делаете TDD, у вас нет парного программирования и слабо выраженное коллективное владение кодом — возможно, вы просто в начале пути. Причины могут быть разными — от неумения «продать» ценность инженерных практик менеджменту до неумения их «готовить». И то и другое можно научиться делать, но это занимает определенное время, верно?
Однако, каждый раз, когда я слышу «у нас скрам, но» в зрелых командах, я пытаюсь услышать нечто большее большее о причинах, которые такую модификацию обуславливают. И знаете, что? Веских причин на самом деле очень мало. Скорее, это непонимание ценностей гибкой разработки, недостаток смелости и силы что бы им следовать, которые вместе образуют процессное «скрамно».
Работая с командами, мы собрали список из 85 заблуждений и препятствий успешного внедрения гибкой разработки. Многие выходят за рамки правил карсасса скрам. В зависимости от контекста проекта, некоторые пункты могут иметь большее или меньшее влияние, и иметь оправдания обстоятельствами. Однако мы верим, что каждый элемент этого списка провоцирует искаженение ценностей и принципов Agile.
Читать полностью »
Больше, чем plain vanilla scrum. Общепринятые практики работы с требованиями
2013-02-26 в 9:39, admin, рубрики: agile, Блог компании «SCRUMguides», скрам, требования, управление проектами, метки: скрам, требованияНедавно, на Скрам портале была опубликована статья Майка Кона об Общепринятых практиках в Скраме — практиках, которые довольно часто встречаются в Скрам-проектах, но не являются базовыми правилами Скрам.
Скрам поощряет подобные добавления и специально построен минималистично, дабы команды могли добавить то, что им по вкусу. Не стоит путать подобные улучшения процесса с печально известным Скрам-ном. В отличие от последнего, добавленные практики улучшают процесс, повышая эффективность выпуска продуктов и выравнивая поток работ.
Сегодня я хочу поделиться множеством таких практик, собранных вокруг работы с требованиями. За последние несколько лет перечисленные практики мне не раз довелось наблюдать за кулисами у успешных команд в роли agile-коуча и рассказывать о них на тренингах Certified ScrumMaster в роли скрам-тренера.
Я ни в коем случае не претендую на полноту практик и буду рад услышать дополнения. Некоторые из перечисленных практик заслуживают отдельных статей — это work in progress.
«Идеальный» скрам: вредные советы
2013-02-08 в 7:02, admin, рубрики: agile, аджайл, Блог компании Luxoft, разработка, скрам, метки: аджайл, скрамМногие компании уверяют, что работают по гибким методологии. Но там ли это? Возьмем, к примеру, скрам. Скрам давно испытанный и отточенный на практике рабочий процесс, но всегда ли он помогает в разработке? Может ли хорошо отлаженный процесс служить не поплавком, но грузилом? Я не являюсь скрам-тренером или кем-то подобным, просто хочу дать несколько анти-советов, которые, надеюсь, помогут взглянуть на скрам со стороны.
Управление временем и все-все-все в YouTrack 4.1
2012-11-08 в 17:51, admin, рубрики: agile, github, jetbrains, kanban, release, scrum, time management, youtrack, баги, Блог компании JetBrains, задачи, скрам, управление временем, управление проектами, метки: agile, github, jetbrains, kanban, release, scrum, time management, youtrack, баги, задачи, скрам, управление временем, управление проектамиТолько что вышло обновление для баг-трекера YouTrack: в версии 4.1 появились очень полезные функции для управления проектами и не только.
Управление временем
Итак, главное нововведение в версии 4.1 — возможность управлять временем! Теперь вы можете контролировать время, затраченное на выполнение задачи, итерации или всего проекта, и сравнивать его с предварительной оценкой. Создавайте отчеты о затраченном времени, чтобы быть в курсе того, как ваша команда справляется с выполнением задач.
Читать полностью »