Comments 9
Программировать я начал в 11 лет.
Это равносильно тому, как если математик скажет: «Математикой заниматься я начал в 7 лет» (что, кстати, будет правдой).
Интересует именно опыт профессиональной разработки ПО. Если Вы выпускали коммерчески успешные приложения в 11 лет, то тогда такая информация будет полезной. Если же Вы в 11 лет программировали для себя, то это не то, что можно назвать опытом профессиональной деятельности.
По остальному тексту. К сожалению, нет конкретики. Из статьи понятно только то, что из-за «хотелок» заказчиков не удавалось зафиксировать скоуп спринта. Но тогда отказ от спринтов и выполнение каждой задачи по-отдельности, в соответствии с её приоритетом — это как начальный ход в шахматах «е2е4». А какие ещё были проблемы? И какие были предложены решения этих проблем?
К сожалению, всё это осталось за рамками статьи.
Например, как Вы боролись с тем, что каждый Заказчик назначает наивысший приоритет для своей задачи? Или как Вы боролись с мелочевкой — когда от одного Заказчика регулярно поступают мелкие задачи, но из-за того, что они не сгруппированы, разработчику приходится отвлекаться от более сложных задач?
Какие еще были причины раздёргивания разработчиков? Как их устранили?
Об этом, к сожалению, ни слова.
Суть предложения:
1) Выкинуть Scrum, выкинуть спринты, забыть про чёткие сроки.
2) Остановить частые переключения и скачки с задачи на задачу.
3) Создать открытые очереди задач.
Перед тем, как поставить новый срочный таск, заказчики обязательно видят срочную очередь. Если нужно побыстрее, то заказчики решают приоритеты между собой, не вмешивая команду.
Нельзя сделать одновременно всё моментально и хорошо. Но можно выдавать максимально возможный performance в рамках тех ресурсов, что есть.
Нет ответа на основной вопрос. Как разбивать большие задачи на маленькие, выполнение которых предсказуемо? Интересует способ, пригодный именно для любых задач, который можно применять в том числе и к задачам, выглядящим неразбиваемыми. Как разбивать такие задачи, которые легко разбиваются, — понятно. Нужен либо универсальный способ для любых задач, либо в дополнение ко всем тривиальным способам ещё один способ для нетривиальных случаев.
1. Выбросить задачу как нерешаемую и поместить в черный список, чтобы не ставили повторно.
2. Обратиться в отдел кадров для подбора специалиста (но сначала понять, кто может отличить специалиста от проходимца).
3. Выделить время для изучения литературы по данной теме, «авось потом станет понятно».
Я имею в виду другое. Когда проблема не в отсутствии знаний. Например, реализация шифрования не разбивается на зашифрование и расшифрование фундаментально. Ни одну из этих подзадач нельзя протестировать и закрыть по отдельности. Для тестирования нужно реализовать вторую. Но это очень простой случай. А в больших сложных системах бывает так, что для добавления какой-то функциональности нужно произвести существенные изменения в пяти-шести различных местах и точно так же, как и в случае с шифрованием, каждое из этих изменений не может быть протестировано по отдельности, а значит не может быть выделено в отдельную задачу. Другими словами, задача неразбиваема не практически, а сугубо методологически. Методология содержит в себе такие ограничения, которые препятствуют формальному разбиению задачи.
Жду следующих статей
Как выковать процесс самому. Опыт компании 2ГИС