Цель заброшена
Автор не отписывался в цели 1 год 2 месяца 8 дней
Дневник цели
Немного завис мой проект, решил все же для начала разобраться в KMP, чтобы часть андроид сразу делать с использованием фреймворка KMP, но как-то все это сложно.
Ну очень интересный видосик по планированию
Немного определиться стоит ли сразу пилить KMP, пока понятно что, для десктопа нужна - идея, а для андроид и iOS - андроид студия и это сразу останавливает, слишком много настроек. Но в любом случае это нужно.
Немного погрузился в должность тимлида или скрам мастера, дополнил план.
Пару дней не работал над проектом, связано с окончанием учебы и практикой.
Сегодня изучал agile методологию — Scrum и понял, что это не подходит для моего проекта.
Рассматриваю варианты Scrumban или Экстремальное программирование.
Изучив экстремальное программирование, основное это постоянная работа с заказчиком и быстрое изменение требований от заказчика.
У меня готовая идея и быстрого изменения к требованиям точно не будет.
Scrumban - Kanban и Scrum. Планирование, разбивка за мелкие задачи, доска канбан, выбор любой задачи, завершение задачи за спринт.
Scrumban – это инновационный Agile-метод, позволяющий работать над проектом более эффективно и действительно решать поставленные задачи, а не просто концентрироваться на них. Гибридный подход помогает быстрее определять ключевые проблемы и находить пути их решения, лучше планировать и контролировать нагрузку команды, быстро реагировать на изменения.
Основные причины для использования Scrumban
- Легче внедрить, чем Scrum. Процесс Scrumban свободнее и больше похож на Kanban. В результате команды могут учиться и адаптироваться к нему быстрее.
- Отлично подходит для команд по разработке продуктов и R&D. Быстрая процедура обеспечивает быстрое и относительно безрисковое тестирование концепции.
- Постоянное улучшение. Благодаря Scrum команда гарантированно вносит улучшения, продвигая свой рабочий процесс.
Проблема-аналитика
При использовании нескольких приложений нет синхронизации между приложениями и оповещения приходят, когда их не ждешь. Несколько полезных приложений должны работать в согласованности с основным приложением таймменеджмента.
Цель
Оптимизировать работу нескольких приложений, для объединения функций и последовательных действий по времени, для уменьшения накладок и синхронизации функций, которые должны выполняться последовательно или одновременно с учетом одинаковых интервалов времени, таких как работа и помидор, перерыв и прием воды, и посещение туалета, прием пищи и прием воды перед прием пищи, большой перерыв между помидорами и прием пищи.
Отдельное приложение выполняет свою функцию, но, например постоянно сообщает о необходимости приема воды во время помидора, что нарушает концентрацию на работе.
MVP 1
Мобильное приложение Android
Features: TimeTracker + Pomodoro + Water meter (drink, to the toilet)
Упрощенный дизайн
Немного поработал над идеей, определил проблему, описал цель решения проблемы, определился с экранами и минимумом для MVP 1.
Разбирался в декомпозиции по агиле.
Техники декомпозиции требований в Agile
Метод 1 – разбиение по этапам
Разбить большую задачу, описывающую некий бизнес-процесс на составные части и этапы. Для этого в данном процессе необходимо выделить последовательную цепочку шагов, которые могут быть реализованы и выполнены независимо друг от друга.
В результате мы разбиваем большой бизнес-процесс на составляющие его этапы. Какие-то этапы при этом могут быть критичными и обязательными, а какие-то опциональными. Такая декомпозиция дает возможность:
Во-первых, определить различные приоритеты для каждой истории и сосредоточиться в первую очередь на самых важных для бизнеса этапах.
Во-вторых, при таком разбиении лучше понятен сам процесс, его шаги и составные части, возможные зависимости меду этапами.
Метод 2 – разбиение по позитивным и негативным сценариям
Декомпозицию на ожидаемый сценарий использования функционала и на неправильные, но возможные и вероятные сценарии работы. Для каждого сценария важно выделить отдельные пользовательские истории:
Для позитивного – реализация правильной работы функционала.
Для негативных – реализовать правильную отработку той или иной возможной ошибки, разработать альтернативный сценарий.
Позволяет выделить, проанализировать и запланировать отработку различных исключений и неверных сценариев использования ПО, которые в любом случае будут возникать.
Метод 3 – разбиение по правилам
Разбиваем процесс не на этапы, а на логические ветки, возможные варианты отработки функционала. Определяем набор сценариев, по которым может выполняться процесс при выполнении тех или иных правил\условий.
Позволяет
Выявить и вынести в отдельную пользовательскую историю различные правила и ограничения, которые могут встречаться в рамках процесса\функционала. Так меньше риск забыть или пропустить какие-то важные условия.
Как правило реализация в бизнес-процессе тех или иных условий будет иметь разный приоритет: что-то требуется реализовать в первой версии продукта, а без чего-то определенное время можно обойтись. Декомпозиция единого процесса по условиям\правилам позволит построить очередность реализации отдельных пользовательских историй.
Метод 4: Разбиение по видам операций
Существует ряд относительно стандартных операций, которые часто встречаются в различных функциях.
CRUD – от слов Create, Read, Update, Delete. Операции CRUD очень распространены в случаях, когда функциональность включает управление объектами, такими как продукты, заказы, пользователи, файлы и т.д.
Декомпозируя функциональность таким образом достаточно легко ответить на следующие вопросы:
Какие из операций являются действительно необходимыми для работы с тем или иным объектом? Как правило операции связанные и не имеет смысла реализовывать, например, создание объекта без возможности его просматривать. Однако, выделение операций позволит расставить для них приоритеты.
Каким образом необходимо реализовать каждую из операций? Возможно одна и та же операция должна быть реализована несколькими способами. В этом случае декомпозицию можно продолжить и вынести реализацию каждого из способов в отдельную пользовательскую историю.
Метод 5: Декомпозиция по типам платформы/ОС.
Является необходимость реализации одного и того же функционала для разных платформ, устройств, операционных систем.
Для разных платформ: персональные компьютеры, планшеты, смартфоны.
Для разных ОС: Windows, iOS, Android.
Для работы в различных браузерах.
Разбивая требование таким образом, может довольно легко выделить наиболее приоритетные направления для развития продукта и сфокусироваться на них в первую очередь.
Метод 6: Разбиение по типам данных и параметрам.
Для некоторых функций можно выделить различные типы данных или параметров, которые они должны обрабатывать. Соответственно, мы можем разбить большое требование\фичу на ряд мелких пользовательских историй, в рамках каждой из которых нужно реализовать работу только с каким-то одним типом данных.
При использовании данного метода декомпозиции мы можем четко определить допустимые и недопустимые параметры для реализуемой функции.
Метод 7: Разбиение по ролям\правам доступа.
Многие бизнес-процессы и функциональности часто подразумевают участие\работу с ними нескольких ролей и групп пользователей. Каждая группа пользователей с определенной ролью и правами доступа, может выполнять только определенную часть функций из общего процесса.
Разбивая общую функциональность на роли, которые должны выполнять ее части, мы более четко понимаем, какие именно функции необходимы и кто имеет права для их исполнения. На первом этапе можно реализовать базовые функции.
Метод 8: Декомпозиция по сценариям тестирования\тест-кейсам.
позволяет разбить большие пользовательские истории задавая вопрос, как та или иная часть функциональности будет проверена.
Мы определяем какие сценарии необходимо проверить, какие тесты выполнить, чтобы узнать, работает ли эта функция. В результате мы сформируем набор тест-кейсов, каждый из которых и будет представлять собой отдельную задачу. Каждая задача должна быть реализована так, чтобы тестовый сценарий был успешно пройден.
Анализируя тестовый сценарий легко понять, насколько он распространен и вероятен в условия реального использования продукта, что позволяет выставить соответствующие приоритеты.
При таком способе разбиения мы сразу получаем и описание для задачи\пользовательской истории и сценарий, по которому можно проверить успешность ее реализации.
Пока занимаюсь проработкой идеи, разбором пунктов ТЗ, минимумов фич для MVP 1. Все сразу не получиться реализовать, пока нужно рабочий минимум реализовать.
Создал доску в трело для проекта. Пока еще нет карточек, посмотреть тут
Пока это была идея было проще, но когда начинаешь переносить это все в план реализации, видится совсем по другому, но тут главное просто по пунктам по пунктам и все будет ок.
Работать над приложением каждый день, каждый день писать отчет о проделанной работе.