Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 39
Кого еще харит скрам-хайп, ставим плюсик. :)
А по русски? А то я понял только часть после запятой =)
харит — harrasment — домогательство
Вот и меня удивил этот комментарий, ибо гугл меня вывел куда-то…
Мне кажется «скрам-хайп» был актуален лет 5 назад, как раз тогда мы на него и перешли. С тем, что он с тех пор набил оскомину соглашусь, но все таки методологий управления разработкой не так уж и много, повторения неизбежны.
А фишка в том, что взять методологию — это половина дела, надо еще адаптировать ее под себя. И я как раз scrum не пиарю, он в этом не нуждается, а просто делюсь наблюдениями за эти 5 лет.
А фишка в том, что взять методологию — это половина дела, надо еще адаптировать ее под себя. И я как раз scrum не пиарю, он в этом не нуждается, а просто делюсь наблюдениями за эти 5 лет.
Как Вы круто всю концепцию ребят из «Гильдии проектировщиков» в один миф запихнули. Не обидятся ли они?
У заказчика/стейкхолдера может быть свое видение продукта, у владельца продукта другое, у вас третье.
А еще есть тестировщики, дизайнеры и аналитики, не говоря уже о пользователях. И всем надо проводить демо и как можно чаще. Не боитесь ли Вы перегнуть палку с количеством времени, которое тратится на взаимодействие?
Тестировщики и аналитики по-хорошему это участники процесса проектирования, демо для них не нужно.
Если говорить про остальных «заинтересованных лиц», то в любом случае придется потратить время на взаимодействие. Либо в виде демо, либо в виде постоянных ответов на их вопросы, потому что сами они могут неправильно понять что вы делаете и зачем.
Если говорить про остальных «заинтересованных лиц», то в любом случае придется потратить время на взаимодействие. Либо в виде демо, либо в виде постоянных ответов на их вопросы, потому что сами они могут неправильно понять что вы делаете и зачем.
Все они (тестировщики, дизайнеры, аналитики) должны участвовать в процессе проектирования продукта и демо для них не должно быть первой встречей с продуктом.
Не нужно проводить весь спринт в обсуждении видения продукта, но нужно понимать, что без должного взаимодействия не выйдет ничего хорошего.
Не нужно проводить весь спринт в обсуждении видения продукта, но нужно понимать, что без должного взаимодействия не выйдет ничего хорошего.
Когда вы что-то обсудили с заказчиком, не записали, забыли, а потом он спрашивает, что вы придумали по его вопросу – то это повод поменять две вещи: тему разговора и свой подход к документированию.
Забрал цитату в копилку :)
А по делу, можете более четко прояснить, что вы понимаете под проектированием? Конкретно. Потому что иногда возникает ощущение, что вы говорите «проектирование», а имеете в виду «планирование», а иногда и еще чего похлеще.
Владелец продукта ставит перед командой задачу: что и зачем нужно сделать, на уровне его видения. Дальше проектируем: разбираемся как будем делать, потом декомпозируем на мелкие части и оцениваем.
Похоже на планирование, но:
Похоже на планирование, но:
- задачи бывают сложные, за один день планирования спринта успеть физически невозможно.
- часто до того, как начать делать нужно получить одобрение владельца продукта и заказчика/стейкхолдера
- видение владельца продукта бывает поверхностным, требуется исследование предметной области, конкурентов, кейсов работы пользователей
Не могли бы Вы сказать какие проекты и в каких предметных областях вы реализовали по такой методологии?
Как вы «встраиваете» работу с аналитиком в свою реализацию Scrum?
Куда относится работа по «требуется исследование предметной области, конкурентов, кейсов работы пользователей»? в какую итерацию они помещаются или делаются вне итераций?
Почему работа по «исследование… конкурентов» относится к самому циклу разработки продукта/решения?
И как так получилось что «программисты пишут бумажки» и какие? да еще и «на выброс»?
Сколько у вас примерно «стоит» проектирование, «Показывать заказчику работающие прототипы» и получать отзывы, разработка, тестирование и развертывание? в среднем для 1...5 спринтов по времени. 10% этап Х, 15% этап Y и т.д.
Как новый участник проекта получает необходимие знания по проекту? Куда деваются знания проекта ушедшего человека?
Если вы работаете в незнакомых и сложных предметных областях — возьмите в команду аналитика, подружитесь с ним – он не кусается.
Как вы «встраиваете» работу с аналитиком в свою реализацию Scrum?
Куда относится работа по «требуется исследование предметной области, конкурентов, кейсов работы пользователей»? в какую итерацию они помещаются или делаются вне итераций?
Почему работа по «исследование… конкурентов» относится к самому циклу разработки продукта/решения?
И как так получилось что «программисты пишут бумажки» и какие? да еще и «на выброс»?
Сколько у вас примерно «стоит» проектирование, «Показывать заказчику работающие прототипы» и получать отзывы, разработка, тестирование и развертывание? в среднем для 1...5 спринтов по времени. 10% этап Х, 15% этап Y и т.д.
Как новый участник проекта получает необходимие знания по проекту? Куда деваются знания проекта ушедшего человека?
Не могли бы Вы сказать какие проекты и в каких предметных областях вы реализовали по такой методологии?
Конкретные проекты назвать не могу, предметная область — ЕСМ и все что вокруг ЕСМ.
Как вы «встраиваете» работу с аналитиком в свою реализацию Scrum?
Аналитик физически в команде, активно участвует в исследовании, проектировании, тестирует, занимается документацией и справкой. Задач по ходу спринта хватает для 100% загрузки.
Куда относится работа по «требуется исследование предметной области, конкурентов, кейсов работы пользователей»
Все в рамках проектирования в итерации. Если это будет отдельно, а потом отдельно проектирование, а потом отдельно реализация это уже не совсем Scrum :-)
Почему работа по «исследование… конкурентов» относится к самому циклу разработки продукта/решения?
Потому что это нужно для проектирования, чтобы понять полную картину. Конечно можно исследования проводить заранее, но на практике они устаревают и забываются к началу итерации, поэтому делаем все вместе.
И как так получилось что «программисты пишут бумажки» и какие? да еще и «на выброс»?
Мы сейчас на выброс ничего не пишем, я собственно об этом и писал. Документируем необходимый минимум, в основном в виде мокапов.
А вообще «программисты пишут бумажки» это распространенная практика, особенно когда заказчик требует тщательно описать все в ТЗ, правда потом его сам не всегда читает.
Сколько у вас примерно «стоит» проектирование?
Посмотрел по прошлому релизу: проектирование + разработка, тестирование и поддержка реализованного (баги, развертывание, продуктивы и т.д.) занимают одинаковое время.
Как новый участник проекта получает необходимие знания по проекту?
Обучение внутри команды + самостоятельно по справке к продукту, парное программирование, своя wiki по архитектуре и приемам разработки, привлечение к проектированию и планированию.
Обычно этого достаточно, чтобы освоиться за пару месяцев.
Аналитик физически в команде, активно участвует в исследовании, проектировании, тестирует, занимается документацией и справкой.
Предположим, освоение нормативного документа и предметной области занимает 3 месяца времени.
Т.е вся команда что бы понять что важно а что нет для проектирования, все 10 человек будут сидеть и читать эту предметную область?
А если изучение предметной области занимает месяцев 3..9? тогда как вписывается в итерации?
Документируем необходимый минимум, в основном в виде мокапов.
Необходимый минимум для кого? Команды или Клиента?
А вообще «программисты пишут бумажки» это распространенная практика, особенно когда заказчик требует тщательно описать все в ТЗ, правда потом его сам не всегда читает.
Наверное, вы знаете что такие «бумажки» пишут как раз не программисты, а архитекторы и аналитики.
Это Presale документация? или уровень функциональной спецификации?
Как этот процес работает с контрактами Time & Material и Fixed Price?
А если изучение предметной области занимает месяцев 3..9?
У нас с этим попроще, но попробую предложить решения:
- Исследовать по кусочкам, если это возможно. Сначала разбить по-крупному, а дальше в каждый спринт брать по одной теме для глубокой проработки и реализации. Повторюсь, если такое возможно в конкретной предметной области
- Увеличить количество аналитиков/развивать компетенции аналитиков у других участников команды. Например, у тестировщиков.
А если не секрет какая предметная область требует изучения нормативной документации по 9 месяцев?
Необходимый минимум для кого?
В нашем случае (продуктовая разработка) получается для команды и заинтересованных лиц. Но и на практике внедрений и внешних проектов заказчики (не все конечно) готовы идти на компромиссы и отказываться от жесткого ТЗ.
«бумажки» пишут как раз не программисты
Где как, но чаще архитекторы и аналитики, вы правы. Я имел ввиду именно проектную документацию (ТЗ, спецификации).
Как этот процес работает с контрактами Time & Material и Fixed Price?
Сильно зависит от заказчика, но может работать. Коллега из отдела внедрения недавно писал статью по опыту недавних внедрений как раз по fixed price и time&material.
В нашем случае (продуктовая разработка)
С этого «нюанса» и надо было начинать :)
нормативной документации по 9 месяцев?
да практически любая из гос кодексов с обвязкой в виде постановлений, инструкций. из межгосударственный вещей с кучей перекрестной документации, специфическая: банковская, налоговая, финансовая, картографическая, медицина.
. Я имел ввиду именно проектную документацию (ТЗ, спецификации).
Проектную «спецификацию и ТЗ» — это работа аналитиков, после контракт. там пофиг итерации и показы. Клиент просто скажет: А покажи мне Отчет Х из твоей системы? сошлось с моим? молодец!.. нет? иди фикси дальше, чего людей отвлекаешь?
Хорошая статья. Сняли с языка некоторые мысли)
Прочитал статью. С моей точки зрения, статья представляет набор банальностей. Это первый минус. Второй минус — то, что советы выливаются в благие пожелания, не предоставляющие какие-либо инструментальные решения.
Что я имею в виду?
Например, автор замечает, что программисты любят писать код и не любят описывать технический дизайн системы. Автор пытался разобраться, почему так происходит? Явление одно, а причины у него могут быть разные.
Первый вариант — некоторые программисты не знают английского языка, а заказчик — иностранец, и требует документацию на английском языке.
Другой вариант — это шаблон документа содержит много разных разделов, которые не нужны, фактически переписываются из документа в документ, и программисту не хочется тратить на это время. Что это за разделы? Как удалось обойтись без них? Какой шаблон документа был изначально и какой шаблон предлагает автор? На эти вопросы нет ответов.
Третий вариант — это огромный набор задач, часто спутанных между собой, на которые нужно найти решения. При чем решение одной задачи может порождать другие задачи, которые, в свою очередь, тоже требуют решения. Часто одни решения плохо согласуются с другими решениями. И программист просто теряется в этом клубке задач. Наступает ситуация, которую в профессиональной литературе называют «паралич от анализа». Что предлагает автор, чтобы устранить подобную проблему и помочь программисту справиться с объемом навалившихся задач? Да, фактически, ничего: нанять аналитика (который справится с этой проблемой, а то, что перед аналитиком может встать точно та же проблема — об этом даже не думается) и проектировать быстро.
И так вся статья.
Что я имею в виду?
Например, автор замечает, что программисты любят писать код и не любят описывать технический дизайн системы. Автор пытался разобраться, почему так происходит? Явление одно, а причины у него могут быть разные.
Первый вариант — некоторые программисты не знают английского языка, а заказчик — иностранец, и требует документацию на английском языке.
Другой вариант — это шаблон документа содержит много разных разделов, которые не нужны, фактически переписываются из документа в документ, и программисту не хочется тратить на это время. Что это за разделы? Как удалось обойтись без них? Какой шаблон документа был изначально и какой шаблон предлагает автор? На эти вопросы нет ответов.
Третий вариант — это огромный набор задач, часто спутанных между собой, на которые нужно найти решения. При чем решение одной задачи может порождать другие задачи, которые, в свою очередь, тоже требуют решения. Часто одни решения плохо согласуются с другими решениями. И программист просто теряется в этом клубке задач. Наступает ситуация, которую в профессиональной литературе называют «паралич от анализа». Что предлагает автор, чтобы устранить подобную проблему и помочь программисту справиться с объемом навалившихся задач? Да, фактически, ничего: нанять аналитика (который справится с этой проблемой, а то, что перед аналитиком может встать точно та же проблема — об этом даже не думается) и проектировать быстро.
И так вся статья.
Я думаю, что программисты, в первую очередь, не любят описывать технический дизайн системы не потому, что не могут его спроектировать, а именно потому, что его надо «описать». А значит надо подобрать слова, использовать правильные термины, четко и кратко сформулировать мысли. Знаю разработчиков, для которых написать программу и показать ее работу гораздо легче, чем объяснить как она работает на пальцах «не программисту». Согласитесь, не всем дано красиво выражать свои мысли, для многих это сложная и неприятная задача.
По поводу поиска решений для большого количества задач:
Если я правильно понимаю автора статьи, идея как раз в том, что проектированием занимается не один выделенный человек, а практически вся команда. В таком случае, даже если у кого-то возникает «паралич от анализа», то остальная команда продолжает генерировать идеи и решения. При чем команда состоит не только из разработчиков, а значит может подойти к решению проблемы с разных сторон.
Можно провести аналогию с подбором команды в «Что? Где? Когда?»: чем сильнее отличаются по опыту, образованию и увлечениям члены команды, тем больше шансов, что при ответе на вопрос, хоть кто-нибудь будет понимать о чем речь, знаком с темой или знать «тонкости» области вопроса.
По поводу поиска решений для большого количества задач:
Если я правильно понимаю автора статьи, идея как раз в том, что проектированием занимается не один выделенный человек, а практически вся команда. В таком случае, даже если у кого-то возникает «паралич от анализа», то остальная команда продолжает генерировать идеи и решения. При чем команда состоит не только из разработчиков, а значит может подойти к решению проблемы с разных сторон.
Можно провести аналогию с подбором команды в «Что? Где? Когда?»: чем сильнее отличаются по опыту, образованию и увлечениям члены команды, тем больше шансов, что при ответе на вопрос, хоть кто-нибудь будет понимать о чем речь, знаком с темой или знать «тонкости» области вопроса.
Я думаю, что программисты, в первую очередь, не любят описывать технический дизайн системы не потому, что не могут его спроектировать, а именно потому, что его надо «описать».
Умение писать техническую документацию входит в квалификационные требования к инженеру. Вряд ли кому из программистов не приходилось писать пояснительную записку к дипломной работе. Также в институте было много и курсовых, и лабораторных работ.
А значит надо подобрать слова, использовать правильные термины, четко и кратко сформулировать мысли.
Это действительно задача. Мне было бы интересно узнать, какие решения предлагает автор статьи. В свою очередь, я бы мог предложить использовать шаблоны документов. Также у нас не требуется писать длинный текст. Используем диаграммы и пару-тройку конкретных фраз, описывающих идею решения. Если мы пишем техническую документацию, то только для инженера, который будет все это реализовывать. Как правило, это один и тот же человек. Нет необходимости соблюдать излишние формальности и писать общие фразы.
Если я правильно понимаю автора статьи, идея как раз в том, что проектированием занимается не один выделенный человек, а практически вся команда. В таком случае, даже если у кого-то возникает «паралич от анализа», то остальная команда продолжает генерировать идеи и решения.
На мой взгляд, это не поможет, т.к. «паралич от анализа» появляется не из-за малого количества людей, работающих над задачей, а из-за наличия множества (порой, мелких) взаимосвязанных задач, и решение каждой из этих задач приводит к возникновению новых задач, которые могут перечеркнуть намеченные решения предыдущих задач.
Насчет технической документации.
Да, у нас есть шаблон, так и называется «Шаблон тех. проекта». А еще есть чеклисты по инициации проектирования, организации обсуждений, исследованию. Это все не строго обязательно, просто упрощает документирование.
У нас документ «по-крупному» должен содержать 4 раздела:
При этом документы получаются короткими, воду лить не нужно. Описать решение тому, кто его придумал обычно не сложно, плюсы и минусы тоже. В документ пишут все участники команды. Проектная документация на спринт команды из 6 человек — 5-6 страниц (с картинками).
Да, у нас есть шаблон, так и называется «Шаблон тех. проекта». А еще есть чеклисты по инициации проектирования, организации обсуждений, исследованию. Это все не строго обязательно, просто упрощает документирование.
У нас документ «по-крупному» должен содержать 4 раздела:
- В разделе «Открытые вопросы» зафиксированы текущие вопросы, которые необходимо обсудить на ближайшем совещании, либо вопросы, на которые нужно ответить к ближайшему обсуждению.
- Раздел «Решения» состоит из текущих прорабатываемых вариантов решений, итоговой оценки трудоемкости, мокапов, скриншотов прототипов. Для предлагаемых вариантов выделяются плюсы и минусы в виде таблицы.
- В раздел «Приложения» переносятся:
- закрытые вопросы;
- результаты исследований;
- ссылки на связанные документы;
- прочая вспомогательная информация.
- При согласовании документа с заказчиком, рекомендуется выделять вверху документа раздел «Аннотации» с кратким содержанием и выводами.
При этом документы получаются короткими, воду лить не нужно. Описать решение тому, кто его придумал обычно не сложно, плюсы и минусы тоже. В документ пишут все участники команды. Проектная документация на спринт команды из 6 человек — 5-6 страниц (с картинками).
У нас документ «по-крупному» должен содержать 4 раздела:
Это фактически у вас работа с рисками: идентификация и анализ/оценка рисков.
Это внутренний документ для управления проектом :) это не техническая документация :))
Ваш ревью спринта, если верно понял, будет привязан к этой «табличке»?
так и называется «Шаблон тех. проекта»
Обычно, это часть PreSale, это тоже не тех документация проекта, и обычно идет в свободной форме что бы " не морщить мозг". По идее этот документ сопровождается бюджетом проекта/решения?
По поводу «аналитического паралича».
Из личного опыта я усвоил, что командная работа от него спасает не всегда. «Закапываться» и «залипать» впятером можно так же, как и одному.
На мой взгляд решение стоит искать в других подходах (предупреждаю, они не всем подойдут):
Из личного опыта я усвоил, что командная работа от него спасает не всегда. «Закапываться» и «залипать» впятером можно так же, как и одному.
На мой взгляд решение стоит искать в других подходах (предупреждаю, они не всем подойдут):
- Не пытаться придумать заранее детальное решение всех проблем. Сделать схему по-крупному с зависимостями, а дальше двигаться: каждый спринт брать кусочек, проектировать и сразу делать. Если при этом возникнут проблемы с уже сделанным — дорабатывать старое или даже переделывать (переделки очень тонкий момент, обсудите с заказчиком заранее). Со временем ваше понимание и знания увеличиваются и вы находите решения, которые не нашли бы находясь в «аналитическом параличе».
- Урезать функциональность. Бывает просят кучу вещей, которые друг другу противоречат. Тогда помогает сначала понять, что действительно важно, донести это до заказчика/стейкхолдера и выкинуть лишнее. Так вы уменьшите количество связанных задач и распутать «клубок» будет легче.
- Проектировать от кейсов пользователей. Обычно кейсы реальной жизни противоречат друг другу реже, чем написанные кем-то «требования».
- Периодически оценивать трудоемкость фич. Наверняка у вас есть максимальная цена в совокупности для всего проекта. Чаще всего нет смысла проектировать фичи, которые вы не будете делать. Если вы оцените весь «клубок» и выясните, что у вас превышение бюджета в два раза переходите к пункту «урезать функциональность».
- Чаще обсуждать проблему. Я имею ввиду не только обсуждения в команде, но и с владельцем продукта, заказчиком. Совет спорный, все таки это затраты времени, но проверено на себе: в случае «паралича» это встряхивает проектировщиков и некоторые проблемы решаются сами собой.
Предположу, что поскольку
Долгая работа в одной предметной области и уже есть какие «шаблонные» решения :)
Все типовые риски и проблемы уже устранены в этих «шаблонных» решениях и давно :)
И это далеко не заслуга Scrum. После, не означает в следствии.
Мы начали внедрять Scrum с 2011 года.
…
релизный цикл у нас состоит из 6 спринтов разработки
…
длительность итерации – 12 рабочих дней.
…
предметная область — ЕСМ и все что вокруг ЕСМ.
Долгая работа в одной предметной области и уже есть какие «шаблонные» решения :)
Все типовые риски и проблемы уже устранены в этих «шаблонных» решениях и давно :)
И это далеко не заслуга Scrum. После, не означает в следствии.
Вы правы, со временем так или иначе начинаешь работать эффективнее и процессы становятся отлаженными.
Почему я упомянул Scrum?
Потому что он в моем случае подталкивал к таким решениям. Командная работа подталкивает к командному проектированию. Итерационная разработка заставляет искать способы ускорения процесса. Ретро это отличный способ работы над улучшениями — вопросы проектирования на ретро поднимаются чаще всех остальных, даже сейчас.
Почему я упомянул Scrum?
Потому что он в моем случае подталкивал к таким решениям. Командная работа подталкивает к командному проектированию. Итерационная разработка заставляет искать способы ускорения процесса. Ретро это отличный способ работы над улучшениями — вопросы проектирования на ретро поднимаются чаще всех остальных, даже сейчас.
Уже ответили про документирование, примерно того же мнения придерживаюсь и я.
Вы подняли интересную тему «analysis paralysis». Я с ней сталкивался сам, пытался решить разными способами и Вы совершенно правы: нанять аналитика это не решение, он впадет в такой паралич часто быстрее разработчика. Проблема сложная и возможно заслуживает отдельного анализа и статьи. Может быть поделитесь другими сложностями, решение которых лично Вам было бы интересно?
Вы подняли интересную тему «analysis paralysis». Я с ней сталкивался сам, пытался решить разными способами и Вы совершенно правы: нанять аналитика это не решение, он впадет в такой паралич часто быстрее разработчика. Проблема сложная и возможно заслуживает отдельного анализа и статьи. Может быть поделитесь другими сложностями, решение которых лично Вам было бы интересно?
Может быть поделитесь другими сложностями, решение которых лично Вам было бы интересно?
В качестве ещё одной сложности можно взять миф 2 из Вашей статьи — это опытный проектировщик, который является «бутылочным горлышком», и вся команда фактически вынуждена ждать, пока он не разработает решение.
Вы, конечно, пишите, что в выработке технического решения должна принимать участие вся команда. Но что делать, если остальные не тянут? Например, могут сделать работу по заранее известному шаблону, но не могут справиться с клубком задач (помните, про «паралич от анализа»?) и выработать приемлемые решения.
Что Вы делаете, чтобы занять проектированием всю команду? Как выстраиваете работу команды с опытным проектировщиком? Как неопытные сотрудники обучаются? Тут тоже целый клубок задач.
Ваши вопросы относятся к теме развития людей и команды, это большая и важная тема. Может быть напишу и по ней статью.
Кратко по тому, как работаем мы: команды периодически перетасовываем по чуть-чуть, но стараемся сделать так, чтобы в каждой команде всегда был опытный проектировщик, в идеале — два. Проектирование всегда парное, если есть только один сильный проектировщик — он проектирует парно с кем-то из способных новичков, обычно за несколько месяцев тот прокачивается до хорошего уровня.
Пара проектировщиков и аналитик начинают проектирование как можно раньше, команда в это время занимается понятными задачами, техдолгом, поддержкой продуктива. По мере понимания задачи команда подключается к прототипированию, проработке конкретных деталей.
Кратко по тому, как работаем мы: команды периодически перетасовываем по чуть-чуть, но стараемся сделать так, чтобы в каждой команде всегда был опытный проектировщик, в идеале — два. Проектирование всегда парное, если есть только один сильный проектировщик — он проектирует парно с кем-то из способных новичков, обычно за несколько месяцев тот прокачивается до хорошего уровня.
Пара проектировщиков и аналитик начинают проектирование как можно раньше, команда в это время занимается понятными задачами, техдолгом, поддержкой продуктива. По мере понимания задачи команда подключается к прототипированию, проработке конкретных деталей.
программисты любят писать код и не любят описывать технический дизайн системыЯ даже слов то таких страшных не знаю, как техдизайн. Судя по дальнейшему описанию вариантов, у вас какой то свой кейс, но я его так и не понял.
Третий вариант вроде частично понятен — но тут как раз спасает скрам команда, в которой всегда найдется или более опытный (или достаточно опытный) коллега, с которым можно обсудить проблему и прийти к её решению.
ПС: я может совсем промахнулся и не понял о чём речь, можете игнорить меня =)
Я даже слов то таких страшных не знаю, как техдизайн.
К сожалению, в России и на просторах СНГ это сильно зависит от компании, в которой работаешь, и от проектов, над которыми работаешь. Опытный флэшер может сделать пару-тройку мини-игр за месяц. С другой стороны, некоторые игровые AAA-тайтлы выпускаются командами из 200 человек за полтора-два года.
На всякий случай, я пишу не о мини-проектах, каждый из которых можно сделать за одну-две человеко-недели, а о более крупных проектах, для которых требуется 2-3 человеко-года.
Хотя и для разработки небольшого проекта требуется продуманный технический дизайн. Как правило, это скелет программы, который слабо меняется от приложения к приложению. Тот же флэшер, клепающий мини-игры пачками, от игры к игре использует наработанную кода-базу.
тут как раз спасает скрам команда, в которой всегда найдется или более опытный (или достаточно опытный) коллега
Вы предлагаете не решение задачи, а возможность переложить его на плечи более опытного коллеги. А если такого коллеги нет? Или решение целого клубка задач требуют именно от Вас?
Если я неправильно вырываю мысли из ваших текстов, говорите сразу, каждый по своему мыслит же.
Сложные вопросы (не обязательно технически, но и логически, оно часто связано, хоть и не всегда) — проектирование, простые — на реализации.
скелет программы, который слабо меняется от приложения к приложениюВот это в принципе не существует, на мой взгляд. Есть фреймворки, которые позволяют однотипную работу на них сгрузить, но чтобы прям скелет? Это уже какой то движок готовый, к которому только цвет кнопочек под заказчика менять.
Вы предлагаете не решение задачи, а возможность переложить его на плечи более опытного коллеги. А если такого коллеги нет? Или решение целого клубка задач требуют именно от Вас?Ну если вопрос целиком на мне — я его и решу. Вопрос всегда решаем, но обычно далеко не всех устраивает цена, после чего нужно накидать разные варианты цена\качество, а накидать их как раз надо на проектировании… возвращаемся к топику.
Сложные вопросы (не обязательно технически, но и логически, оно часто связано, хоть и не всегда) — проектирование, простые — на реализации.
Перенес комментарий
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Мифы и заблуждения о проектировании в Scrum