Комментарии 13
Возможно не внимательно читал, либо из виду упустил — подскажите сколько человек было в команде ?
Не заострять внимание на качестве кода и дизайна — это пилить сук, на котором сидишь.
Хороший код, архитектура и дизайн нужны как раз для того, чтоб в будущем изменения было легко вносить, и темп "спринт — 2 недели" можно было поддерживать бесконечно долго.
Весь смысл в том, что проект — чаще всего не спринт, а марафон.
А так да, есть много полезной информации.
Не заострять внимание на качестве кода и дизайна
Тут речь про приоритет, важнее дать рабочий продукт, которым начнут пользоваться завтра, чем отсрочить релиз из-за чуть-чуть кривой архитектуры (или некрасивых имён переменных)
Поэтому все верно
Чаще всего архитектура обсуждается всей командой на груминге, и с учётом этого даётся оценка сложности юзер стори
Нет выделенного "архитектора", который не кодит
Во время груминга команда понимает как будет сделана, но никто не запрещает менять планы, если нашлось лучшее решение
Краткое содержание: В долгосрочной перспективе trade off между качеством кода и рабочим продуктом невозможен. Этот как взять кредит — можно заплатить немного сейчас, или заплатить много позже.
Архитектура в софте — это то, что сложно или дорого изменить, а потому (в проекте нацеленном на долгосрочную перспективу) лучше таки отсрочить релиз. ИМО, подтвержденное мучительной болью долгосрочных проектов.
Самое интересное, что я понимаю и одного и другого. Не заострять внимание на качестве кода, тут имеется в виду не слишком детально и полно дописывать прямо код, как в конечном продукте. Но то что подразумевается под термином "архитектура" тоже важно. Это писать код так, чтобы было понятно как его, потом быстро изменить, он должен напоминать структурированную систему блоков, которые можно быстро менять местами, частично заменять, перестраивать и дополнять, это универсальное слово — слабая связанность (loosely coupled).
То есть слабая связанность и неидеальный и как бы незаконченный код, практически на чем строится первый MVP или релизные фичи так что оба правы.
И статья очень толковая, я немного бегло прочитал, но суть скрама там прям полностью поймана и разложена по полочкам. А самое главное, что ребята достигли результатов, а заказчик получил продукт.
))) Вот чем надо хвастаться, а не "я тимлид, и нас большая и дружная команда, мы оторвали ковш от экскаватора (взяли что то из скрама), и уже делаем непонятно что вот уже несколько лет".
Работать по чистому скраму вполне себе приятно. К сожалению, мне чаще попадаются проекты, где думают, что поняли скрам и пытаются «улучшать» процессы. Получается от «не очень» до «крайне паршиво», потому что и поняли неправильно и поменяли криво.
На деле дать точную оценку неточных требований нереально. Типичный путь в проектном менеджменте — составить подробнейшее ТЗ перед началом разработки. А затем реализовать весь функционал одним большим куском. Но такой «вотерфольный» подход грозит уже другими рисками: запуском проекта в стиле «большого взрыва» — когда ты получаешь первый результат в самом конце проекта. И он может оказаться очень далек от реальных бизнес целей и нужд пользователей.А что мешает проектному менеджменту на начальном этапе предложить заказчику реализовать самый минимальный функционал используя как вы говорите «вотерфольный» подход и потом так же последовательно и тоже «вотерфольно» добавлять новые фичи? Вы же сами пишете что по SCRUM:
Заказчику трудно — он НЕ может подготовить стратегический план развития проекта с достоверными датами релизов. Неизвестность пугает, особенно когда нужно оплачивать этот путь уже сейчас.Что мешает исполнителям составить и просчитать ТЗ не на весь проект, а на небольшой его кусок и
«подписаться кровью» за результат в назначенный срок за фиксированные деньгии делать так на каждом этапе — чем это хуже SCRUM? Или вы думаете что это не понравится заказчику?
Самое интересное, контекст будет каждый раз теряться и всякий участник этого каскада будут вникать снова и снова
в скраме же есть только одна команда, им всем один раз всё объясняют, просят подписаться кровью всей команды за оценку сложности и остается только ждать демо)
обычно это укладывается за 2 недели)
Суть не в том, чтоб начать оценивать стори в сторипойнтах вместо часов, а в том, что б при оценке стори мы отталкивались от некого бейзлайна.
Пример: вот была у нас стори, мы решили что она 1, а эта вот выглядит побольше, но меньше той, что была 3, значит оцениваемая сторя где-то 2
Т.е. чтоб мы перестали оценивать в часах (потому что такие оценки все равно неправда, и пальцем в небо, а также создают ненужную эмоциональную привязку «я ж пообещал к среде..») а сравнивали стори с неким эталоном.
А соотношение сколько «строипойнтов в спринт» — вычисляется эмпирически и позволяет посчитать некую вилку между предполагаемым минимальным количеством сторипойнтов и максимальным.
Вот тут можно почитать подробнее medium.com/@mdalmijn/12-common-mistakes-made-when-using-story-points-f0bb9212d2f7
Как некое пособие по скрам гайду из жизненного опыта, теория размазана по всей статье и по каждому пункту есть объяснение
Мне кажется, эту статью стоит давать новичкам в скраме, чтобы увидели как работает на практике хороший скрам)
и да, выделенный, а тем более сертифицированный скрам мастер — огромный плюс)
Как мы делали SCRUM