Ви бачите багато тих кто заповів всі гроші Залужному і дивиться на океан? Ви ж саме так написали поєднавши вчинок Людини із тим що вас турбує в знайомову вам оточенні.
Краще замислитись чому вас оточують такі люди, що ви це бачите.
Подивився статистику — такі ні. Європа різна. Балкани виглядають як церковні миші. Дивно.
Про рівень спеців — повністю згоден. Я не маю пояснення цьому факту.
Будь ласка обережніше. Це ж ДОУ. Тут люди не з черги за гречкою прийшли.
Вам хто цю ахінею про зброю та Київ та грабежі написав? Ви що серьозно в ЦЕ повірили настиільки щоб цитувати?
Таку солов’евську пропаганду тільки в черзі за водою в Донецьку можуть розказати.
Соромно таке лайно пистаи проміж освітненіх громадян.
А ви не цікавились скільки в Європі складають статки працівників б’юті індустрії?
Ви будете ДУЖЕ здивовані.
там хтось вище згадував манікюрчік про який варто забути. І це в першу чергу викликано ціною цього манікюрчика.
Про зачіки по 250 гривень можете не думати. Готуйте такуж суму але в валюті Європи.
Дякую за розгорнуту відповідь. Не дуже часто я зустрічав людей в чийому досвіді SAFE спрацював. З недоліками згоден на всі 100%.
З мого власного досвіду (не Уклон) SAFE програва важкістю планувать, що при зміні настроїв в бізнесі часто зводили на нуль все планування.
Можливо питання в якості проробки рішень заздалегідь та ступеню невизнченості в плані яким чином віирішити задачу.
Останнє питання — якого розміру PI? та розміри спринтів, що практикувались?
А до якої міри беруться невідомі речі в планування?
Ну на приклад задачі покращити перформанс, бо це треба але як не зрозуміло.
Чи взагалі кросс-командні речі в яких щось важливе для однієї залежної команди виявляться не таким важливим в команд, яка робить першою?
Чи взагалі якщо команда яка робить першу частину зіткнулась з блокером під час імплементації. Таке бувало?
А ви пробували SAFE в роботі? Якого успіху вдалось досягти? З якими складнощами зіткнулись та чи побороли їх?
Якщо не секрет, то яким чином?
Коли працюеш в українській компаній розробляючи додаток яким користуються мільйони співвітчизників, то відчуття accomplishment буає навіть частіше за релізи.
Knaban прискорює і реалізацю замовлень і розв’язок залежностей між командами і вирішення проблем в проді. До речі SCRUM це не покриває, так само як приоретизацію помилок.
Доречі дякую за назву книги, подивлюсь.
Зі свого боку, застерігаю не покладатись цілком на книжки. Життя має високий ступень різноманітности. Притягнути можно за вуха що завгодно. Особливо в ретроспективному сягненні, до якого людський мозок дуже пристосований. Але ж вирішенню завдань сьогодення ретроспективний аналіз не дуже сприяє, але допомагає в контрольованому процесі.
Більше про те, як працює наш мозок можно дізнатися з книги «Мислиння швидке та повільне» Д. Канемана.
А ось стосовно spike, з власного досвіду, у Канбан швідкість прийняття рішення та процесс виглядає набагато кращим ніж в SCRUM. В більшості випадків spike за годину не виконаєш. А в спринті вже весь час зайнято і для планування невідоме не готове.
Що каже SCRUM — беремо spike. І? Ну звичайно ж тільки його беруть у спрінт. Бо відповіді ж не має. І зазвичай його вирішують швидше за інші завдання. Почитали, погуглили, зробили прототип швиденько. І вже в настйпний спрінт беремо задачку.
Нібито все чудово, але коли клієнт побчить нову фічу? В кращому випадку через місяць, бо зайняло 2 спринти.
Що робить Канбан. Він робить spike та слідом задачку по результатам spike (research). В загалом займє від 4- х днів до тиждня. Тобто в рази швидше.
Так, з точки зору навантаження на product owner Канбан вимагає майже щоденної роботи над приоритезацією. Але ж це й дає гнучкість бізнесу в вирішенні «хотєлок» одну за одній.
Відповідь буде неочікувано короткою. Якщо не робити на ретро те що написали Ви, то це нібито і не ретроспектива зовсім. Підхід поскардитись на несмачну каву на холодні булочи не про нас.
Співчуваю. Пройти через цей біль сертифікації ISO.
А без Agile та SCRUM робироль, барато. Була навіть маленька епоха waterfall.
Проте питання від тих, хто платить гроші — як отримати не автомобіль. Бо з ним все більш-менш зрозуміло.
Питання — як отримати те, що начебто є продуктом інжинерії але з додаванням хаосу творчості.
Якщо для вас це не має складності — вітаю. Все ще попереду.
Ця «історична» складова є тим, що я ніяким чином не міг як розробник ПО зрозуміти. Як допоможе швідкість імплементації нового алгоритму сорутвання опомогти в розв’язанні задачі по баласуванню графа. Тим не менше SCRUM євангеліє на цьому базується.
Для мене книгою, яка поставила крапочки над і стала «Чистий Agile» Роба Мартіна.
Єдине де «історичні данні» допомагають є виконання проекту, який побито на етапи. І данні іллюструють наскільки успішним є прогрес в проекті. Не більше.
Все інше «від лукавого». Вся динаміка ламається в той час, в який команда стикається з невідомим. І ніякий Agile не дає відповіді, скільки часу може зайняти розв’язання задачі.
1. Насправді ми не викорисовуємо Канбан як підхід «взяв задачку і роби її, поки не буде зроблено». Ми дивимось на Cycle Time. І це не можливо без естімейту.
Тому задачі декомпонуються на меньші таким чином, щоб кодування рішення не займало більше
Оцінювання така сама практика як і ретроспективи. Вона не є винятковим атрибутом SCRUM, а більше невід’ємною частиною будь якого планування.
2. SCRUM чи Kanban відрізняє тільки підхід до взяття в роботу тікетів членом команди.
І як на мій досвід, саме SCRUM не обмежує брати те що до вподоби з ToDO тому що саме там і є скоуп спрінту. Єдине чим користуються члени команди це ціль спринта. В протилежність цьому Kanban жостко лімітує брати першу найвищу.
Тому описана ситуація є порушенням базового принципу Канбан top-right, при якому саме місце картки на дошці визначає її приоритет. І найприоритетніші залачі повинні братися в роботу коли «звільняються руки».
Як на мій смак, Kanban більш гнучкий в реакції на фідбек, бо дозволяє змінити рішення тут і зараз, ане чекати кінця спрінта, чи взагалі відміняти спринт. При цьому повністю захищаючи каденцію релізів.
Спробую допомогти Каріні, сформулювавши власний погляд на SCRUM та реалії розробки ПО в сьогоденні.
1. З власного досвіду, SCRUM не дуже пристосований до змін. Він добре працює на великому проєкті, де є великий ступень незалежності від інших команд і більшість змін йде до продукту що розробляється.
У разі змін приоритетів в розробці(не вимог до функціоналу, а безпосередньо змін) він перестає працювати. Закритість спрінтів вимагає багато узгоджень та лишає бізнес можливості швидкої реакції на навколишній світ.
Помилки знайдені після релізу взагалі більшостю SCRUM адептів віддаються на шось абстракте і не мають ніякої регламентації в фреймворку (начебто їх не існує). Не можливо чекати наступний спрінт, якщо в вас «лежить» прод або нова фіча вимагає швидких змін.
Ось чому, якщо ви розробляєете ВЛАСНИЙ продукт з різноманіттям функціоналу, то SCRUM більше заважає.
І цілі спринта разом з естімейтами на різноманіття доробок більше виглядають як карго культ і не сприяють бойовому духу команди.
Стосовно ретроспективи. Цей інструмент є корисним в будь якому фреймворці. Так само як і Канбан дошка, без якої SCRUM не працює, але ж вона все ж таки Канбан а не SCRUM. Тому я б рекомендував її всім хто спрямований на покращання процессів на регулярній основі.
2. Стосовно кросфункціональності. Все залежить від ступеню гранулярності завдань. Якщо доходити до рівня «додати кнопочку на цю формочку», тоді треба мати anykey-щика розробника. Але якщо залишатись на рівні story з ухилом до досвіду користувача, то задача в залежності від наявних ресурсів може виконуватись поступово через розширення тієї частини функціоналу де є вільні руки в канбан. Є фронтенд — доробляємо частину фротенду. Є бек — робимо необхідні зміни до беку. Якщо грамотно пикористовувати принцип архітектури «відкритий до розширення, закритий до змін» то конфліктів з Канбан не виникає. Узгодження контрактів та версіність інтерфейсу є одним з інструментів в досягненні успіху.
3. Скільки часу зацняло? В середньому на адаптацію треба від місяця до трьох. Це для того, щоб прилаштувати процеси. Дуже важливо слідкувати за розумінням процесу та принципів Канбан усіма учасниками. А все інше вже в руках команд та ретроспектив.
4. Чи лишились квартальні роадмапи? Звісно так. Без планування не існує майбутнього.
Буду радий фідбеку на фідповіді.
А где вы видели КАСКО за
Можно принять стоимость машины 500К, взнос 400К, кредита 100К.
КАСКО 35К за первый год и где-то
Тело кредита вы гасите, но уже переплатили за 2 года 65К при кредите в 100К.
Ну еще страховкой жизни 2% накидаем. Незаметно комиссию за выдачу 1% подсунем, плюс за перечисление денег возьмём 0.6%
Получим еще 3,6% что есть 3.6К от суммы.
Переплата за 2 года рассрочки 70К=70% от тела кредита.
Вот как-то так.
Всё равно перебор. Вы цены на готовые дома на западной окраине Киева смотрели? Там все под ключ и ценники таки в два раза меньше.
Посмеялся. Клоуны ведь для того чтобы смеятся. Правда? ТОлько к чему это в данной теме?
Год назад после мечты о Citroen Picasso (Grand Picasso) просмотрев рынок убиенных б/ушек неожиданно узнал что Peugeot 308 SW до 2017 года имеет такую же полноценную компоновку
И при этом всем на 10 см длиннее
По набору опций и комфорта за приемлимые деньги даст фору немцам (в холивор не полезу).
Ну и качество французов уже давно отличается от мифов рожденных в гаражах дядей Вась, ктороые лезли в Автомобиль с принципами итальянского автопрома середины прошлого века. Все работает. Я сменил С4 на 308 и второй год радуюсь ))
Дякую за сміливість поділитись досвідом,
Читав як цікавий триллер.
Після того як дочитав, виникло питання.
Де саме сталась помилка?
Експерементувати то не є помилка, то є шлях до успіху.
Добрався в роздумах до наступного:
А яким чином результат розробки ( навмистно залишу це в абстракній формі) повинен бути використованим на мобільних девайсах.
І ось тут як на мене випливає проблема.
Згадно із задумом автора фреймворку — у вигляді ДОДАТКУ.
А згідно із задумом команди автора топіку : у вигляді САЙТУ.
Що булоб, якби результат роботи був завантажегний як додаток на мобільний?
Повангую, що картинка перформансу була б без знаків питання.