Я слышал о попытках коуча запрограммировать

Он же в контекст не погружается, а вопросы задает, шансы есть

если ии заменит менеджера или прогрммист этот вопрос будет бессмысленен

менеджеров, скраммастер бот уже вот есть для слака :)

чатботы тоже есть, только толку с них нет. пока

поля -- крестьянам, фабрики -- рабочим, таски -- программистам

таска как средство производства ?

как ты без тасков продукт выпустишь?

ну это справедливо и для крестьян и для рабочих

и и согласно лозунгу сейчас таски не принадлежат программистам ?

сейчас они принадлежат менеджерам

а менеджеры (верхи) уже не могут

ленин бы наверное сейчас очень стеснялся этой фразы

Если речь идет о таске, как сущности в трекере - то и без них продукт можно сделать

Кто из Уфы? Результаты: Я (11): Ольга Alexandr ape364 Bulatbulat48 vozzurg rinatbakiev Eugene_Seleznev Ilfat spoletskiy Ilya Z4PH0D Не я (166): JTProg alexeyilchenko Anton Zanimonets Nicola Alice 2.0 eaglealex netsuileo Ilya Andrey karinatsar anonovich Anastasiya andrey_chevozerov weareallbuddhas hellika denisenkoaj Pavel dphov Pushkinmazila levdanov Michael ditt0 Roman Irina granin netsend nikitinaann aksnes B2Bgroup rsscssr VladislavSeletov andreychev kirill1 HTML666 hulygun rmdm88 k1ber rhcsa vkuznetsov Valeree olebedev GEXmur Danila Ivan rimma_b Aleksei where_is_your_god_now medvden Belsandr CashmanWow Neyznayka spotykashka Дмитрий igorpavlov BeGetOn oayunin Николай liolia chekunkov RunGiantBoom levinside PureRage plotnikoff paul_anti djondon eddieburn ISidorov drew A_method Yegor blacktrub krokot84 nede1 ExileeD deluxoft Fonturacetamum zeroabe nmudrik TeKTuS bro0ke lailune Recouse star_orpheus Dmytro borisgern alexprokofev Kirillvs imuzykin Piroman99 Aladex ObiWanRoman Anufant yaroslavlevs Nikita mr_makko Chikiro mmpmax reggess NoManDestroyer luckyth1rteen Mikhail Rodbe Galina iamfuckingguy Nigmatiy wintwin AnnaDiz adam sergeilpanchenko quantum_robin bauer19 Aleksandr Evgeny_Sobko pics23 dmitriyabr artmilevskiy hrt4u nbayborodin haos_001 professorsda Dmitry Евгений MrLinch runon Iskakov stepus te_dasha Below ArsIQ HellPirate freenetwork Dmitry Anastasia Kintal Kirill_ln AndrewFa upppi bearpro opencn remezbird naudachu nnimnul Andrew shlyha_80lvl drGOD Alexey ThePanaceya drakmail Наталья (mnatikk) Dmitry hirama Johny_official semsem000 arhi9med Pavel Alvor iradvoretskaya grouse dmt_gudakov Alexandr jebcoat darenta mronitzuka foxrs Gleb

Ребят, привет всем

Здесь можно задавать вопросы по планированию, составлению тех. задания?

в принципе можно

возможно вот этот чатик сможет помочь

https://telegram.me/analyst_ru

возможно вот этот чатик сможет помочь

благодарю

Мой вопрос довольно пространственный. Клиент написал описание приложения. Каков порядок эффективной работы над тз? С чего начать — проектирование базы данных, продумывание UI/UX? Как сделать так, чтобы не переделывать 10 раз?

Тз пишу для себя. Для веб-приложения.

Либо рисовать схемы сначала с логикой?

приложение направлено на b2b или b2c?

приложение направлено на b2b или b2c?

b2b

суть такова — рекламодатели ищут водителей личных автомобилей для поклейки на них рекламы

Но суть — не главное. Я просто уже пытался спланировать прошлое приложение и с треском провалился.

Поэтому интересует, как именно подходить к задаче на этом этапе, когда до написания кода еще далеко

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

Также у меня есть крутейшая идея, которую я хочу реализовать. Но боюсь к ней даже подходить без умения нормально спланировать все до конца. Может я что-то не то пишу, поправьте, пожалуйста.

хорошие и правильные вопросы :)

форматы тз бывают разные. в вашем случае функциональные требования обычные, видимо не подойдут

так точно

Подозреваю, что нужны какие-то блок-схемы с ответвлениями (действиями пользователя) и побочными эффектами от этих действий.

пока предлагаю почитать вот это

https://medium.com/@beskov/%D0%BA%D0%B0%D0%BA-%D0%B2%D1%8B%D0%BF%D0%BE%D0%BB%D0%BD%D0%B8%D1%82%D1%8C-%D1%82%D0%B5%D1%81%D1%82%D0%BE%D0%B2%D0%BE%D0%B5-%D0%B7%D0%B0%D0%B4%D0%B0%D0%BD%D0%B8%D0%B5-%D0%BD%D0%B0-%D0%B2%D0%B0%D0%BA%D0%B0%D0%BD%D1%81%D0%B8%D1%8E-%D0%B8%D1%82-%D0%B0%D0%BD%D0%B0%D0%BB%D0%B8%D1%82%D0%B8%D0%BA%D0%B0-f3e3e59b0e03#.8qmnabtn8

а потом посмотреть сюда

https://docs.google.com/document/d/1YJXPHBJFfRPBhbzndSZtA6w55C0N8DXeWE-Nz0DEAPg/edit

например

думаю как минимум часть вопросов снимет. или даже появится понимание, как в вашем случае правильно поступить :)

Спасибо, смотрю.

У нас есть правило ui-first т.е сначала рисуем wireframe а потом меняем переделываем по ходу работы

"без умения нормально спланировать все до конца" это прямое противоречие тому, на чём базируется Agile

если можно обойтись без ТЗ — обходитесь без него

без чего обычно сложно обходиться — так это без списка объектов поставки

потому что всем нужен какой-то механизм контроля хода и приёмки

в Agile таким реестром часто выступает бэклог

причём он хорошо поддерживает исследовательский принцип «сначала вширь, потом — вглубь»

объектом поставки может быть экран интерфейса, но в моей практике это для многих проектов плохо кончается

Что можно сделать: 1. Накидать концепцию приложения в виде краткой карточки с ответами на ключевые вопросы или Product Canvas 2. Сделать простую сквозную модель процесса, автоматизируемого в приложении, если она есть 3. Накидать на неё функциональные возможности, например, в виде user story map

Это даст общий обзор

Дальше уже можно детализировать поведение и модели данных только тех историй, которые пойдут в работу первыми

если слова ТЗ, база данных и интерфейс встречаются вместе, значит вы путаете ТЗ на проектирование и ТЗ на разработку

Есть, грубо говоря, 3 уровня проектирования: 1. Концептуальное 2. Функционально-логическое 3. Техническое

Концептуальное проектирование — это ответ на вопрос «какую чью проблему решаем каким принципиально образом». Чем его оформлять просто и быстро — я написал выше в 1-2.

Функционально-логическое проектирование обычно ложится в ТЗ и функционально описывает только ВНЕШНЕЕ поведение, не учитывающее программную архитектуру.

В ГОСТ-овских подходах для технического проектирования есть пакет работ под названием «технический проект».

В Agile техническое проектирование принято делать уже в ходе разработки, непосредственно в итерации.

Вместо функционально-логического проектирования как написания документа SRS в agile есть BDD-сценарии и Agile Modeling

Заказчики часто ожидают от вас способности подробно спроектировать и спланировать приложение.

Но практика показывает, что человек без реальной проверки всех этих заложенных в проектную модель идей ошибается на 30-80%.

Т.е. работа пойдёт в мусор.

@beskov Спасибо за информацию, все понятно и доходчиво.

Scrum всё? Откуда такие мотивы? Почему сильные разработчики не принимают SCRUM? Нужны ли все эти абстракции или это излишняя когнитивная нагрузка? Может пора что-то переосмыслить и проявить гибкость к самим гибким методикам? > The longflow model is an engineering-centric workflow for serious software developers, tired of the "Agile"/"Scrum" bullshit. Что думаете про тезисы в манифесте? https://github.com/Nax/longflow-manifesto/blob/master/README.md

Да блин, ну те же мотивы, что у "Пиши код, блять" Устают от булшита, потому что хайп, а когда хайп — внедряют как поняли, а не как задумано и где нужно Если программист жалуется на микроменеджмент в скраме, значит он уж точно не в настоящей скрам команде работает... Таких манифестов дофига. Кстати сам манифест ни разу не аджайл,)

Там чел думает на уровне "таск", на уровне "таск" бывают только практики

> @DenisIzmaylov Что думаете про тезисы в манифесте? boring. Когда люди пишут "не делайте так", это обычно значит, что им нечего предложить по существу. Value quality over deadlines, don't fear running late - видимо, спонсоры безусловного дохода у проектов автора уже есть.

Ггг спонсоры безусловного дохода - very good

Пока мы все еще пытаемся скрам, западные коучи активно интересуются ТРИЗ :)

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

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

управления чем? :) и что такое "технологии управления"? :)

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

те, которые самые нужные :)

Контекстозависимые ;)

Пока мы все еще пытаемся скрам, западные коучи активно интересуются ТРИЗ :)

у нас тоже про ТРИЗ говорят, Артем Горбунов например, а что говорят наши зарубежные коллеги?

http://www.liberatingstructures.com/6-making-space-with-triz/ упражнени всякие вот практикуют применительно к триз

Мой любимый вопрос про управление: дирижёр чем управляет: оркестром, музыкой, собой ещё чем?

настроением

настроение управляет дирижёром)

Во-во. Вот пример подхода. Есть реальность, она одна. Ходят люди, чего-то делают, что-то получается, кто-то что-то кому-то платит. А у управленцев тысяча подходов: кто проектом управляет, кто персоналом, кто собой, кто настроением. Один про технологии говорит приминительно к персоналу, другой - к проекту. И с вайном друг с другом спорят кто правильнее управляет. При этом реальность одна.