Pull to refresh
25
Karma
0
Rating
Владимир Ряшенцев @vryashentsev

Пользователь

  • Followers 39
  • Following 6

Современная Android разработка на Kotlin. Часть 2

ObjectBox рекомендую

Семь проблем внедрения Scrum, о которых мы не знали

Вы считаете, что скрам не работает потому что разработчиков не интересует компания, то чем они занимаются и у них проблемы с ответственностью и честностью?

Семь проблем внедрения Scrum, о которых мы не знали

Давление в скраме как раз взято под контроль. Команда берет в спринт то что считает, что успеет сделать. А дальше да — взяли на себя ответственность по объему спринта — обязаны сфокусировать усилия именно на нём. Причем именно сфокусировать усилия, а не непременно завершить. А с тем скрамом, что вы описали (с блэкджеком и давлением), увы, потрясающих успехов не достичь.

Семь проблем внедрения Scrum, о которых мы не знали

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

Семь проблем внедрения Scrum, о которых мы не знали

Боюсь дэйли можно проводить хреново как, собственно, и описывать задачи. За 90 секунд можно сказать многое. Но вообще-то такого ограничения нет, есть только ограничение 15 минут на весь дэйли. Если возникают вопросы, которые надо обсудить детально — назначаются отдельные встречи с заинтересованными сторонами.

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

Сделал задачи такие-то, планирую сделать такие-то, не понимаю такую-то задачу — Вася, давай обсудим. Петя, когда вы собираетесь обсуждать то-то? Меня подключите к обсуждению. Бывает и 30 секунд достаточно.

Семь проблем внедрения Scrum, о которых мы не знали

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

Но тем не менее — ежедневный стендап это петля обратной связи. Возможно конкретно вы всё и так знаете, но я не видел такой команды, которая могла бы синхронизироваться без дэйли. Находятся вопросы для прояснения, обсуждения и корректировки. Да, не каждый раз, но и времени дэйли занимает немного — не более 15 минут. Зато при должном исполнении даёт гарантию, что ничего не забыто. Потом при релизе никто не говорит — вот это забыли, вот это забыли и вон то сделали неправильно. Всё уже давно обсудили и решили на дэйли.

Семь проблем внедрения Scrum, о которых мы не знали

Сркам вообще штука забавная. Он даёт несколько петель обратной связи чтобы корректировать движение по многим фронтам. Используется в условиях серьезной неопределенности для корректировки как самого продукта так и процессов. Неопределенность сложно и долго решать через жиру. Прямая коммуникация как минимум быстрее. Можно конечно нанять аналитика, который всё заранее просчитает и сам решит, но аналитики чаще всего не владеют всей полнотой умений для принятия единоличного решения да и ситуация меняется или появляется новая информация в том числе внутри спринта, которая влияет на ход работы.
Просто «фигачить код» в разработке с большой неопределенностью, к сожалению, не работает.

Семь проблем внедрения Scrum, о которых мы не знали

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

Где Agile ужасен, особенно Scrum

Так вы сравните вкус хлеба испеченного в одном месте с хлебом испеченном в другом месте?
Или может быть сравните не с хлебом а с мамалыгой?
Или может быть сравните хлеб испеченный в разных печах?
Если раз за разом делать одно и тоже то и результат будет такой же.

Где Agile ужасен, особенно Scrum

Конечно!
Так вы сравните вкус в итоге?

Где Agile ужасен, особенно Scrum

Вы не забывайте предлагать. Идеальная критика диаметром 1м и массой 1 кг в вакууме бесполезна. Сравнивайте. Говорите «так недо», но не забывайте продолжать «а надо так-то».

Где Agile ужасен, особенно Scrum

Вы не ответили на вопрос.
Есть такой принцип, который явно показывает, где ответственный человек, а где — поболтать пришел.
Критикуешь — предлагай. Предлагаешь — делай.

Почему в будущем Agile станет не нужен

1. Я пока в своей жизнь, в разработке ПО, не встречал случая, где разработку архитектуры стоит выносить в отдельную фазу. Может у меня мало опыта, а может «отдельная фаза» просто привычное дело, которое пихают во все щели просто потому что это привычно? Впрочем допускаю, что где-то это может пригодиться, но пока еще такого не встретил.
Интеграционные тесты вполне уместны в Agile. Тот же Дядюшка Боб или Гойко Аджич хорошо описали как их надо делать. Все что автоматизируется — хорошо ложится в рамки Agile. То что не автоматизируется — может не лечь красиво.
2. Нет проблем, есть фреймворки для масштабирования.
3. Релизы не должны совпадать со спринтами. Спринты вообще не являются неотъемлемой частью Agile.
4. Здесь сложнее.

Но вообще-то вы затронули темы совершенно новые, не относящиеся к теме статьи никак. Основной посыл статьи — компании хорошо, а человеку — плохо. Это не так. Agile учит сотрудничеству и создавать ценный продукт вместо прикрывания своего зада и игры в футбол. Agile это этап развития, который учит людей работать совместно. Agile учит командной работе. Agile даёт удовольствие от работы, если конечно участник команде не хочет только крутить бесполезные гайки. Такой человек, да, будут выгнан самой командой, т.к. он просто не работает на общую цель.

Почему в будущем Agile станет не нужен

Зачем пилится продукт очень даже хорошо узнается, если об это хотя бы просто поговорить, но тот же Lean заставляет работать над портретами своих клиентов, понимать их потребности, обозначать гипотезы и проверять их. Тот же скрам заставляет имперически проверять что работает для клиентов, а что нет. В итоге приходит поинимание, что проект пилится для таких-то людей, которые ночью любят покушать, а днем поездить на велосипеде, грубо говоря. Это как минимум — становится понятно зачем этот продукт клиенту. При этом, конечно никто не заставляет формулировать цель продукта для производителя, это уже не из области agile, это из области управления портфелем.

Целеполагание лежит в основе, как я уже сказал, одного из фреймворков. Оно есть по определению. Его нет, если разработка по сути «хаотическая».

Про когда закончим, откровенно говоря, вообще вопрос дискуссионный. Хотя бы потому что другие инструменты тоже не отвечают на этот вопрос сколько нибудь точно. Любые планы оказываются ложью, хоть строительство космического корабля, хоть моста, хоть разработка ПО для магазина одежды для кошек. Но, по-крайней мере в скраме, планы строятся на основе факта о производительности команды.

Почему в будущем Agile станет не нужен

Это эмпирический опыт многих людей. Работая в отделе фронтенд, ты даже не знаешь зачем пилится продукт. Поэтому будьте уверены — вовлеченность значительно больше. Целеполагание, прозрачность, инспекция бэклога участниками команды — это все составляющие части одного из Agile фреймворков. Они не то чтобы дают вовлеченность, это просто одна из основных ЦЕЛЕЙ.

Сударь, ваша команда — не команда

Вот такое у меня мнение по этому вопросу habr.com/post/349668

Принцип подстановки Барбары Лисков

Тут как раз всё понятно, если вспомнить про отношение «является».
Любой квадрат является прямоугольником.
Не любой прямоугольник является квадратом.
Квадрат расширяет Прямоугольник.

Создание компании. Идеология — first

В том то и дело, что принятие решений согласно Лалу упрощается по сравнению с тем как это делается в небольших Agile командах. Потому и возможно принятие решений в значительно бОльших коллективах.

У Фокуса много сторон, но часто не хватает именно понимания как конкретные действия помогают цели.

Мало кто готов работать в плоских командах. Люди Agile-то до сих пор понять не могут — «как это нет начальников?». А уж бирюзу и того сложнее понять. Совершенно непривычно и потому очень интересно.

Создание компании. Идеология — first

Работать получается.
Зарабатывать деньги — тоже.
Простите, кто мне должен и почему? Не понял. Есть цель и я к ней стремлюсь. Никого не считаю должным помогать мне. Но желающих всегда приветствую.

Создание компании. Идеология — first

Именно так в большинстве компаний и есть. И это очень грустно.

Information

Rating
Does not participate
Location
Томск, Томская обл., Россия
Date of birth
Registered
Activity