Вы считаете, что скрам не работает потому что разработчиков не интересует компания, то чем они занимаются и у них проблемы с ответственностью и честностью?
Давление в скраме как раз взято под контроль. Команда берет в спринт то что считает, что успеет сделать. А дальше да — взяли на себя ответственность по объему спринта — обязаны сфокусировать усилия именно на нём. Причем именно сфокусировать усилия, а не непременно завершить. А с тем скрамом, что вы описали (с блэкджеком и давлением), увы, потрясающих успехов не достичь.
Еще называется карго культ. Сделать самолет из глины и палок и ждать что из него вывалятся телевизоры и айфоны. Печально, что дурное исполнение часто рушит доверие именно к самому подходу, а не к конкретному исполнению.
Боюсь дэйли можно проводить хреново как, собственно, и описывать задачи. За 90 секунд можно сказать многое. Но вообще-то такого ограничения нет, есть только ограничение 15 минут на весь дэйли. Если возникают вопросы, которые надо обсудить детально — назначаются отдельные встречи с заинтересованными сторонами.
В таком случае, если человек готов к дейли и не размазывает сопли вместо того чтобы коротко и ясно изложить свой вклад, то 90 секунд бывает даже много.
Сделал задачи такие-то, планирую сделать такие-то, не понимаю такую-то задачу — Вася, давай обсудим. Петя, когда вы собираетесь обсуждать то-то? Меня подключите к обсуждению. Бывает и 30 секунд достаточно.
Это один из принципов XP — создание информационного пространства, чтобы информация воспринималась между прочим — визуализация и сидение в одной комнате.
Опен спейс правда несколько избыточен для этого т.к. чаще всего в опен спейсе сидит куча людей, которые не имеют отношения к команде.
Но тем не менее — ежедневный стендап это петля обратной связи. Возможно конкретно вы всё и так знаете, но я не видел такой команды, которая могла бы синхронизироваться без дэйли. Находятся вопросы для прояснения, обсуждения и корректировки. Да, не каждый раз, но и времени дэйли занимает немного — не более 15 минут. Зато при должном исполнении даёт гарантию, что ничего не забыто. Потом при релизе никто не говорит — вот это забыли, вот это забыли и вон то сделали неправильно. Всё уже давно обсудили и решили на дэйли.
Сркам вообще штука забавная. Он даёт несколько петель обратной связи чтобы корректировать движение по многим фронтам. Используется в условиях серьезной неопределенности для корректировки как самого продукта так и процессов. Неопределенность сложно и долго решать через жиру. Прямая коммуникация как минимум быстрее. Можно конечно нанять аналитика, который всё заранее просчитает и сам решит, но аналитики чаще всего не владеют всей полнотой умений для принятия единоличного решения да и ситуация меняется или появляется новая информация в том числе внутри спринта, которая влияет на ход работы.
Просто «фигачить код» в разработке с большой неопределенностью, к сожалению, не работает.
Метафора про карандаш хорошая.
Тупой карандаш это обмен информацией на дэйли.
Острая память — надежда, что все посмотрят твой комментарий в жире, правильно поймут формулировку задачи или не пропустят уведомление из жиры об очень важной штуке.
Так вы сравните вкус хлеба испеченного в одном месте с хлебом испеченном в другом месте?
Или может быть сравните не с хлебом а с мамалыгой?
Или может быть сравните хлеб испеченный в разных печах?
Если раз за разом делать одно и тоже то и результат будет такой же.
Вы не забывайте предлагать. Идеальная критика диаметром 1м и массой 1 кг в вакууме бесполезна. Сравнивайте. Говорите «так недо», но не забывайте продолжать «а надо так-то».
Вы не ответили на вопрос.
Есть такой принцип, который явно показывает, где ответственный человек, а где — поболтать пришел.
Критикуешь — предлагай. Предлагаешь — делай.
1. Я пока в своей жизнь, в разработке ПО, не встречал случая, где разработку архитектуры стоит выносить в отдельную фазу. Может у меня мало опыта, а может «отдельная фаза» просто привычное дело, которое пихают во все щели просто потому что это привычно? Впрочем допускаю, что где-то это может пригодиться, но пока еще такого не встретил.
Интеграционные тесты вполне уместны в Agile. Тот же Дядюшка Боб или Гойко Аджич хорошо описали как их надо делать. Все что автоматизируется — хорошо ложится в рамки Agile. То что не автоматизируется — может не лечь красиво.
2. Нет проблем, есть фреймворки для масштабирования.
3. Релизы не должны совпадать со спринтами. Спринты вообще не являются неотъемлемой частью Agile.
4. Здесь сложнее.
Но вообще-то вы затронули темы совершенно новые, не относящиеся к теме статьи никак. Основной посыл статьи — компании хорошо, а человеку — плохо. Это не так. Agile учит сотрудничеству и создавать ценный продукт вместо прикрывания своего зада и игры в футбол. Agile это этап развития, который учит людей работать совместно. Agile учит командной работе. Agile даёт удовольствие от работы, если конечно участник команде не хочет только крутить бесполезные гайки. Такой человек, да, будут выгнан самой командой, т.к. он просто не работает на общую цель.
Зачем пилится продукт очень даже хорошо узнается, если об это хотя бы просто поговорить, но тот же Lean заставляет работать над портретами своих клиентов, понимать их потребности, обозначать гипотезы и проверять их. Тот же скрам заставляет имперически проверять что работает для клиентов, а что нет. В итоге приходит поинимание, что проект пилится для таких-то людей, которые ночью любят покушать, а днем поездить на велосипеде, грубо говоря. Это как минимум — становится понятно зачем этот продукт клиенту. При этом, конечно никто не заставляет формулировать цель продукта для производителя, это уже не из области agile, это из области управления портфелем.
Целеполагание лежит в основе, как я уже сказал, одного из фреймворков. Оно есть по определению. Его нет, если разработка по сути «хаотическая».
Про когда закончим, откровенно говоря, вообще вопрос дискуссионный. Хотя бы потому что другие инструменты тоже не отвечают на этот вопрос сколько нибудь точно. Любые планы оказываются ложью, хоть строительство космического корабля, хоть моста, хоть разработка ПО для магазина одежды для кошек. Но, по-крайней мере в скраме, планы строятся на основе факта о производительности команды.
Это эмпирический опыт многих людей. Работая в отделе фронтенд, ты даже не знаешь зачем пилится продукт. Поэтому будьте уверены — вовлеченность значительно больше. Целеполагание, прозрачность, инспекция бэклога участниками команды — это все составляющие части одного из Agile фреймворков. Они не то чтобы дают вовлеченность, это просто одна из основных ЦЕЛЕЙ.
Тут как раз всё понятно, если вспомнить про отношение «является».
Любой квадрат является прямоугольником.
Не любой прямоугольник является квадратом.
Квадрат расширяет Прямоугольник.
В том то и дело, что принятие решений согласно Лалу упрощается по сравнению с тем как это делается в небольших Agile командах. Потому и возможно принятие решений в значительно бОльших коллективах.
У Фокуса много сторон, но часто не хватает именно понимания как конкретные действия помогают цели.
Мало кто готов работать в плоских командах. Люди Agile-то до сих пор понять не могут — «как это нет начальников?». А уж бирюзу и того сложнее понять. Совершенно непривычно и потому очень интересно.
Работать получается.
Зарабатывать деньги — тоже.
Простите, кто мне должен и почему? Не понял. Есть цель и я к ней стремлюсь. Никого не считаю должным помогать мне. Но желающих всегда приветствую.
В таком случае, если человек готов к дейли и не размазывает сопли вместо того чтобы коротко и ясно изложить свой вклад, то 90 секунд бывает даже много.
Сделал задачи такие-то, планирую сделать такие-то, не понимаю такую-то задачу — Вася, давай обсудим. Петя, когда вы собираетесь обсуждать то-то? Меня подключите к обсуждению. Бывает и 30 секунд достаточно.
Опен спейс правда несколько избыточен для этого т.к. чаще всего в опен спейсе сидит куча людей, которые не имеют отношения к команде.
Но тем не менее — ежедневный стендап это петля обратной связи. Возможно конкретно вы всё и так знаете, но я не видел такой команды, которая могла бы синхронизироваться без дэйли. Находятся вопросы для прояснения, обсуждения и корректировки. Да, не каждый раз, но и времени дэйли занимает немного — не более 15 минут. Зато при должном исполнении даёт гарантию, что ничего не забыто. Потом при релизе никто не говорит — вот это забыли, вот это забыли и вон то сделали неправильно. Всё уже давно обсудили и решили на дэйли.
Просто «фигачить код» в разработке с большой неопределенностью, к сожалению, не работает.
Тупой карандаш это обмен информацией на дэйли.
Острая память — надежда, что все посмотрят твой комментарий в жире, правильно поймут формулировку задачи или не пропустят уведомление из жиры об очень важной штуке.
Или может быть сравните не с хлебом а с мамалыгой?
Или может быть сравните хлеб испеченный в разных печах?
Если раз за разом делать одно и тоже то и результат будет такой же.
Так вы сравните вкус в итоге?
Есть такой принцип, который явно показывает, где ответственный человек, а где — поболтать пришел.
Критикуешь — предлагай. Предлагаешь — делай.
Интеграционные тесты вполне уместны в Agile. Тот же Дядюшка Боб или Гойко Аджич хорошо описали как их надо делать. Все что автоматизируется — хорошо ложится в рамки Agile. То что не автоматизируется — может не лечь красиво.
2. Нет проблем, есть фреймворки для масштабирования.
3. Релизы не должны совпадать со спринтами. Спринты вообще не являются неотъемлемой частью Agile.
4. Здесь сложнее.
Но вообще-то вы затронули темы совершенно новые, не относящиеся к теме статьи никак. Основной посыл статьи — компании хорошо, а человеку — плохо. Это не так. Agile учит сотрудничеству и создавать ценный продукт вместо прикрывания своего зада и игры в футбол. Agile это этап развития, который учит людей работать совместно. Agile учит командной работе. Agile даёт удовольствие от работы, если конечно участник команде не хочет только крутить бесполезные гайки. Такой человек, да, будут выгнан самой командой, т.к. он просто не работает на общую цель.
Целеполагание лежит в основе, как я уже сказал, одного из фреймворков. Оно есть по определению. Его нет, если разработка по сути «хаотическая».
Про когда закончим, откровенно говоря, вообще вопрос дискуссионный. Хотя бы потому что другие инструменты тоже не отвечают на этот вопрос сколько нибудь точно. Любые планы оказываются ложью, хоть строительство космического корабля, хоть моста, хоть разработка ПО для магазина одежды для кошек. Но, по-крайней мере в скраме, планы строятся на основе факта о производительности команды.
Это эмпирический опыт многих людей. Работая в отделе фронтенд, ты даже не знаешь зачем пилится продукт. Поэтому будьте уверены — вовлеченность значительно больше. Целеполагание, прозрачность, инспекция бэклога участниками команды — это все составляющие части одного из Agile фреймворков. Они не то чтобы дают вовлеченность, это просто одна из основных ЦЕЛЕЙ.
Любой квадрат является прямоугольником.
Не любой прямоугольник является квадратом.
Квадрат расширяет Прямоугольник.
У Фокуса много сторон, но часто не хватает именно понимания как конкретные действия помогают цели.
Мало кто готов работать в плоских командах. Люди Agile-то до сих пор понять не могут — «как это нет начальников?». А уж бирюзу и того сложнее понять. Совершенно непривычно и потому очень интересно.
Зарабатывать деньги — тоже.
Простите, кто мне должен и почему? Не понял. Есть цель и я к ней стремлюсь. Никого не считаю должным помогать мне. Но желающих всегда приветствую.