Pull to refresh
3
0
Сергей Сова @ssova

Java developer

Send message

У меня сформировалось обратное мнение об Иннополисе. Большинство приезжих — какраз молодые семьи. Тут хороший садик, спорткомплекс, многие дружат семьями, ходят в гости. Очень много детей. Кафе есть в технопарке, университете, спорткомплексе, в ЖК есть бар, ресторан, сейчас ещё кольянная появилась

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

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

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

Спасибо за полезный комментарий! Уже было совсем запутался в этой статье, но вы меня спасли)

Несколько месяцев активной разработки, тестирования и доработок – бета-версия готова.

Оперативно, молодцы!

Не корректно

Можно и не заниматься спринтостроением, только не нужно называть это скрамом

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

этож аджайл, куда повернешь туда и поплывет

Как раз об этом моя статья. Нельзя бездумно перекраивать Agile процесс!


Прочитав ваш комментарий, я представил себе такую картину: сидят члены сообщества Agile за очередной чашечкой кофе и один из них: "А давайте больше не будем считать часы и фокус фактор, а будем считать story points и velocity..." и остальные ему: "Давай, давай, давай".


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

Продуктовые цели:


  • Повысить конверсию на 5%;
  • Вывести продукт на рынок B2C.

Такая цель может висеть несколько спринтов подряд, до тех пор пока не будет достигнута.


Техническая цель:


  • Делать ровно столько, сколько нужно для готовности спринтовой фичи, не закладываясь на будущее;
  • Завершить спринт без хвостов.

Техническими целями лучше не злоупотреблять. Ставить их нужно только для командного решения наболевших проблем

> У каждого члена может быть своя цель

Может, но это уже не скрам
> Но разные люди могут работать над разными участками. Кто-то пишет АПИ, кто-то его использует. Как это можно обойти?

Если взять 3 недельный спринт, то можно успеть написать API и клиента в одном спринте.
Вы правы. Скрам хорошо работает только в продуктовой и инхаус разработке. В других случаях лучше канбан или что-нибуть из каскадо-водопада
Впрочем для Agile тоже не принципиально важно взаимодействие программистов со стэкхолдерами, оно может происходить опосредовано, через Product Owner'а.

Прошу прощения за разговор самого с собой. Уважаемые модераторы, обьедините, пожалуйста, три моих комментария в один.
Полная изоляция программистов от стэкхолдеров (именно программистов, а не разработчиков) возможна только в классическом каскадо-водопаде. И да, для программистов в этом есть определенный плюс.
В Agile, Product Owner выполняет бизнес анализ и является ответственным лицом за коммуникацию со стэкхолдерами. Таким образом, он значительно снижает нагрузку на команду связанную со взаимодействием. Но, у команды остается возможность самой взаимодействовать со стэкхолдерами для проведения системного анализа, проектирования пользовательского интерфейса и архитектуры системы.
Другая компания скорее послужила доп. стимулом и образцовым примером. Наша компания не стала брать каскадо-водопад в чистом виде, а адаптировала его под себя
Я не упомянул в статье один важный момент, наши аналитики проводили не только бизнес-анализ, но также забрали на себя проектирование пользовательского интерфейса и предметной области.

Если ваш аналитик выполняет только бизнес-анализ, то он возможно выполняет роль Product Owner и тогда всё хорошо — это чистый Agile.

Если ваши аналитики проводят системный анализ, то если разработчики с аналитиками образуют единую команду и единое информационное пространство (все концепции в голове аналитика, также есть и в голове у разработчиков, а аналитик в свою очередь многое знает о реализации), опять же всё хорошо — это чистый Agile, аналитик внутри команды.

Если же у вас есть барьер между аналитиками и разработчиками и аналитики выполняют системный анализ, то можно попытаться устранить этот барьер, а можно и перейти полностью на классический каскадо-водопад, с детальным ТЗ, спецификациями и проч., оставив барьер на месте.

Information

Rating
Does not participate
Location
Москва, Москва и Московская обл., Россия
Date of birth
Registered
Activity