вторник, 25 марта 2014 г.

AgileDays'14, день второй

Выступление Антона Волкова на AgileDays'13 произвело на меня очень сильное впечатление. Я долго думал, как бы использовать эти идеи у себя в команде, К концу года у меня созрел план и вот уже почти месяц я тестирую на команде свою систему рейтингов. Не удивительно что я очень ждал доклада Антона.

Возможно поэтому доклад Дамира Тенишева почти не отложился в памяти :). Пришлось восстанавливать по записям. К вопросу про старичков - ротация необходима, хотя и болезненна. Группировка вокруг задач, ну это все и так ясно. Понравилось ограничение на размер кода по фиче.

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

Для того, чтобы понять какие люди нужны, нужно понять, насколько эти люди разделяют твою цель. А для этого нужно понять, какова твоя цель. Альтернатива Платформ поставила себе амбициозную цель на пять лет вперед. И построили план достижения этой цели. И идут по нему.

В обычной жизни не все люди понимают, куда идет их компания. Не всем понятно даже, зачем они пишут код? Для чего? Для кого они выпускают релиз? Зачем в релизе все эти фичи? Да что говорить о простых разработчиках, даже руководители не всегда понимают - нафига. Нужно попытаться больше задавать неудобных вопросов, чтобы побудить руководителей задуматься. Конечно, какие-то планы у нашей компании есть. Может быть они тоже амбициозные, но проблема в том, что рядовые сотрудники вообще не в теме.
Что же касается коммуникаций - каждый понимает в меру своей испорченности. Не надо рассчитывать что сказанное будет понято правильно. Фиксируйте, детализируйте, визуализируйте в конце концов. И что важно - никому нельзя верить на слово. :) Кто там код взялся без требований писать, когда непонятно, как это должно быть?

В систему соглашений они добавили коэффициенты по разным аспектам. Открытость, Сроки, Ошибки, Практики, Технологии, точно не помню. Команда может осознанно продолбать срок, но компенсировать это на Технологиях к примеру. Но думаю, что для этого надо достичь определенного уровня зрелости в команде. Я пока не хочу усложнять свою крайне простую систему, про котороую попозже обязательно напишу.

Асхат, как всегда на гребне волны. Тренд NoEstimations появился сравнительно недавно. И всем в SCRUM влом тратить по полтора дня на планирование. Логично, что надо меньше планировать. :) Кроме того нельзя недооценивать важного факта: Нет оценок, значит их нельзя сорвать. :)

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

Психологические доклады из малого зала не сильно зацепили. Хотя что-то в голове про фиксацию и про позитивную психологию крутится. Чиксентмихайю я читал, надо будет Селигмана почитать, и про фиксацию.

Ретроспективы. У нас не очень то проводятся ретроспективы, надо это дело чинить. Тимофей Евграшин предложил много интересных методик проведения и инструментов ретроспектив. Шесть смайликов - понравилось, каждый участник на ретроспективе должен выбрать два, которые по его мнению характеризуют прошедший спринт.

Максим Дорофеев зря прибедняется. Великий гуру теории ограничений. :) Надо будет поприставать по почте, а то блин Голдратта почитал, Детмера почитал, но полноценных диаграмм пока не получается. Понятно, что за каждой диаграмой у Макса тоже стоят часы раздумий. Не совсем понятно, что делать с нытьем. У Стейкера бумажки делятся на факты, мнения и предположения. Вероятно в диаграммы надо стараться включать факты, чтобы диаграмма была корректна для всех (никто ж против фактов не спорит :). Грозовая туча должна строится только при наличии двух сторон, одна сторона не может конфликтовать. Короче, есть еще куда расти.

Несколько мыслей напоследок:

Не все хорошие идеи достойны реализации.

Перевод идей в Ready to Devel, это обязательство заказчика. Тем самым он подтверждает, что одобряет затраты на разработку.

Когда команды работает над тем, что не приносит пользу, это называется Failure Demand (Ложная загрузка).
PS: Подарков было много, но всеравно хочется больше. :) Спасибо организаторам и всем участникам.