Waterban, PlanTrack, GtkSharp та інші смішні словосполучення - пара думок про те, чому варто зробити рішення по УП під себе

Всім добрий день!

Даний короткопост буде ходити близько питань проектного управління, присмачивши це прототипом реалізації ідеї суміщення канбана і водоспаду.

Преамбула
Неодноразово стикався з картиною: від менеджера вимагають сказати кінцевий термін і дають в руки трекер завдань. Рішення буває таке — план проекту в MS Project/TeamWork або в якомусь звичному для Waterfall інструменті, а для трекінгу кастомизированная Jira/Trello або щось ще. Дивлячись на муки з актуалізацією туди-сюди, народилася ідея одружити Waterfall і Kanban: методично і практично (у рамках наколенно-доморослої реалізації на Gtk#).


Амбулія як би
Методично
Канбан — це в першу чергу аналіз зміни статусу завдань. Звичний waterfall — це аналіз послідовності завдань. В цьому плані на перший погляд перетину ніякого немає — заплановані завдання можуть змінювати статус (і навіть в MS Project або хоч де). Однак прогноз канбана будується на часі проходження задачі до кінцевого статусу, і статуси змінюють виконавці самостійно, чим створюють факт, в той час як водоспад дає нам планові терміни. Щоб об'єднати це в одне, досить примітивно дати можливість виконавцям ганяти по канбан-доріжках завдання водоспаду в будь-яку сторону. Звична завдання менеджера після створення водоспадні плану зведеться до аналізу відхилень від нього — в той час як звична справа розробників та інших виконавців проекту зведеться до зміни статусів завдань.

Нічого чарівного, якщо б не одне але. Існують завдання, зміну статусу яких має скидати стан її послідовників — наприклад, якщо почали переробляти реалізацію фічі, то статус тестування міг би піти в нуль по-хорошому. Завдання таких зв'язків я без довгих роздумів назвав створенням «сильних зв'язків між завданнями.

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

Практично
Для практичної реалізації був обраний C# і Gtk# (оскільки я linux-користувач, а хотілося кроссплатформенности). Реалізацію (знову ж таки не думаючи довго) назвав я PlanTrack, і поточне стан — прототип.

Лайка з приводу поточної реалізаціїЯк з'ясувалося, Gtk# не настільки багатоплатформовий, наскільки хотілося (під Windows треба затягнути купку бібліотек). По-друге, вибір бази Sqlite теж був досить наївним потрібні різні збірки під різні платформи. Ті, хто захоче зібрати проект під linux, повинні будуть змінити в коді три рядки (DBHelper.cs: System.Data.SQLite --> Mono.Data.Sqlite, і в тому ж файлі у двох місцях SQLiteConnection --> SqliteConnection).

Більш того, на солодке. Мої вибачення за код похапцем, часу у мене як завжди обмаль (працюю навіть на святах), але справа навіть не в цьому. Виглядає все інтерфейсне господарство під Linux і під Windows надто вже по-різному.


Скріншоти





Посилання на windows-складання (прочитайте readme!).

Постамбула
Про що пост — може і не про ідеї, і точно не про реалізації (мої вправи по Gtk# навряд чи комусь згодяться).
Пост скоріше про те, що створення своїх інструментів може себе виправдати. Я не раз і не два робив (як PM'a) різні рішення з управління проектами, містечкові, у тих місцях де працював. Навіть на 1С доводилося. І знаєте що?.. Воно того варте. Заточений під себе інструмент дозволяє забивати цвяхи відразу прямо, а не натягувати свою роботу під чиїсь роздуми про те, як треба було б.

Всі ці підходи з управління проектами, всі ці рішення з управління проектами… їх треба знати — але тільки для того, щоб вибрати те, що підходить в даній ситуації. Я прихильник адаптації методів до роботи, а не адаптації роботи до методів.

В цьому і вододіл. Не можна, мабуть, вірити в те, що ми візьмемо RUP/XP/Scrum/<Список довгий> і тепер заживемо. Ні, не заживемо, а отримаємо проблем. Ні, не можна взяти MS Project і Jira і сказати — ось тепер ми в них трекаем і плануємо, тоді все буде добре. Ні, добре, не буде.

Добре буде тоді, коли хтось візьме, наприклад, Excel, і на макроси VBA зробить те, що підходить вашому бізнесу. Було діло я працював в одній великій компанії (обертається на Лондонській біржі) — і там ніхто не замовляв переробку SAP. Оцінка та відстеження проектів були зроблені під себе, під свої проекти, під свої методи. І в Excel. Працював я і в компаніях в 500 разів (без перебільшення) менше — і там створення своїх проектних рішень себе виправдовувало. Чому?

Якщо створення рішень по управлінню проектами під свої потреби — не компетенція компанії, то тоді проекти — не є пріоритетними для компанії, і не є перевагою для бізнесу.

Все примітивно. Майбутнє проектної компанії забезпечується процесом планування цього майбутнього. Якщо інструмент диктує правила планування, якими б не були хорошими закладені в нього практики — майбутнє не буде гнучким, воно не буде відповідати обставинам вашого бізнесу. Воно буде відповідати обставинам того бізнесу, який за вас подумав, як потрібно керувати вашими проектами.

Гарних свят і вдалих проектів!
У результаті думка така: свій молоток з ізоляційною стрічкою краще купленої кувалди, а приклад моїх триденних старань, викладених вище, можливо переконає когось у тому, що це цілком реально. Спасибі всім хто дочитав.

Джерело: Хабрахабр

0 коментарів

Тільки зареєстровані та авторизовані користувачі можуть залишати коментарі.