Нам надійшло наступне питання щодо організації і планування Scrum:
я трохи сконфужена. Зараз читаю про скрам і ось що мене насторожує:
"Такая целенаправленность на выпуск рабочего кода за короткий промежуток времени означает только одно: в Scrum и XP нет места теории. Agile-методологии не гонятся за красивыми UML моделями, выполненными при помощи специальных case-средств, за созданием детализированных спецификаций или написанием кода,
который сойдёт на все случаи жизни. Вместо этого Scrum и XP команды концентрируются на том, чтобы завершить необходимые задачи. Эти команды могут мириться с ошибками в ходе работы, но они понимают, что лучшее средство выявить эти ошибки – это перестать думать о софте на теоретическом уровне анализа и дизайна, и, закатав рукава, полностью посвятить себя созданию продукта.
Именно акцент на действии, а не на теории ярко выделяет эту книгу среди прочих."
Однак після цього йде велика кількість саме планування, та пояснення чому так важливо спілкуватись та обговорювати плани.
Відповідь:
розумію, Scrum не означає відсутність планування, воно дуже і дуже важливе, але трохи на іншому рівні, ніж це було прийнято раніше. В абзаці говорять про планування, коли все до деталей було проговорене завчасно і лише потім програмісти починали писати код. Зараз же програмісти пишуть код ще задовго до того, як ідея фінального продукту оформлена до кінця, тож на шляху буде багато помилок і переписування коду, для того, щоб зрозуміти куди рухатися далі на рівні компанії.
нажаль, часто замовники самі не розуміють чого хочуть і тим паче не розуміють що технічно можливо і як багато часу це займе. За два тижні можна видати перший прототип чи версію і показати. Тоді вони можуть потестити і зрозуміти, що їм підходить, а що ні і вже від цього рухатися далі.
Весь потенційний функціонал ділиться на маленькі шматочки, а їх пріоритет і вигляд не прописуються завчасно у великих мануалах, а динамічно змінюються у процесі створення - отримання фідбеку - обговорення з командою - продовження створення