Только одно утверждение верно на счет методологии Agile: "Все понимают ее неверно". @fwip
Значит вы мне говорите, что у разработчиков есть 12 свободных недель в году, которые они могут потратить на что угодно, например, рисование, серфинг и прочие развлечения? Как это вообще может быть возможно в мире, где доминирует 8 часовой рабочий день, а в Китае вообще существует система 12 часового рабочего дня (72 часовая рабочая неделя - 996 working hour system).
Я считаю что ваша команда должна иметь столько разгрузочных дней, сколько ей комфортно и необходимо.
Напомню, что когда-то, на заре 20 века, внедрение системы 40 часовой рабочуй недели, тоже считалась радикальным решением. Напирмиер, компания Google, сравнительно недавно стала использовать идею, когда ее сотрудники работают 80% времени, а остальные 20% тратят на свои личные увлечения (хобби).
Китайская система 996 (работа с 9:00 до 21:00 6 дней в неделю), наоборот, пытается внедрить 72 часовую рабочую неделю. Я считаю это откатом в прошлое средневековье и считаю, что люди должны перестать пытаться ее внедрять и использовать, т.к. это не ведет к увеличению продуктивности работы.
Так же это зависит от вас, как вы будете понимать неделю разгрузки, возможно в эту неделю работники должны работать не в полную меру или вообще отдыхать, это уже вы решайте сами. Суть в том что должна быть неделя разгрузки для них. Можете включить ее в счет части отпусков или еще как-нибудь.
Просто ваша команда должна понимать, что у нее после трех недельного спринта есть неделя разгрузки. А что они будут делать в этот период вы решите сами.
Если в период спринта разработчик приступеает к решению назначенной на него задачи, значит ли это что он должен ее обязательно закрыть в текущем спринте?
Нет это не обязательно и зависит от степени сложности задачи. Если он не укладвается в период спринта, то на следующем этапе недельного плнанировани эта задача персматривается и проджект менеджер принимает решение о необходимости переноса ее в следующий спринт, или возврат в беклог, либо назначение на другого разработчика.
Можем ли мы понимать трехнедельные спринты, как очередные итерации разработки проекта?
Да, конешно. Просто в данном описании мы придерживаемся понятия спринт.
Почему 3-х недельные спринты?
Потому что работа по разработке плюс время на восстановление должно укладываться в 13 частей (интервалов) в год. Когда закончивается очередной цикл и начинается новый. Разгрузочная неделя обеспечивает моральную разгрузку перед началом нового периода очередного спринта.
Заничит ли это, что начало спринта и его окончание зачастую будут находится в середине календарного месяца?
Да.
Должны ли разработчики привлекаться к планированию очередного спринта?
Да. Разаработчикам не воспрещается посещять митинги по планированию очередного спринта. Просто зачастую им это не требуется, т.к. они итак видят свои задачи в системе трекинга и команда возможно уже обсуждала эти задачи на предыдыщем спринте.
Вообще я за минимизацию митингов. Вам нравятся митинги? Я сторонник того чтобы митинги собирались по острой необходимости и чтобы на них присутвовали только необходимые для обсуждения задач люди.
Нужно ли проводить ежедневные стендапы?
По моему опыту в этом нет необходимости. Обычно все кто стоит в кругу, слушают разговор одного человека 20 минут. Конечно, это вариант "как не нужно проводить стендапы", но я не видел пока ни одной команды, которая бы их проводила правильно, поэтому я бы просто рекомендовал их вообще не проводить. Такж нет смысла их проводить, если ваша команда распределена географически. Но если же вы считается что стендапы вам необходимы, то не буду вас от них отговариавть. Делайте как считаете лучше для своей команды.
Должны ли мы делать все в точности как описано в данных статьях по Agile Lite?
Нет, конечно. В статьях указаны рекомендации, а не беспрекословные требования.
Согласны ли вы с тем, что то, что работает для вас, может не работать для остальных?
Конечно, да.
Вы не должны точно оценивать сроки выполнения задач, т.к. точные оценки невозможны.
Все наши оценки задач мы должны рассматривать как приблизительные. Поэтому, зачастую, от оценок луше отказаться. Просто делайте качественно свою работу и оценивайте ее в интервале 4 часов своего рабочего времени. Например, успею ли я сделать это за 4 часа и т.д.
Разработчикам нельзя доверять, за ними нужно следить, и они должны постоянно отчитываться о проделанной работе. Потому что только так делается работа.
Абсолютно не согласен с данным утверждением. Я не смогу вам быстро объяснить почему это утверждение неверно, но скажу, что если вы так действительно считаете, то у нас с вами разные точки зрения на то, как должна быть организована работа команды разработки.
То что вы описали здесь это не Agile
Нет, не верно. Все что тут описано, это и есть методология Agile.
Это никогда не будет работать
Но это работает.
Вы неправильно трактуете и используете методологию Agile
К сожалению, проблема методологии Agile в том, что она не может быть сделана правильно =) Каждый ее делает по-своему.