#agile #scrum #процессы
Жизнь по скраму
Общаясь с разными людьми, убеждаюсь, что сейчас все живут по скраму. На худой конец, используют какую-нибудь вариацию на тему аджайла. Хтонический ужас водопада можно встретить только в госухе и детских страшилках. Каждая команда живет коротким спринтами, ведет бэклог, рефлексирует на ретро, пишет и оценивает юзер стори. Мир светел и прекрасен. Но есть нюанс.
Если вспомнить труды блаженного Сазерленда, в скраме результатом каждого спринта должен быть Инкремент Продукта, который несет реальную ценность для заказчика или пользователя. Инкремент Продукта мы в конце спринта выкатываем на живых людей, чтобы оперативно получить обратную связь. Анализируя фидбек от пользователей, мы можем скорректировать наши планы по развитию продукта, чтобы не строить никому не нужный космолет. При этом мы не завязываемся на жесткие даты, потому что к моменту большого релиза у нас может полностью измениться понимание того, что нужно в итоге сделать.
Ровно эти идеи, на мой взгляд, обеспечивают гибкость при разработке продукта.
А теперь посмотрим, что зачастую называют скрамом в нашей уютной it-шечке:
1. Живем двухнедельными спринтами
2. Выпускаем новые фичи для пользователей раз в 2-3-6 месяцев
3. В начале работы над крупной фичей оцениваем (а лучше сразу коммитимся на них) сроки, когда она будет готова
Выходит, что спринт - это не более, чем квант планирования. Фидбек получаем раз в полгода. Гибко изменять состав релиза не можем - сроки же, да и пообещали руководству или акционерам. Вот и где здесь скрам?
При этом есть противоположный пример.
Команда одного не слишком большого, но достаточно известного банка, жила трех(!) месячными спринтами. При этом каждый раз они поставляли на прод функциональность, несущую реальную ценность для клиентов. Над ними все ржали - ну какой же это скрам?! У вас же спринт три месяца!
Почему так происходит?
1. Обычный карго-культ, когда берем внешние атрибуты методологии, не вникая в ее суть.
2. Последствия быстрого роста. Когда были маленькими, все получалось, но на фоне взрывного роста процессы как-то поломались. Даже заметить не успели.
3. Скрам в компании - это не более, чем маркетинг и следование трендам, чтобы завлекать сотрудников. Тогда вопросов нет. Только не забудьте про смузи.
4. Самый очевидный вариант, который я не увидел.
Жизнь по скраму
Общаясь с разными людьми, убеждаюсь, что сейчас все живут по скраму. На худой конец, используют какую-нибудь вариацию на тему аджайла. Хтонический ужас водопада можно встретить только в госухе и детских страшилках. Каждая команда живет коротким спринтами, ведет бэклог, рефлексирует на ретро, пишет и оценивает юзер стори. Мир светел и прекрасен. Но есть нюанс.
Если вспомнить труды блаженного Сазерленда, в скраме результатом каждого спринта должен быть Инкремент Продукта, который несет реальную ценность для заказчика или пользователя. Инкремент Продукта мы в конце спринта выкатываем на живых людей, чтобы оперативно получить обратную связь. Анализируя фидбек от пользователей, мы можем скорректировать наши планы по развитию продукта, чтобы не строить никому не нужный космолет. При этом мы не завязываемся на жесткие даты, потому что к моменту большого релиза у нас может полностью измениться понимание того, что нужно в итоге сделать.
Ровно эти идеи, на мой взгляд, обеспечивают гибкость при разработке продукта.
А теперь посмотрим, что зачастую называют скрамом в нашей уютной it-шечке:
1. Живем двухнедельными спринтами
2. Выпускаем новые фичи для пользователей раз в 2-3-6 месяцев
3. В начале работы над крупной фичей оцениваем (а лучше сразу коммитимся на них) сроки, когда она будет готова
Выходит, что спринт - это не более, чем квант планирования. Фидбек получаем раз в полгода. Гибко изменять состав релиза не можем - сроки же, да и пообещали руководству или акционерам. Вот и где здесь скрам?
При этом есть противоположный пример.
Команда одного не слишком большого, но достаточно известного банка, жила трех(!) месячными спринтами. При этом каждый раз они поставляли на прод функциональность, несущую реальную ценность для клиентов. Над ними все ржали - ну какой же это скрам?! У вас же спринт три месяца!
Почему так происходит?
1. Обычный карго-культ, когда берем внешние атрибуты методологии, не вникая в ее суть.
2. Последствия быстрого роста. Когда были маленькими, все получалось, но на фоне взрывного роста процессы как-то поломались. Даже заметить не успели.
3. Скрам в компании - это не более, чем маркетинг и следование трендам, чтобы завлекать сотрудников. Тогда вопросов нет. Только не забудьте про смузи.
4. Самый очевидный вариант, который я не увидел.
👍1
#agile #scrum #процессы
По мотивам предыдущего поста. В одном из выступлений Алексея Пименова услышал интересную мысль о том, когда нужно использовать скрамоподобные подходы.
Далее вольная цитата: “Посчитайте по спринтам средний процент фичей, которые вы выкатили пользователям, а потом убрали. Если он равен нулю, то скрам вам не нужен, т.к. вы с абсолютной точностью угадываете, что хочет пользователь”.
Логично - нет смысла тратиться на все эти скрамы, если мы заранее знаем, что нужно рынку. Либо другой вариант - угадываем мы не все, но фидбек рынка (продуктовые метрики) не отслеживаем, или у нас нет механизма управления продуктом на основе этого фидбека.
К чему это? Надо бы чаще рефлексировать, зачем мы внедряем те или иные подходы.
По мотивам предыдущего поста. В одном из выступлений Алексея Пименова услышал интересную мысль о том, когда нужно использовать скрамоподобные подходы.
Далее вольная цитата: “Посчитайте по спринтам средний процент фичей, которые вы выкатили пользователям, а потом убрали. Если он равен нулю, то скрам вам не нужен, т.к. вы с абсолютной точностью угадываете, что хочет пользователь”.
Логично - нет смысла тратиться на все эти скрамы, если мы заранее знаем, что нужно рынку. Либо другой вариант - угадываем мы не все, но фидбек рынка (продуктовые метрики) не отслеживаем, или у нас нет механизма управления продуктом на основе этого фидбека.
К чему это? Надо бы чаще рефлексировать, зачем мы внедряем те или иные подходы.
Telegram
Yet another SA channel
#agile #scrum #процессы
Жизнь по скраму
Общаясь с разными людьми, убеждаюсь, что сейчас все живут по скраму. На худой конец, используют какую-нибудь вариацию на тему аджайла. Хтонический ужас водопада можно встретить только в госухе и детских страшилках.…
Жизнь по скраму
Общаясь с разными людьми, убеждаюсь, что сейчас все живут по скраму. На худой конец, используют какую-нибудь вариацию на тему аджайла. Хтонический ужас водопада можно встретить только в госухе и детских страшилках.…
#цитаты
Банальная, но бесконечно прекрасная история. Всегда бы так было в жизни.
Прикольный канал, кстати, люблю формат заметок. Жаль, что мало.
“Был год, если не ошибаюсь, 2014. Я только начал активно участвовать в продажах. И вот в конце года к нам пришел потенциальный проект. Я вел пресейл, начиная с первого звонка. Всё горело, нужно было до конца года вписаться в проект. Бюджет хороший, но все в мыле, нет времени объяснять, нужно срочно бежать. А я не понимаю куда🤯
И вот 30 декабря, последний рабочий день. Я приехал со встречи на наш корпоратив. Помню, сидя где-то в углу, написал письмо, в котором окончательно отказался от проекта. Самое интересное, что проект уходил к нашим прямым конкурентам. Кошмарный сон любого продавца🤭
Так вот, меньше чем через полгода этот проект к нам вернулся. Я спросил у нашего заказчика, почему он думает, что с нами получится? Ответ был примерно такой: вы вопросов много задаёте и хотите разобраться, а не бежите, сломя голову, увидев хороший бюджет.
А я опять к чему?🙃
🙋♂️ Задавайте вопросы, если не понимаете что-то. Да и если понимаете, тоже иногда полезно переспросить. Не бойтесь показаться глупым.
⏱ Чем меньше времени на принятие решения, тем сильнее нужно тормозить. Это про ожидания”.
Банальная, но бесконечно прекрасная история. Всегда бы так было в жизни.
Прикольный канал, кстати, люблю формат заметок. Жаль, что мало.
“Был год, если не ошибаюсь, 2014. Я только начал активно участвовать в продажах. И вот в конце года к нам пришел потенциальный проект. Я вел пресейл, начиная с первого звонка. Всё горело, нужно было до конца года вписаться в проект. Бюджет хороший, но все в мыле, нет времени объяснять, нужно срочно бежать. А я не понимаю куда🤯
И вот 30 декабря, последний рабочий день. Я приехал со встречи на наш корпоратив. Помню, сидя где-то в углу, написал письмо, в котором окончательно отказался от проекта. Самое интересное, что проект уходил к нашим прямым конкурентам. Кошмарный сон любого продавца🤭
Так вот, меньше чем через полгода этот проект к нам вернулся. Я спросил у нашего заказчика, почему он думает, что с нами получится? Ответ был примерно такой: вы вопросов много задаёте и хотите разобраться, а не бежите, сломя голову, увидев хороший бюджет.
А я опять к чему?🙃
🙋♂️ Задавайте вопросы, если не понимаете что-то. Да и если понимаете, тоже иногда полезно переспросить. Не бойтесь показаться глупым.
⏱ Чем меньше времени на принятие решения, тем сильнее нужно тормозить. Это про ожидания”.
Telegram
Спокойно, договоримся!
Костя Степанов из HFLabs про переговоры, управление ИТ-компанией и удивительный мир вокруг🙃
#реклама #интеграция #API #REST
В феврале делаю тестовый запуск тренинга о REST API для самых маленьких.
Условия: присутствовать на всех занятиях, сделать дз и дать фидбек на выходе.
Даты: 14.02, 21.02, 28.02
UPD. Всем спасибо, группу собрали.
В феврале делаю тестовый запуск тренинга о REST API для самых маленьких.
Условия: присутствовать на всех занятиях, сделать дз и дать фидбек на выходе.
Даты: 14.02, 21.02, 28.02
UPD. Всем спасибо, группу собрали.
#интеграция #API #анонс
Описание API в Confluence
Завтра в 18:00 по мск намечается ламповая встреча с Олегом Игониным на тему документирования API в конфлюенс:
“Хочу рассказать о том, как у меня сложилась работа с описанием API методов в Confluence для постановки задачи на их реализацию разработчикам (структура страниц в confluence, структура заголовков, некоторая автоматизация, описание интерфейса метода и работы логики под капотом).
Будет пара примеров, которые можно будет использовать как "рыбу".
Залью это дело на ютуб, так что кому надо, тот сможет посмотреть задним числом.
Но в целом я не претендую на то, что это "единственно верный метод описания", для вас это будет один из вариантов, как люди работают в других компаниях. Можно будет что-то почерпнуть для себя.
В общем, возьму лампу, кота и буду рассказывать. 😂
Ссылка и id конференции:
https://us04web.zoom.us/j/75989849812?pwd=Q2Mra0thdi9EL0JYUVFDVUcwU1kyUT09
Идентификатор конференции: 759 8984 9812”
Описание API в Confluence
Завтра в 18:00 по мск намечается ламповая встреча с Олегом Игониным на тему документирования API в конфлюенс:
“Хочу рассказать о том, как у меня сложилась работа с описанием API методов в Confluence для постановки задачи на их реализацию разработчикам (структура страниц в confluence, структура заголовков, некоторая автоматизация, описание интерфейса метода и работы логики под капотом).
Будет пара примеров, которые можно будет использовать как "рыбу".
Залью это дело на ютуб, так что кому надо, тот сможет посмотреть задним числом.
Но в целом я не претендую на то, что это "единственно верный метод описания", для вас это будет один из вариантов, как люди работают в других компаниях. Можно будет что-то почерпнуть для себя.
В общем, возьму лампу, кота и буду рассказывать. 😂
Ссылка и id конференции:
https://us04web.zoom.us/j/75989849812?pwd=Q2Mra0thdi9EL0JYUVFDVUcwU1kyUT09
Идентификатор конференции: 759 8984 9812”
Zoom Video
Join our Cloud HD Video Meeting
Zoom is the leader in modern enterprise video communications, with an easy, reliable cloud platform for video and audio conferencing, chat, and webinars across mobile, desktop, and room systems. Zoom Rooms is the original software-based conference room solution…
#архитектура
Коллеги подогнали классный курс про проектированию нагруженных систем прямиком из альма-матер, ведет Олег Бунин. Оказывается, Олег не только организатор конференций, но еще и человек глубоко в теме, который умеет просто и понятно говорить о важных вещах.
Это не гламурный онлайн-курс, а запись живых семинаров со студентами, проходящих в режиме беседы между преподавателем и аудиторией. На занятиях обсуждают реальные задачи проектирования, в конце каждого дают задачу на подумать самостоятельно. Каких-то особенных технических вводных на входе не нужно, но как сериальчик посмотреть не получится - придется думать и периодически останавливаться. Если, конечно, вы не проходили это сами на боевых задачах.
Люто советую всем причастным к разработке и проектированию для расширения картины мира.
https://youtube.com/playlist?list=PL4_hYwCyhAvZuoK6Y0FaCh-25jEYtBvDo
Коллеги подогнали классный курс про проектированию нагруженных систем прямиком из альма-матер, ведет Олег Бунин. Оказывается, Олег не только организатор конференций, но еще и человек глубоко в теме, который умеет просто и понятно говорить о важных вещах.
Это не гламурный онлайн-курс, а запись живых семинаров со студентами, проходящих в режиме беседы между преподавателем и аудиторией. На занятиях обсуждают реальные задачи проектирования, в конце каждого дают задачу на подумать самостоятельно. Каких-то особенных технических вводных на входе не нужно, но как сериальчик посмотреть не получится - придется думать и периодически останавливаться. Если, конечно, вы не проходили это сами на боевых задачах.
Люто советую всем причастным к разработке и проектированию для расширения картины мира.
https://youtube.com/playlist?list=PL4_hYwCyhAvZuoK6Y0FaCh-25jEYtBvDo
#архитектура #интеграция #конференция
Подлодка запускает новую онлайн конфу, посвященную backend. Первая неделя будет о распределенных системах, вторая о протоколах передачи данных.
Кому были интересны архитектура и интеграция, может быть полезно.
https://podlodka.io/becrew?utm_campaign=BE-1-Early-Bird&utm_medium=social&utm_source=telegram&utm_content=BE-1-Early-Bird_PodlodkaNews
Подлодка запускает новую онлайн конфу, посвященную backend. Первая неделя будет о распределенных системах, вторая о протоколах передачи данных.
Кому были интересны архитектура и интеграция, может быть полезно.
https://podlodka.io/becrew?utm_campaign=BE-1-Early-Bird&utm_medium=social&utm_source=telegram&utm_content=BE-1-Early-Bird_PodlodkaNews
podlodka.io
Онлайн-конференция Podlodka Backend Crew, сезон #5
Недельное мероприятие от команды Podlodka: ежедневные интерактивные сессии в Zoom по актуальным проблемам backend-разработки, нон-стоп общение с экспертами и звёздами индустрии, закрытое профессиональное сообщество в Telegram.
#API #REST #интеграция
Вавилонская башня REST
Заметка о том, что люди в обыденной жизни называют RESTом, и как их понять.
Пока писал, нашел статью на схожую тему: https://habr.com/ru/post/319984/
На днях с интересом посмотрел доклад, где автор рассуждал о плюсах и минусах “REST-протокола”. В очередной раз вспомнил, что в термин REST человек может вкладывать примерно любой смысл. Усложняется история тем, что в сети полно статей и видосиков, дающих разные трактовки: одни говорят про правильные GET-POST-PUT, другие про JSON и XML, третьи вообще об архитектурных стилях рассуждают.
Вот моя версия Русско-Рестового словаря.
REST - это архитектурная концепция, которая рассказывает нам, как построить распределенную систему так, чтобы она была масштабируемой, производительной и со всех сторон успешной. Концепция включает в себя шесть принципов-ограничений, которым она должна удовлетворять. Возможно, глубокое изучение принципов никогда не понадобится аналитику, но часть из них стоит понять и осмыслить: модель client-server, stateless, кэширование – будет полезно не только при работе с REST-сервисами.
HATEOAS- идея гипермедиа, которую использует REST. Познакомиться можно на вики или тут. Встречается не так часто, но полезно для общего развития и философских дискуссий.
RESTful-сервис - сервис, удовлетворяющий принципам REST.
HTTP/1.1 - протокол передачи данных, на котором живет большая часть интернета. А вот REST протоколом не является.
Чтобы понять, как правильно использовать POST, PUT и статус коды, нужно читать спеку HTTP. Или для начала посмотреть статью на тему.
А теперь следим за руками. Несмотря на то, что в массовом сознании HTTP и REST неразлучны, REST никак не привязан к конкретному протоколу передачи данных. Можете спроектировать взаимодействия хоть поверх очередей, если ваши сервисы будут соответствовать принципам REST, то можно смело называть их RESTful-сервисами.
Но лучше об этом не говорить, т.к. собеседник может принять вас за сумасшедших. Да, для многих REST и HTTP почти синонимы.
Тогда что принято называть REST-сервисами в повседневной жизни? Здесь хочу обратиться к модели зрелости REST-сервисов Ричардсона. Он выделяет 4 уровня зрелости REST-сервисов:
Уровень 0. Мы берем в качестве протокола HTTP, но при этом игнорируем рекомендации по использованию HTTP-глаголов и именованию ресурсов aka endpoints. Часто в таких случаях используют POST с одним endpoint. Сюда можно отнести SOAP, XML-RPC, JSON-RPC и еще много чего.
Уровень 1. Начинаем правильно работать с ресурсами, но по-прежнему ограничиваемся одним HTTP-глаголом.
Уровень 2. Мы научились использовать HTTP-глаголы, статус коды и разделять endpoints так, как предусмотрено HTTP.
Уровень 3. Все то же самое, только дополнительно реализуем HATEOAS
Так вот, чаще всего REST-сервисами называют:
⁃ Сервис Уровня 0, который использует JSON. Так называемый JSON поверх HTTP, или JSON over HTTP
⁃ Сервис Уровня 2, т.е. правильное HTTP API
Кстати, многие считают, что REST-сервис - это обязательно JSON, XML использовать мы уже не можем. Хотя в концепции REST таких ограничений, конечно, нет.
Вавилонская башня REST
Заметка о том, что люди в обыденной жизни называют RESTом, и как их понять.
Пока писал, нашел статью на схожую тему: https://habr.com/ru/post/319984/
На днях с интересом посмотрел доклад, где автор рассуждал о плюсах и минусах “REST-протокола”. В очередной раз вспомнил, что в термин REST человек может вкладывать примерно любой смысл. Усложняется история тем, что в сети полно статей и видосиков, дающих разные трактовки: одни говорят про правильные GET-POST-PUT, другие про JSON и XML, третьи вообще об архитектурных стилях рассуждают.
Вот моя версия Русско-Рестового словаря.
REST - это архитектурная концепция, которая рассказывает нам, как построить распределенную систему так, чтобы она была масштабируемой, производительной и со всех сторон успешной. Концепция включает в себя шесть принципов-ограничений, которым она должна удовлетворять. Возможно, глубокое изучение принципов никогда не понадобится аналитику, но часть из них стоит понять и осмыслить: модель client-server, stateless, кэширование – будет полезно не только при работе с REST-сервисами.
HATEOAS- идея гипермедиа, которую использует REST. Познакомиться можно на вики или тут. Встречается не так часто, но полезно для общего развития и философских дискуссий.
RESTful-сервис - сервис, удовлетворяющий принципам REST.
HTTP/1.1 - протокол передачи данных, на котором живет большая часть интернета. А вот REST протоколом не является.
Чтобы понять, как правильно использовать POST, PUT и статус коды, нужно читать спеку HTTP. Или для начала посмотреть статью на тему.
А теперь следим за руками. Несмотря на то, что в массовом сознании HTTP и REST неразлучны, REST никак не привязан к конкретному протоколу передачи данных. Можете спроектировать взаимодействия хоть поверх очередей, если ваши сервисы будут соответствовать принципам REST, то можно смело называть их RESTful-сервисами.
Но лучше об этом не говорить, т.к. собеседник может принять вас за сумасшедших. Да, для многих REST и HTTP почти синонимы.
Тогда что принято называть REST-сервисами в повседневной жизни? Здесь хочу обратиться к модели зрелости REST-сервисов Ричардсона. Он выделяет 4 уровня зрелости REST-сервисов:
Уровень 0. Мы берем в качестве протокола HTTP, но при этом игнорируем рекомендации по использованию HTTP-глаголов и именованию ресурсов aka endpoints. Часто в таких случаях используют POST с одним endpoint. Сюда можно отнести SOAP, XML-RPC, JSON-RPC и еще много чего.
Уровень 1. Начинаем правильно работать с ресурсами, но по-прежнему ограничиваемся одним HTTP-глаголом.
Уровень 2. Мы научились использовать HTTP-глаголы, статус коды и разделять endpoints так, как предусмотрено HTTP.
Уровень 3. Все то же самое, только дополнительно реализуем HATEOAS
Так вот, чаще всего REST-сервисами называют:
⁃ Сервис Уровня 0, который использует JSON. Так называемый JSON поверх HTTP, или JSON over HTTP
⁃ Сервис Уровня 2, т.е. правильное HTTP API
Кстати, многие считают, что REST-сервис - это обязательно JSON, XML использовать мы уже не можем. Хотя в концепции REST таких ограничений, конечно, нет.
Хабр
А ваша служба является RESTful? Все что необходимо/обязательно знать про веб службы и REST
Введение Вот не люблю я изобретать велосипед и статью я бы эту не написал, но пришлось. Про REST сказано уже довольно много. Многие поставщики веб служб готовы к...
👍3❤1
#agile #scrum #процессы
Скрам для HR
Сейчас понял, что при внедрении “скрама” совсем не обязательно думать об ускорении разработки, уменьшении петли обратной связи и тюнинге процессов. Можно использовать его как инструмент развития HR-бренда.
1. Сначала сделаем ежедневные стендапы, где команда может пообщаться, кидая по очереди мячик, и размяться после целого дня в кресле. Особенно полезны эти минутки единства на удаленке, когда люди почти не видят друг друга.
2. Теперь нам нужна геймификация - повесим доску со стикерами или заведем борду в джире, где будем брать задачи словно квесты в рпг.
3. Организуем планирование спринта, на котором поиграем в покер, оценивая задачи в сторях, попугаях и кракенах. Нужно больше игровых механик.
4. В конце спринта собираемся всей командой и покупаем две пиццы. Потом два часа обсуждаем, что в спринте было хорошо, а что плохо.
Все, “скрам внедрен”. Теперь мы прогрессивная компания, используем гибкие методологии. Весело, модно, молодежно.
А теперь попробуем посчитать, чего мы добились. Предположим, что на “скрам”-ритуалы уходит 10-15% времени команды. Это легко измеримая сумма S, здесь проблем нет.
Дальше можем экспериментально сравнить стоимость найма, когда мы
⁃ рассказываем кандидатам о “скраме” в командах
⁃ говорим, что используем вотерфолл, каскадную разработку и вообще не против традиционных ценностей
Посчитав разницу, получаем выигрыш на одного нанятого сотрудника dH. Если нанимаем много и часто, то экономия H может быть серьезной.
В итоге сравниваем два числа: S и H. Если H больше, то смело масштабируем “скрам” на всю компанию. Тот случай, когда подражание внешним признакам способно принести профит. А со временем кто-нибудь и о смысле задумается.
Допускаю, что “скрам” еще уменьшает текучку за счет общения внутри команды, но не понимаю, как оценить это.
Пойду-ка гуглить статьи на тему, наверняка кто-то уже интересовался этим вопросом.
Скрам для HR
Сейчас понял, что при внедрении “скрама” совсем не обязательно думать об ускорении разработки, уменьшении петли обратной связи и тюнинге процессов. Можно использовать его как инструмент развития HR-бренда.
1. Сначала сделаем ежедневные стендапы, где команда может пообщаться, кидая по очереди мячик, и размяться после целого дня в кресле. Особенно полезны эти минутки единства на удаленке, когда люди почти не видят друг друга.
2. Теперь нам нужна геймификация - повесим доску со стикерами или заведем борду в джире, где будем брать задачи словно квесты в рпг.
3. Организуем планирование спринта, на котором поиграем в покер, оценивая задачи в сторях, попугаях и кракенах. Нужно больше игровых механик.
4. В конце спринта собираемся всей командой и покупаем две пиццы. Потом два часа обсуждаем, что в спринте было хорошо, а что плохо.
Все, “скрам внедрен”. Теперь мы прогрессивная компания, используем гибкие методологии. Весело, модно, молодежно.
А теперь попробуем посчитать, чего мы добились. Предположим, что на “скрам”-ритуалы уходит 10-15% времени команды. Это легко измеримая сумма S, здесь проблем нет.
Дальше можем экспериментально сравнить стоимость найма, когда мы
⁃ рассказываем кандидатам о “скраме” в командах
⁃ говорим, что используем вотерфолл, каскадную разработку и вообще не против традиционных ценностей
Посчитав разницу, получаем выигрыш на одного нанятого сотрудника dH. Если нанимаем много и часто, то экономия H может быть серьезной.
В итоге сравниваем два числа: S и H. Если H больше, то смело масштабируем “скрам” на всю компанию. Тот случай, когда подражание внешним признакам способно принести профит. А со временем кто-нибудь и о смысле задумается.
Допускаю, что “скрам” еще уменьшает текучку за счет общения внутри команды, но не понимаю, как оценить это.
Пойду-ка гуглить статьи на тему, наверняка кто-то уже интересовался этим вопросом.
#продуктвиность
Не смог пройти мимо поста, ибо когда-то перебирал всевозможные техники продуктивности и управления вниманием. В итоге принял, что лучше позаниматься рутиной и мелочевкой вместо того, чтобы ловить потоки. А когда увлекаюсь задачей, никакие отвлекающие помидоры не нужны.
https://t.me/pmdaily/780
Не смог пройти мимо поста, ибо когда-то перебирал всевозможные техники продуктивности и управления вниманием. В итоге принял, что лучше позаниматься рутиной и мелочевкой вместо того, чтобы ловить потоки. А когда увлекаюсь задачей, никакие отвлекающие помидоры не нужны.
https://t.me/pmdaily/780
Telegram
FEDOR BORSHEV
#вопрос Как тебе удаётся длительное время концентрироваться на одной задаче?
Основной лайфхак — я не пытаюсь длительное время концентрироваться на одной задаче: это жутко выматывает. Есть только один случай, когда я буду заниматься одной задачей больше часа…
Основной лайфхак — я не пытаюсь длительное время концентрироваться на одной задаче: это жутко выматывает. Есть только один случай, когда я буду заниматься одной задачей больше часа…
#оффтоп
Словарь начинающего руководителя.
“У нас очень амбициозная цель на третий квартал” - все понимают, что сроки нереальные, но вслух мы обсуждать это не будем.
Словарь начинающего руководителя.
“У нас очень амбициозная цель на третий квартал” - все понимают, что сроки нереальные, но вслух мы обсуждать это не будем.
#agile #процессы #команда #конференция
Впервые дошел ногами до тимлодконфа.
Илья Степырев - Game of Motivations
Илья разработал карточную игру, которая должна помочь выяснить мотивацию и приоритеты сотрудника. Без реальной практики оценивать ее бессмысленно, но демо на воркшопе выглядело интересно. Планирую пересмотреть запись и попробовать в реальности.
Общее представление об игре можно составить по презе.
https://teamleadconf.ru/moscow/2021/abstracts/6984
Анна Абрамова - Как мы переходили на гибкие методологии с неклассической структурой команд
История перехода от разрозненного недоэнтерпайза с хаотичными подходами к некоторой адекватной форме агила. Рыдал, т.к. такую же историю наблюдаю изнутри больше года.
Зацепила мысль - агил должен быть обоюдоострым. Разработка может строить сколь угодно гибкие процессы, но это бессмысленно, пока бизнес сам не готов к гибкости. Необходимо объяснить, насколько важно планировать и продумывать развитие на несколько шагов вперед и доносить это до разработки.
https://teamleadconf.ru/moscow/2021/abstracts/7502
Дмитрий Ильенков - Как сохранить лидерство в команде
Семь мыслей о том, как наладить и поддерживать здоровые отношения в команде. Откровений нет, но подача классная. Полезно иногда проглядывать, чтобы лишний раз подумать о своей работе.
https://teamleadconf.ru/moscow/2021/abstracts/7643
Алексей Самойлов - Ошибки умных людей, или аудит коллективов
Классный чеклист для диагностики проблем в коллективе, все на примере известных руководителей и команд: Ландау, Павлов и т.д.
В конце презы автор дает много ссылок на другие материалы по теме, тоже хочу посмотреть.
https://teamleadconf.ru/moscow/2021/abstracts/7220
Впервые дошел ногами до тимлодконфа.
Илья Степырев - Game of Motivations
Илья разработал карточную игру, которая должна помочь выяснить мотивацию и приоритеты сотрудника. Без реальной практики оценивать ее бессмысленно, но демо на воркшопе выглядело интересно. Планирую пересмотреть запись и попробовать в реальности.
Общее представление об игре можно составить по презе.
https://teamleadconf.ru/moscow/2021/abstracts/6984
Анна Абрамова - Как мы переходили на гибкие методологии с неклассической структурой команд
История перехода от разрозненного недоэнтерпайза с хаотичными подходами к некоторой адекватной форме агила. Рыдал, т.к. такую же историю наблюдаю изнутри больше года.
Зацепила мысль - агил должен быть обоюдоострым. Разработка может строить сколь угодно гибкие процессы, но это бессмысленно, пока бизнес сам не готов к гибкости. Необходимо объяснить, насколько важно планировать и продумывать развитие на несколько шагов вперед и доносить это до разработки.
https://teamleadconf.ru/moscow/2021/abstracts/7502
Дмитрий Ильенков - Как сохранить лидерство в команде
Семь мыслей о том, как наладить и поддерживать здоровые отношения в команде. Откровений нет, но подача классная. Полезно иногда проглядывать, чтобы лишний раз подумать о своей работе.
https://teamleadconf.ru/moscow/2021/abstracts/7643
Алексей Самойлов - Ошибки умных людей, или аудит коллективов
Классный чеклист для диагностики проблем в коллективе, все на примере известных руководителей и команд: Ландау, Павлов и т.д.
В конце презы автор дает много ссылок на другие материалы по теме, тоже хочу посмотреть.
https://teamleadconf.ru/moscow/2021/abstracts/7220
#требования #инструменты
У нас тут организовались ламповые посиделки об использовнии Requirements Yogi. Рады всем, кто хочет поделиться своим опытом или болью.
Вторник 18.05 в 19:00 по МСК
https://us02web.zoom.us/j/83151438146?pwd=VGFEQlMrTWx2YWlNWlIrTVBlaWtPQT09
Meeting ID: 831 5143 8146
Passcode: 279720
Приблизительная повестка:
1. История команды, которая планирует использовать RY. Какие проблемы хотят решить, почему смотрят на йогу.
2. Как мы используем RY и чем недовольны.
3. Опыт архитектора. Успешные кейсы использования RY.
4. Свободная дискуссия.
У нас тут организовались ламповые посиделки об использовнии Requirements Yogi. Рады всем, кто хочет поделиться своим опытом или болью.
Вторник 18.05 в 19:00 по МСК
https://us02web.zoom.us/j/83151438146?pwd=VGFEQlMrTWx2YWlNWlIrTVBlaWtPQT09
Meeting ID: 831 5143 8146
Passcode: 279720
Приблизительная повестка:
1. История команды, которая планирует использовать RY. Какие проблемы хотят решить, почему смотрят на йогу.
2. Как мы используем RY и чем недовольны.
3. Опыт архитектора. Успешные кейсы использования RY.
4. Свободная дискуссия.
Zoom Video
Join our Cloud HD Video Meeting
Zoom is the leader in modern enterprise video communications, with an easy, reliable cloud platform for video and audio conferencing, chat, and webinars across mobile, desktop, and room systems. Zoom Rooms is the original software-based conference room solution…
#интеграция #API #конференция
Analyst Days 12
Материалы, которые обещал участникам воркшопа по проектированию API.
https://microservice-api-patterns.org - коллекция паттернов проектирования API
https://twirl.github.io/The-API-Book/docs/API.ru.html - книга о проектировании API. Если все читать лень, то в контексте воркшопа можно ограничиться главами 10 и 11
http://www.servicedesignpatterns.com - книга и о проектировании web-сервисов. В большой степени ориентирована на разработчиков и архитекторов, но хорошо написано о поллинге и коллбеках и других полезных штуках
https://habr.com/ru/company/yandex/blog/442762/ - статья от яндекс такси об ужасах идемпотентности
Analyst Days 12
Материалы, которые обещал участникам воркшопа по проектированию API.
https://microservice-api-patterns.org - коллекция паттернов проектирования API
https://twirl.github.io/The-API-Book/docs/API.ru.html - книга о проектировании API. Если все читать лень, то в контексте воркшопа можно ограничиться главами 10 и 11
http://www.servicedesignpatterns.com - книга и о проектировании web-сервисов. В большой степени ориентирована на разработчиков и архитекторов, но хорошо написано о поллинге и коллбеках и других полезных штуках
https://habr.com/ru/company/yandex/blog/442762/ - статья от яндекс такси об ужасах идемпотентности
Решил зарегаться на GetMentor. Пишите, если интересно пообщаться.
https://getmentor.dev/andrey-burakov-299
https://getmentor.dev/andrey-burakov-299
https://getmentor.dev
Андрей Бураков | GetMentor – открытое сообщество IT-наставников
Product Manager / Teamlead / System Analyst @ NextWay | GetMentor – это открытое комьюнити IT-наставников, готовых делиться своими опытом и знаниями. Наша задача – помогать людям находить ответы на свои вопросы в работе или жизни через прямой доступ к экспертизе…
#мышление #требования
Еще один пример мышления письмом. Особенно полезно это упражнение аналитикам, когда формулируем сложные требования. Ибо требование есть мысль.
“Поймал себя на мысли, что пишу очень сложные предложения, длинные и сильносвязные. Полез проверять у классиков: Толстой, Чехов и другие - обнаружил, что доля сложносочиненных предложений очень невелика, а сложноподчинённые короткие. В итоге стал себя заставлять писать короткими предложениями. Оказалось, что пока ты стараешься укоротить предложение или разбить его на связные части - прокручиваешь изначальную мысль несколько раз. А ещё seo-плагин вордпреса умеет ругать статьи в бложеке по этой причине. Тоже меняю текст:) Как результат - сильный рост доступности и понятности текста. И вывих мозга” - утащено из одного чатика, автор @dumtest
Пока попробовал только в переписке, но уже чувствую результат.
Как-то у меня была заметка о подходе к переписке: https://t.me/another_sa/37
Еще один пример мышления письмом. Особенно полезно это упражнение аналитикам, когда формулируем сложные требования. Ибо требование есть мысль.
“Поймал себя на мысли, что пишу очень сложные предложения, длинные и сильносвязные. Полез проверять у классиков: Толстой, Чехов и другие - обнаружил, что доля сложносочиненных предложений очень невелика, а сложноподчинённые короткие. В итоге стал себя заставлять писать короткими предложениями. Оказалось, что пока ты стараешься укоротить предложение или разбить его на связные части - прокручиваешь изначальную мысль несколько раз. А ещё seo-плагин вордпреса умеет ругать статьи в бложеке по этой причине. Тоже меняю текст:) Как результат - сильный рост доступности и понятности текста. И вывих мозга” - утащено из одного чатика, автор @dumtest
Пока попробовал только в переписке, но уже чувствую результат.
Как-то у меня была заметка о подходе к переписке: https://t.me/another_sa/37
#конференция
В ближайшее воскресение расскажу на ЛАФ о терминологическом хаосе вокруг REST. Кратко об этом уже писал тут, теперь погрузимся в тему глубже. У кого будет желание - пишите, познакомимся😏
В ближайшее воскресение расскажу на ЛАФ о терминологическом хаосе вокруг REST. Кратко об этом уже писал тут, теперь погрузимся в тему глубже. У кого будет желание - пишите, познакомимся😏
#требования #мышление #анализ
Анна Абрамова рассказывает о том, как аналитику научиться видеть задачу целиком, и не продалбывать важные моменты.
https://www.artofba.com/post/how-to-see-whole-picture
Конспектировать не буду, ибо ее cnjbn прочитать и обдумать самостоятельно. Несколько тезисов, которые особо зацепили:
О ценности аналитика
По моему глубокому убеждению, задачей аналитика является видеть риски и явно описывать ограничения. Аналитик работает с огромным количеством информации на разных уровнях абстракции и видит пробелы и нестыковки, которые не могут увидеть другие.
Об инструментах анализа: UML, Use Cases, User Stories и т.п.
Для меня идеальный подход к проработке каждой задачи – использовать 2-3 инструмента, обязательно включающие текстовое и графическое представление информации. Это заставляет мозг работать в разных режимах и рассматривать разные аспекты, не теряя общей картины.
О выборе и валидации решения
Рассматривать несколько решений, в том числе решение, что ничего не нужно делать.
Об организации процесса работы
Мы пришли к выводу, что аналитику нужно минимум два часа в день «на подумать» без прерываний на вопросы от команды, переговоры и другие задачи.
Анна Абрамова рассказывает о том, как аналитику научиться видеть задачу целиком, и не продалбывать важные моменты.
https://www.artofba.com/post/how-to-see-whole-picture
Конспектировать не буду, ибо ее cnjbn прочитать и обдумать самостоятельно. Несколько тезисов, которые особо зацепили:
О ценности аналитика
По моему глубокому убеждению, задачей аналитика является видеть риски и явно описывать ограничения. Аналитик работает с огромным количеством информации на разных уровнях абстракции и видит пробелы и нестыковки, которые не могут увидеть другие.
Об инструментах анализа: UML, Use Cases, User Stories и т.п.
Для меня идеальный подход к проработке каждой задачи – использовать 2-3 инструмента, обязательно включающие текстовое и графическое представление информации. Это заставляет мозг работать в разных режимах и рассматривать разные аспекты, не теряя общей картины.
О выборе и валидации решения
Рассматривать несколько решений, в том числе решение, что ничего не нужно делать.
Об организации процесса работы
Мы пришли к выводу, что аналитику нужно минимум два часа в день «на подумать» без прерываний на вопросы от команды, переговоры и другие задачи.
ArtofBA
Как аналитику видеть задачу целиком ≡ Блог ArtofBA
Часто, принимая в работу новый проект команда видит описание какого-то программного решения, но не понимание решаемой задачи
#анализ
Среда 7 июля в 19:00
Люблю критику, ибо она часто помогает понять, как улучшить нашу работу. Вечером в среду Филипп поделится фидбеком, который мы сможем вместе обсудить, присоединяйтесь😏
Первую часть проведем в формате интервью, вторую - в режиме общей дискуссии.
https://compractice.timepad.ru/event/169456
Среда 7 июля в 19:00
Люблю критику, ибо она часто помогает понять, как улучшить нашу работу. Вечером в среду Филипп поделится фидбеком, который мы сможем вместе обсудить, присоединяйтесь😏
Первую часть проведем в формате интервью, вторую - в режиме общей дискуссии.
https://compractice.timepad.ru/event/169456
compractice.timepad.ru
Почему системный аналитик в компании - это bad smell? И что мы можем с этим сделать? / События на TimePad.ru
Почему системный аналитик в компании — это bad smell? И что мы можем с этим сделать?
Уже через час обсудим с Филиппом проблемы при работе с аналитиками, подключайтесь
https://us02web.zoom.us/j/89499320249
https://us02web.zoom.us/j/89499320249
#анализ #манагерское
Почему системный аналитик в компании - это bad smell?
https://youtu.be/__CS7ogpMks
Конспект писать не буду, но пару мыслей из обсуждения хочу вынести:
⁃ Системным аналитиком называем роль, которая занимается техническим дизайном (проектированием API, БД, UI, внутренней логики приложений), проработкой пользовательских требований (user story, пользовательские сценарии и т.п.) и выполняет кучу других функций, которые получится на него повесить.
⁃ Залезать в техдизайн СА не стоит, т.к. для этого нужны технические компетенции уровня разработчика с 5-10 годами опыта.
⁃ Работа с пользовательскими требованиями - это функции product owner/manager’а. Можно похоливарить на тему, почему относим эти функции продукту, но сейчас это распространенная трактовка.
⁃ При этом работа СА на интеграционных задачах вполне допустима, т.к. здесь аналитик выступает как архитектор решений на минималках, что не требует глубокого погружения в технику.
⁃ Если в разработки продукта есть выделенный СА, то это указывает на проблемы в процессах команды или компании. В частности, в коммуникациях между разработкой и бизнесом. При этом налаживать процессы может оказаться сложнее или дороже, чем привлечь СА.
⁃ По опыту Филиппа 2/3 разработчиков способны и готовы коммуницировать с бизнесом и погружаться в предметную область, если у них есть возможность.
В сухом остатке получается, что привлечение системных аналитиков вполне оправдано, если нет возможности менять процессы в команде и нанимать профессиональных разработчиков. Самим же аналитикам лучше фокусироваться на функциях архитектора или продукта - интересно, что схожие мысли последнее время озвучивали на конференциях Дмитрий Безуглый и Сергей Нужненко.
По итогам хочу еще поисследовать тему с другими представителями индустрии. Кому-нибудь еще интересен такой формат? Дайте знать в комментах, плз.
Почему системный аналитик в компании - это bad smell?
https://youtu.be/__CS7ogpMks
Конспект писать не буду, но пару мыслей из обсуждения хочу вынести:
⁃ Системным аналитиком называем роль, которая занимается техническим дизайном (проектированием API, БД, UI, внутренней логики приложений), проработкой пользовательских требований (user story, пользовательские сценарии и т.п.) и выполняет кучу других функций, которые получится на него повесить.
⁃ Залезать в техдизайн СА не стоит, т.к. для этого нужны технические компетенции уровня разработчика с 5-10 годами опыта.
⁃ Работа с пользовательскими требованиями - это функции product owner/manager’а. Можно похоливарить на тему, почему относим эти функции продукту, но сейчас это распространенная трактовка.
⁃ При этом работа СА на интеграционных задачах вполне допустима, т.к. здесь аналитик выступает как архитектор решений на минималках, что не требует глубокого погружения в технику.
⁃ Если в разработки продукта есть выделенный СА, то это указывает на проблемы в процессах команды или компании. В частности, в коммуникациях между разработкой и бизнесом. При этом налаживать процессы может оказаться сложнее или дороже, чем привлечь СА.
⁃ По опыту Филиппа 2/3 разработчиков способны и готовы коммуницировать с бизнесом и погружаться в предметную область, если у них есть возможность.
В сухом остатке получается, что привлечение системных аналитиков вполне оправдано, если нет возможности менять процессы в команде и нанимать профессиональных разработчиков. Самим же аналитикам лучше фокусироваться на функциях архитектора или продукта - интересно, что схожие мысли последнее время озвучивали на конференциях Дмитрий Безуглый и Сергей Нужненко.
По итогам хочу еще поисследовать тему с другими представителями индустрии. Кому-нибудь еще интересен такой формат? Дайте знать в комментах, плз.
YouTube
Почему системный аналитик в компании - это bad smell? И что мы можем с этим сделать?
Мы много раз слышали о том, зачем проекту или команде нужен системный аналитик. Однако, представители других IT-профессий не всегда разделяют это мнение. Андрей Бураков вместе с Филиппом Дельгядо говорили о том, какие проблемы возникают при работе с системными…